Re: [Standards] Nonzas: What are they and do we need them?
On Thu, Apr 23, 2015 at 3:52 AM, Kim Alvefur wrote: > tors apr 23 02:35:24 2015 GMT+0200 skrev Waqas Hussain: > > On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus > wrote: > > > > > The discussion drifted a bit into whether non-stanza top-level stream > > > elements should be used for a particular use case/XEP > > > or not. But what I really wanted to discuss is whether they could be > > > used after resource binding in general, or if this should be > disallowed. > > > That's why I asked the council members to express their opinion on this > > > in their next meeting. > > > > > > As side note: I still think it is advantageous to have a unambiguous > > > term defined for non-stanza top-level stream elements. It would clearly > > > distinguish stanzas from non-stanzas in specifications and may help to > > > avoid the case where specification authors erroneously refer to > > > non-stanzas as stanzas. See for example the EXI XEP (XEP-322) where > this > > > is done (nearly?) everywhere. Not to mention that this may cause > > > confusion when we take XEP-198: Stream Management into consideration. > > > > > > - Florian > > > > > > > > Some thoughts: In the Prosody XMPP server implementation, we classify > > top-level elements into two categories: stanzas, and non-stanzas > (nonzas!). > > We call non-stanzas 'elements'. Interestingly, stanzas sent before a bind > > are categorized with non-stanzas, given how different they are from > normal > > stanzas (several normally expected invariants don't hold for them, e.g., > no > > reliable 'from' attribute). The bind stanza is special, and is almost a > > third category (it awkwardly exists in this space between having a > username > > and not having a resource). > > > > These three categories require different sets of validation. > > > > Normally we expect non-stanzas to be purely affecting the state of a > > specific stream, and they don't have any affect beyond that. Stanzas > > typically do not affect the stream itself. The exceptions make code > > awkward, and the main (only?) one is the bind IQ (which we are forced to > > special case). > > I would like to point out that dialback elements are also in an awkward > space, being treated as stanzas when sending (being routed etc) and nonzas > when receiving. > I'll add this to your point: bind is more awkward than dialback. While dialback is awkward, it can relatively easily be isolated in the s2s and dialback plugins in Prosody. Bind awareness however needs to be in the core stanza router. In the XMPP layering violation contest, my vote goes to bind :) Inspecting stanza routers of different servers is actually quite fascinating. You get to see all the more awkward parts of XMPP core. -- Waqas Hussain
Re: [Standards] Nonzas: What are they and do we need them?
tors apr 23 02:35:24 2015 GMT+0200 skrev Waqas Hussain: > On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus wrote: > > > The discussion drifted a bit into whether non-stanza top-level stream > > elements should be used for a particular use case/XEP > > or not. But what I really wanted to discuss is whether they could be > > used after resource binding in general, or if this should be disallowed. > > That's why I asked the council members to express their opinion on this > > in their next meeting. > > > > As side note: I still think it is advantageous to have a unambiguous > > term defined for non-stanza top-level stream elements. It would clearly > > distinguish stanzas from non-stanzas in specifications and may help to > > avoid the case where specification authors erroneously refer to > > non-stanzas as stanzas. See for example the EXI XEP (XEP-322) where this > > is done (nearly?) everywhere. Not to mention that this may cause > > confusion when we take XEP-198: Stream Management into consideration. > > > > - Florian > > > > > Some thoughts: In the Prosody XMPP server implementation, we classify > top-level elements into two categories: stanzas, and non-stanzas (nonzas!). > We call non-stanzas 'elements'. Interestingly, stanzas sent before a bind > are categorized with non-stanzas, given how different they are from normal > stanzas (several normally expected invariants don't hold for them, e.g., no > reliable 'from' attribute). The bind stanza is special, and is almost a > third category (it awkwardly exists in this space between having a username > and not having a resource). > > These three categories require different sets of validation. > > Normally we expect non-stanzas to be purely affecting the state of a > specific stream, and they don't have any affect beyond that. Stanzas > typically do not affect the stream itself. The exceptions make code > awkward, and the main (only?) one is the bind IQ (which we are forced to > special case). I would like to point out that dialback elements are also in an awkward space, being treated as stanzas when sending (being routed etc) and nonzas when receiving. -- Kim "Zash" Alvefur
Re: [Standards] Nonzas: What are they and do we need them?
On Wed, Apr 22, 2015 at 3:41 AM, Florian Schmaus wrote: > The discussion drifted a bit into whether non-stanza top-level stream > elements should be used for a particular use case/XEP > or not. But what I really wanted to discuss is whether they could be > used after resource binding in general, or if this should be disallowed. > That's why I asked the council members to express their opinion on this > in their next meeting. > > As side note: I still think it is advantageous to have a unambiguous > term defined for non-stanza top-level stream elements. It would clearly > distinguish stanzas from non-stanzas in specifications and may help to > avoid the case where specification authors erroneously refer to > non-stanzas as stanzas. See for example the EXI XEP (XEP-322) where this > is done (nearly?) everywhere. Not to mention that this may cause > confusion when we take XEP-198: Stream Management into consideration. > > - Florian > > Some thoughts: In the Prosody XMPP server implementation, we classify top-level elements into two categories: stanzas, and non-stanzas (nonzas!). We call non-stanzas 'elements'. Interestingly, stanzas sent before a bind are categorized with non-stanzas, given how different they are from normal stanzas (several normally expected invariants don't hold for them, e.g., no reliable 'from' attribute). The bind stanza is special, and is almost a third category (it awkwardly exists in this space between having a username and not having a resource). These three categories require different sets of validation. Normally we expect non-stanzas to be purely affecting the state of a specific stream, and they don't have any affect beyond that. Stanzas typically do not affect the stream itself. The exceptions make code awkward, and the main (only?) one is the bind IQ (which we are forced to special case). This all has actual architectural implications: stream features can be consumed by XMPP proxies (BOSH/websocket components, TLS unwrapping proxies, other edge server scenarios), while non-stanzas are passed through to the XMPP core/router. The idea of XMPP reverse proxies has very interesting deployment implications, and something we have experimented with. -- Waqas Hussain
Re: [Standards] Nonzas: What are they and do we need them?
On Mon, Apr 20, 2015 at 2:45 PM, Florian Schmaus wrote: > On 20.04.2015 18:22, Christian Schudt wrote: > > > >> For me personally, the contra-Nonza arguments did not convince me. It > >> appears that nothing in the specification prevents you from using Nonzas > >> after resource binding with BOSH. XEP-206 3. only says "SHOULD contain". > >> I also don't see why they would introduce "a bunch of conceptual and > >> implementations problems". > > > > I agree with you. The contra arguments are weak. I think Prosody even > advertises XEP-0198 over BOSH, so clients would use it. And I also see no > implementation problems. > > Not sure what prosody is doing and it's slightly unrelated to the Nonza > discussion, but I want to point out that it makes no sense to use xep198 > SM over BOSH. Ignoring Prosody for a moment, why do you think 198 on BOSH is nonsensical? BOSH is a low level protocol, and the stream abstraction still exists. XEP-0198 operates over the stream abstraction. Whether it's TCP, BOSH, WebSocket or something else under the stream, 198 can continue operating. It certainly isn't (and shouldn't be) disallowed. Use-case: you can in theory start a BOSH stream, and use 198 to upgrade to a WebSocket stream later. It's an interesting idea, where you can swap the low level transport based on changing network conditions without interrupting the user's session. I'm not sure if this works in Prosody (if it doesn't, then advertising it is a bug). -- Waqas Hussain
Re: [Standards] Nonzas: What are they and do we need them?
The discussion drifted a bit into whether non-stanza top-level stream elements should be used for a particular use case/XEP or not. But what I really wanted to discuss is whether they could be used after resource binding in general, or if this should be disallowed. That's why I asked the council members to express their opinion on this in their next meeting. As side note: I still think it is advantageous to have a unambiguous term defined for non-stanza top-level stream elements. It would clearly distinguish stanzas from non-stanzas in specifications and may help to avoid the case where specification authors erroneously refer to non-stanzas as stanzas. See for example the EXI XEP (XEP-322) where this is done (nearly?) everywhere. Not to mention that this may cause confusion when we take XEP-198: Stream Management into consideration. - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Nonzas: What are they and do we need them?
On 4/20/15 12:45 PM, Florian Schmaus wrote: On 20.04.2015 18:22, Christian Schudt wrote: For me personally, the contra-Nonza arguments did not convince me. It appears that nothing in the specification prevents you from using Nonzas after resource binding with BOSH. XEP-206 3. only says "SHOULD contain". I also don't see why they would introduce "a bunch of conceptual and implementations problems". I agree with you. The contra arguments are weak. I think Prosody even advertises XEP-0198 over BOSH, so clients would use it. And I also see no implementation problems. Not sure what prosody is doing and it's slightly unrelated to the Nonza discussion, but I want to point out that it makes no sense to use xep198 SM over BOSH. Oh and I'd prefer to just call them (top-level) XML elements, or Stream elements. Nonza sounds really weird. There's no need to invent a new name, imo. That's ambiguous: Stanza are also (top-level) XML elements and Stream elements [1]. That's the main motivation behind defining a term for them: Removing ambiguity (when discussing things, when specifying protocols, …). - Florian 1: An accurate specification for stanza would be: "A top-level XML element of a XMPP Stream which tag name is either 'message', 'iq' or 'presence' qualified by either the 'jabber:client' or 'jabber:server' namespace." What a coincidence, that's exactly how it's defined in RFC 6210. ;-) http://tools.ietf.org/html/rfc6120#section-4.1 Peter
Re: [Standards] Nonzas: What are they and do we need them?
On 4/20/15 1:44 PM, Peter Saint-Andre - &yet wrote: On 4/20/15 12:45 PM, Florian Schmaus wrote: On 20.04.2015 18:22, Christian Schudt wrote: For me personally, the contra-Nonza arguments did not convince me. It appears that nothing in the specification prevents you from using Nonzas after resource binding with BOSH. XEP-206 3. only says "SHOULD contain". I also don't see why they would introduce "a bunch of conceptual and implementations problems". I agree with you. The contra arguments are weak. I think Prosody even advertises XEP-0198 over BOSH, so clients would use it. And I also see no implementation problems. Not sure what prosody is doing and it's slightly unrelated to the Nonza discussion, but I want to point out that it makes no sense to use xep198 SM over BOSH. Oh and I'd prefer to just call them (top-level) XML elements, or Stream elements. Nonza sounds really weird. There's no need to invent a new name, imo. That's ambiguous: Stanza are also (top-level) XML elements and Stream elements [1]. That's the main motivation behind defining a term for them: Removing ambiguity (when discussing things, when specifying protocols, …). - Florian 1: An accurate specification for stanza would be: "A top-level XML element of a XMPP Stream which tag name is either 'message', 'iq' or 'presence' qualified by either the 'jabber:client' or 'jabber:server' namespace." What a coincidence, that's exactly how it's defined in RFC 6210. ;-) 6120, that is! http://tools.ietf.org/html/rfc6120#section-4.1 Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] Nonzas: What are they and do we need them?
On 20.04.2015 17:00, Georg Lukas wrote: > * Florian Schmaus [2015-04-20 15:27]: >> Contra: >> - Messages and IQs could be used instead >> - Can't be used with BOSH > As you pointed out below, they can be used in theory. I just assume that > most implementations will not expect them and might break in subtle ways. > IIRC, it required significant refactoring of the Smack XMPP library to > accommodate them. I'm sure similar effort will be required in most other > XMPP client and server implementations. When I added support for SM to Smack I needed to define an internal API for Nonzas anyway, i.e. there is now a "callback" (it's not really a typical callback), which interested parties can consume when a Nonza arrives. So you basically have the effort of adding support for Nonzas in your XMPP stack anyways (as soon as you add support for SM). >> - Introduces a bunch of conceptual and implementations problems > One specific problem is that they can not be accounted for in XEP-0198, > and therefore it is not clear if a Nonza got successfully delivered to > the recipient in case of stream resumption. In the CSI discussion this > caused confusion and led to the notion of resetting the CSI state on > stream resumption, which looks like fixing the symptoms. It appears the author(s) of CSI think of not keeping the CSI state as a feature and specified the protocol that way intentionally, not as workaround for Nonzas not being tracked by SM. >> Pro: >> - Expresses the semantic that they are not routed >> - This increases security, as they are harder to spoof > > I understand the first two points, but I'm not sure if they really > outweigh the problems. I think the advantages outweigh he problems. In fact, I think there are no problems at all. >> A. Nonzas MUST NOT be used after resource binding > With the obvious exception of XEP-0198, of course. Course, SM is fine as it is, And we all ♥ it (I really do). :) - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Nonzas: What are they and do we need them?
On 20.04.2015 19:40, Philipp Hancke wrote: > Am 20.04.2015 um 06:27 schrieb Florian Schmaus: >> In order to make the following easier, I'd first like to define the term >> Nonza: >> >> A Nonza is every top level XMPP stream element which is not a Stanza. >> (see also [1]). > > http://geekplace.eu/xeps/xep-nonza/xep-nonza.html#rules > > and violate those rules. But they're legacy > which we can't fix anyway. That's the sole reason the rule in the Nonza XEP uses "SHOULD NOT". :) - Florian signature.asc Description: OpenPGP digital signature
Re: [Standards] Nonzas: What are they and do we need them?
On 20.04.2015 18:22, Christian Schudt wrote: > >> For me personally, the contra-Nonza arguments did not convince me. It >> appears that nothing in the specification prevents you from using Nonzas >> after resource binding with BOSH. XEP-206 3. only says "SHOULD contain". >> I also don't see why they would introduce "a bunch of conceptual and >> implementations problems". > > I agree with you. The contra arguments are weak. I think Prosody even > advertises XEP-0198 over BOSH, so clients would use it. And I also see no > implementation problems. Not sure what prosody is doing and it's slightly unrelated to the Nonza discussion, but I want to point out that it makes no sense to use xep198 SM over BOSH. > Oh and I'd prefer to just call them (top-level) XML elements, or Stream > elements. Nonza sounds really weird. There's no need to invent a new name, > imo. That's ambiguous: Stanza are also (top-level) XML elements and Stream elements [1]. That's the main motivation behind defining a term for them: Removing ambiguity (when discussing things, when specifying protocols, …). - Florian 1: An accurate specification for stanza would be: "A top-level XML element of a XMPP Stream which tag name is either 'message', 'iq' or 'presence' qualified by either the 'jabber:client' or 'jabber:server' namespace." signature.asc Description: OpenPGP digital signature
Re: [Standards] Nonzas: What are they and do we need them?
On 20 April 2015 at 18:40, Philipp Hancke wrote: > Am 20.04.2015 um 06:27 schrieb Florian Schmaus: > >> In order to make the following easier, I'd first like to define the term >> Nonza: >> >> A Nonza is every top level XMPP stream element which is not a Stanza. >> (see also [1]). >> > > http://geekplace.eu/xeps/xep-nonza/xep-nonza.html#rules > > and violate those rules. But they're legacy > which we can't fix anyway. > Yeah, but I think the rules are wrong. The risk of saying "Nonzas have no to/from" is that the converse doesn't apply - there are only three stanzas ever, and you'd never want to route anything else. Dave.
Re: [Standards] Nonzas: What are they and do we need them?
Am 20.04.2015 um 06:27 schrieb Florian Schmaus: In order to make the following easier, I'd first like to define the term Nonza: A Nonza is every top level XMPP stream element which is not a Stanza. (see also [1]). http://geekplace.eu/xeps/xep-nonza/xep-nonza.html#rules and violate those rules. But they're legacy which we can't fix anyway.
Re: [Standards] Nonzas: What are they and do we need them?
On 20 April 2015 at 17:39, Georg Lukas wrote: > * Matthew Wild [2015-04-20 18:33]: >> > In the XEP-0352 case, "Nonzas" could get lost without resending them >> > upon stream resumption, leaving the client under the impression that >> > it's active, although the server thinks it's inactive. >> This can't happen, because new streams are always active by default. I >> really thought this was clear in the XEP, but actually it's a little >> bit ambiguous. > > This looks to me like a restriction caused by using nonzas in the first > place (and the inability to track them in 0198), not like something > which makes sense from a protocol desgin view point. > > As a client developer, I would expect the stream to be in the same state > it was before resumption, as stream resumption is caused by network > interruptions and has nothing to do with user/client activity. It depends whether you view CSI as a property of the stream or not (which it is currently considered to be). If you "expect the stream to be in the same state", would you also expect to not have to renegotiate compression on a resumed stream? Regards, Matthe
Re: [Standards] Nonzas: What are they and do we need them?
* Matthew Wild [2015-04-20 18:33]: > > In the XEP-0352 case, "Nonzas" could get lost without resending them > > upon stream resumption, leaving the client under the impression that > > it's active, although the server thinks it's inactive. > This can't happen, because new streams are always active by default. I > really thought this was clear in the XEP, but actually it's a little > bit ambiguous. This looks to me like a restriction caused by using nonzas in the first place (and the inability to track them in 0198), not like something which makes sense from a protocol desgin view point. As a client developer, I would expect the stream to be in the same state it was before resumption, as stream resumption is caused by network interruptions and has nothing to do with user/client activity. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature
Re: [Standards] Nonzas: What are they and do we need them?
On 20 April 2015 at 17:22, Christian Schudt wrote: > But...: As Georg pointed out, I also think the biggest problem is, that they > are not tracked by XEP-0198. > In the XEP-0352 case, "Nonzas" could get lost without resending them upon > stream resumption, leaving the client under the impression that it's active, > although the server thinks it's inactive. This can't happen, because new streams are always active by default. I really thought this was clear in the XEP, but actually it's a little bit ambiguous. Regards, Matthew
Re: [Standards] Nonzas: What are they and do we need them?
On 4/20/15 7:27 AM, Florian Schmaus wrote: In order to make the following easier, I'd first like to define the term Nonza: A Nonza is every top level XMPP stream element which is not a Stanza. (see also [1]). Thanks for the fun neologism. :-) Now we just need to figure out what a "wowza" is... To my best knowledge, Nonzas which are exchanged after resource binding, are currently used in xep198 I think nonzas make sense in stream management because you don't want your counters to get mixed up with the things you're counting. and xep352. I don't see a good reason to use nonzas for indicating client state. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] Nonzas: What are they and do we need them?
> For me personally, the contra-Nonza arguments did not convince me. It > appears that nothing in the specification prevents you from using Nonzas > after resource binding with BOSH. XEP-206 3. only says "SHOULD contain". > I also don't see why they would introduce "a bunch of conceptual and > implementations problems". I agree with you. The contra arguments are weak. I think Prosody even advertises XEP-0198 over BOSH, so clients would use it. And I also see no implementation problems. But...: As Georg pointed out, I also think the biggest problem is, that they are not tracked by XEP-0198. In the XEP-0352 case, "Nonzas" could get lost without resending them upon stream resumption, leaving the client under the impression that it's active, although the server thinks it's inactive. Theoretically your rules could be applied to XEP-0186 Invisile Command or XEP-0280 as well. Or even more XEPs, maybe like Blocking Command. (all of which uses elements, which don't get routed). I see problems with having neither IQ responses nor the XEP-0198 reliability, when using "Nonzas". Oh and I'd prefer to just call them (top-level) XML elements, or Stream elements. Nonza sounds really weird. There's no need to invent a new name, imo. -Christian
Re: [Standards] Nonzas: What are they and do we need them?
* Florian Schmaus [2015-04-20 15:27]: > Contra: > - Messages and IQs could be used instead > - Can't be used with BOSH As you pointed out below, they can be used in theory. I just assume that most implementations will not expect them and might break in subtle ways. IIRC, it required significant refactoring of the Smack XMPP library to accommodate them. I'm sure similar effort will be required in most other XMPP client and server implementations. > - Introduces a bunch of conceptual and implementations problems One specific problem is that they can not be accounted for in XEP-0198, and therefore it is not clear if a Nonza got successfully delivered to the recipient in case of stream resumption. In the CSI discussion this caused confusion and led to the notion of resetting the CSI state on stream resumption, which looks like fixing the symptoms. > Pro: > - Expresses the semantic that they are not routed > - This increases security, as they are harder to spoof I understand the first two points, but I'm not sure if they really outweigh the problems. > A. Nonzas MUST NOT be used after resource binding With the obvious exception of XEP-0198, of course. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e h- r++ y? || ++ IRCnet OFTC OPN ||_|| signature.asc Description: Digital signature
