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