[Standards] Stanza namespaces
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. 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. In a recent change to M-Link, we tightened up our handling of namespaces on stanzas, so we are now conformant WRT the above. There has since been some (unfortunately public) suggestions that not accepting client stanzas on an S2S stream is a bug in M-Link, so I'd like to seek other opinions on the correct behaviour. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Stanza namespaces
Hi, On Tue, Apr 27, 2010 at 10:00 AM, Dave Cridland d...@cridland.net wrote: There has since been some (unfortunately public) suggestions that not accepting client stanzas on an S2S stream is a bug in M-Link, so I'd like to seek other opinions on the correct behaviour. How would client stanzas appear on a S2S stream? Given that the S2S streams doesn't use the client NS, are you saying that you are receiving over a S2S link something like: c:message xmlns:c=jabber:client.../c:message Just trying to understand how this would happen. As for how to deal with it, we could argue for be liberal on what you accept...-style of rule, but those tend to leave a big bag of legacy stuff for future generations. Also, this would remove the pressure on buggy servers (and I'm claiming that a server that generates client namespace elements over a S2S link is buggy) to fix it. I don't believe there is a good solution. I prefer not to accept such stanzas, and drop the connection with the appropriate stream error stanza but we should be aware that this could disrupt the XMPP network for a while, as currently working (but buggy) servers stop being able to connect to the rest of the us. By, -- Pedro Melo http://www.simplicidade.org/ xmpp:m...@simplicidade.org mailto:m...@simplicidade.org
Re: [Standards] Stanza namespaces
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/
Re: [Standards] Stanza namespaces
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,
Re: [Standards] Stanza namespaces
On 4/27/10 3:00 AM, Dave Cridland wrote: 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. Sometime yesterday (before you sent your message to the list) I wrote the following text in my working copy of 3920bis: *** Note: Because a client sends stanzas over a stream whose default namespace is 'jabber:client', if the server to which the client is connected needs to route a client-generated stanza to another server then it MUST re-scope the stanza so that its default namespace is 'jabber:server' (i.e., it MUST NOT send a stanza qualified by the 'jabber:client' namespace over a stream whose default namespace is 'jabber:server'). Similarly, a routing server MUST re-scope a stanza received over a server-to-server stream (whose default namespace is 'jabber:server') so that the stanza is qualified by the 'jabber:client' namespace before sending it over a client-to-server stream (whose default namespace is 'jabber:client'). *** That might not be precise enough, and it leaves out the error handling. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Stanza namespaces
On Tue, Apr 27, 2010 at 9:18 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/27/10 3:00 AM, Dave Cridland wrote: 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. Sometime yesterday (before you sent your message to the list) I wrote the following text in my working copy of 3920bis: *** Note: Because a client sends stanzas over a stream whose default namespace is 'jabber:client', if the server to which the client is connected needs to route a client-generated stanza to another server then it MUST re-scope the stanza so that its default namespace is 'jabber:server' (i.e., it MUST NOT send a stanza qualified by the 'jabber:client' namespace over a stream whose default namespace is 'jabber:server'). Similarly, a routing server MUST re-scope a stanza received over a server-to-server stream (whose default namespace is 'jabber:server') so that the stanza is qualified by the 'jabber:client' namespace before sending it over a client-to-server stream (whose default namespace is 'jabber:client'). *** That might not be precise enough, and it leaves out the error handling. That seems fairly definitive and, as Dave mentions, the error handling is already defined elsewhere. /K
Re: [Standards] Stanza namespaces
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
Re: [Standards] Stanza namespaces
On Tue, Apr 27, 2010 at 9:34 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/27/10 2:30 PM, Kevin Smith wrote: On Tue, Apr 27, 2010 at 9:18 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 4/27/10 3:00 AM, Dave Cridland wrote: 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. Sometime yesterday (before you sent your message to the list) I wrote the following text in my working copy of 3920bis: snip/ That might not be precise enough, and it leaves out the error handling. That seems fairly definitive and, as Dave mentions, the error handling is already defined elsewhere. It's definitive, but it might not be correct. Do we need to be so strict about this? As long as the message xmlns='jabber:client'/ and message xmlns='jabber:server'/ have different schemas, I think we probably should. The other option is consolidating the schemas, and doing away with the two namespaces and sticking them in the same one. While in principle I'm in favour of the latter as the cleaner solution, we're looking at a new xmpp stream version header, and I don't know if anyone's up for that at this point. /K
Re: [Standards] Stanza namespaces
Note: Because a client sends stanzas over a stream whose default namespace is 'jabber:client', if the server to which the client is connected needs to route a client-generated stanza to another server then it MUST re-scope the stanza so that its default namespace is 'jabber:server' (i.e., it MUST NOT send a stanza qualified by the 'jabber:client' namespace over a stream whose default namespace is 'jabber:server'). Similarly, a routing server MUST re-scope a stanza received over a server-to-server stream (whose default namespace is 'jabber:server') so that the stanza is qualified by the 'jabber:client' namespace before sending it over a client-to-server stream (whose default namespace is 'jabber:client'). *** That might not be precise enough, and it leaves out the error handling. That seems fairly definitive and, as Dave mentions, the error handling is already defined elsewhere. It's definitive, but it might not be correct. Do we need to be so strict about this? That's the question. Especially that it also applies to the external component protocol - XEP-0114 which also uses separate namespaces (2!!) for sending stanzas. Even though XEP-0225 seems to be re-using jabber:client namespace, which in my opinion is move in a good direction, it needs some corrections too. As I mentioned, it doesn't have a separate namespace for the handshaking packets, hence causing conflicts if you want to put c2s connection manager behind the XEP-0225 component. Artur
Re: [Standards] Stanza namespaces
Dnia 2010-04-27, wto o godzinie 15:56 +0100, Artur Hefczyc pisze: 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. This is also how jabberd2 is handling incoming packets. Is there a real advantage of not accepting jabber:client packets on S2S connection, while still blindly converting jabber:server to jabber:client?
Re: [Standards] Stanza namespaces
On 4/27/10 4:06 PM, Tomasz Sterna wrote: Dnia 2010-04-27, wto o godzinie 15:56 +0100, Artur Hefczyc pisze: 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. This is also how jabberd2 is handling incoming packets. Is there a real advantage of not accepting jabber:client packets on S2S connection, while still blindly converting jabber:server to jabber:client? I assume that even if we allowed 'jabber:client' stanzas over 'jabber:server' streams, we would not allow 'jabber:server' stanzas over 'jabber:client' streams. At which point everything becomes 'jabber:client', in a way... Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
