[Standards] Stanza namespaces

Artur Hefczyc artur.hefczyc at tigase.org
Tue Apr 27 14:56:24 UTC 2010


I normally don't participate to such discussions because they tend to be lengthy with no practical outcome.
However, I encountered a few problems related to xmlns handling recently both with jabber.org (M-Link)
and transports and also with XEP-0225.

I think sharing my thought and experience might be useful.

> 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.

My understanding of the spec is that it defines a default namespace for top level
elements but it does not forbids you from sending elements within a different namespace
as long as this different namespace can be understood.

The thing is that converting namespaces between jabber:client, jabber:server, 
jabber:component:accept does not make much practical sense and on the server
side it does impact the performance.

Please note, right now from the server point of view we have 2 namespaces:
jabber:client and jabber:server. During s2s communication the server blindly
converts xmlns from jabber:client to jabber:server when sending the packet
and the receiving server blindly converts xmlns from jabber:server to 
jabber:client. There is no practical meaning for this xmlns conversion and
there is no way we can extend it.
I mean, let's say we create a monitor component and we would like it to
send packets within jabber:monitor namespace (for whatever reason). 
There is currently now way we can send such packets through s2s and
preserve the namespace.

So I suggest we understand the spec as it defines a default namespace
for top-level elements unless the element has a different namespace set.
Just think of a practical implications and what would serve us best.

The only place where I can see usage for a different namespaces
are the protocol control packets: s2s handshaking, XEP-0225 handshaking,
XEP-0114 handshaking etc...

Especially for the XEP-0225 this is quite important. Right now it shares the
same xmlns for the connection handshaking and other traffic. Therefore it is
impossible to put c2s connection manager over the XEP-0225 connection
because you never know whether the SASL or startls packets refers to the
XEP-0225 connection or the c2s user connection.

> 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 § 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.

I do not know what was the original author's intention for this statement.
My understanding of this is that: the server supports both jabber:client and
jabber:server namespaces.
'OR' returns false if both sides of the OR are false. Therefore, if the server
receives jabber:client packet over s2s stream it should still be acceptable
because this 'first-level child element' is supported by the server which fulfils
the first requirement.

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

Regardless whose understanding is correct about the spec above. I am also
concerned what are the benefits of that change? One of the greatest advantages
of the XMPP protocol you hear is it's flexibility and openness. I am really keen on
staying 100% close to the spec but in places where the spec is not 100% clear, I prefer
not to put artificial restrictions.

Artur Hefczyc

More information about the Standards mailing list