In XMPP, each stream has a default namespace. Stanzas are the elements with local-name "message", "presence", or "iq", qualified by that default namespace. Streams also have other, specifically documented, top-level elements, such as those for SASL, or TLS negotiation - these being explicitly signalled as being acceptable. Other unknown top-level elements will cause the connection to be dropped.

In particular, §4.5.2 of rfc3920bis states:

A default namespace declaration is REQUIRED and defines the allowable
  first-level children of the root stream element.

Note that §A.1 includes:

          <xs:choice minOccurs='0' maxOccurs='1'>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
              <xs:element ref='client:message'/>
              <xs:element ref='client:presence'/>
              <xs:element ref='client:iq'/>
            </xs:choice>
            <xs:choice minOccurs='0' maxOccurs='unbounded'>
              <xs:element ref='server:message'/>
              <xs:element ref='server:presence'/>
              <xs:element ref='server:iq'/>
              <xs:element ref='db:result'/>
              <xs:element ref='db:verify'/>
            </xs:choice>
          </xs:choice>

(In other words, either client or server+db elements appear, never both).

And §4.6.3.24 describes the unsupported-stanza-type stream error:

The initiating entity has sent a first-level child of the stream that
  is not supported by the server or consistent with the default
  namespace.

Now...

My assertion is that if a server sees, on an S2S stream, a top-level element of local-name "message" qualified by a namespace of "jabber:client", for example, it should - for strict conformance with the specification - issue a stream error and shut down the stream.

In a recent change to M-Link, we tightened up our handling of namespaces on stanzas, so we are now conformant WRT the above.

There has since been some (unfortunately public) suggestions that not accepting client stanzas on an S2S stream is a bug in M-Link, so I'd like to seek other opinions on the correct behaviour.

Dave.
--
Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

Reply via email to