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. 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 §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. > 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 -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
