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'/> </stream:stream> or (perhaps even worse) this: <stream:stream xmlns='jabber:server'> <message xmlns='foo'/> </stream:stream> or (what's under discussion now) this: <stream:stream xmlns='jabber:server'> <message xmlns='jabber:client'/> </stream:stream> > 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. Correct. > 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? <snip/> >> 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 -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
