[Standards] Stanza namespaces
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:
or (perhaps even worse) this:
or (what's under discussion now) this:
> 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
> 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...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards