[Standards] Stanza namespaces

Peter Saint-Andre stpeter at stpeter.im
Tue Apr 27 20:33:22 UTC 2010

On 4/27/10 8:56 AM, Artur Hefczyc wrote:

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

This is ambiguous in the spec. For instance, it's not clear if this is OK:

<stream:stream xmlns='jabber:server'>
  <foo xmlns='bar'/>

or (perhaps even worse) this:

<stream:stream xmlns='jabber:server'>
  <message xmlns='foo'/>

or (what's under discussion now) this:

<stream:stream xmlns='jabber:server'>
  <message xmlns='jabber:client'/>

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

This is true not just "right now" but ever since 1999.

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

And: what would break?


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

It seems that most server developers have always assumed that you needed
to re-scope a stanza for sending over s2s (make sure the stanza is
qualified by 'jabber:server' instead of 'jabber:client'). I don't see
what that really accomplishes, and I think it might be only a legacy of
the original jabberd 1.x server without any practical value. However,
historically your interpretation is somewhat novel. That doesn't mean
it's wrong. :)

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

Or we can fix the spec...


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100427/1ba46843/attachment.bin>

More information about the Standards mailing list