[Standards] Stanza namespaces

Matthew Wild mwild1 at gmail.com
Tue Apr 27 14:52:41 UTC 2010


Excerpts from Artur Hefczyc's message of Tue Apr 27 15:56:24 +0100 2010:
> Hi,
> 
> 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.
> 

I agree. If we were doing XMPP from the start, this is certainly one thing I'd love to
see changed.

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

You would encapsulate it inside a message. This is standard XMPP, non-stanzas
have no semantics related to routing, so I think it's perfectly valid for them
to be rejected by a server that doesn't understand them.

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

This is already done for SASL, TLS, compression, etc.. It's perfectly legal,
just don't expect a server that doesn't understand such tags to silently
accept (drop?) them.

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

s2s started out quite a different beast to c2s. I'm quite sure it seemed wise back
then to have everything between servers under a new namespace. However we now have
SASL, TLS, compression between servers - and it really looks little different to a
standard c2s stream. However there are still differences, one noticeable one being
that s2s stanzas are required to have both to/from attributes, however clients are
able to omit from (also 'to' in some cases).


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

Prosody also has the same check, and excepting a bug in 0.6.1 (which caused it to allow
jabber:client stanzas without error) it will reject any stanza not in jabber:server or
one of the other understood (defined) namespaces. This guards against clients/servers
trying to negotiate features we don't support, for example. The alternative would be
to ignore such elements, however that could lead to silent failures, which I am really
not a fan of.

I do agree that the M-Link switch was rather sudden and unforgiving - related to the
bug I mentioned above, Prosody 0.6.1 was also prone to sending jabber:client over s2s
in some cases (notably MUC presence broadcasts). However overall I welcome the move,
there are too many clients and servers playing fast and loose with the specifications,
(knowingly or not) and all it does is give potential for silly bugs and incompatibilities.

FWIW Prosody 0.6.2 (hopefully to be announced today) closes the bug, and makes a second
server that acts completely the same way as M-Link.

Regards,
Matthew



More information about the Standards mailing list