Re: [Standards] CSI and Carbons state after SM resumption
On 06.02.2017 10:31, Georg Lukas wrote: > * Sam Whited [2017-02-06 10:15]: >>> Ah right, another unfortunate design decision. >> >> Not at all; the nonzas are semantically correct here because it >> doesn't make sense to have the CSI enable/disable "commands" be >> routable. > > I principally agree with your point, and I'm not explicitly blaming CSI > for using nonzas. On the other hand, nonzas were introduced in 0198 as a > kind of meta-element that is required to count actual elements without > interfering with them, and now CSI ended up (ab)using them as well. > > If I were going to redesign everything in XMPP, I'd probably > differentiate between "stanzas" (routable elements), "nonzas" (non- > routed elements between the user's client and their server; these > could also be used for other XEPs like Carbons to avoid devs' security > sloppyness), and "SM nonzas" which are the only ones explicitly excempt > from XEP-0198 counters. That ^ I would seriously consider this change if we ever do a version bump of XEP-0198 Stream Management. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Tue, Feb 07, 2017 at 10:35:50AM -0600, Sam Whited wrote: > On Tue, Feb 7, 2017 at 7:20 AM, Matthew Wild wrote: > > Session state pertains to a user's account: > > > > - Roster > > - Privacy/block lists > > - Private XML > > - PEP > > - ... > > I think the roster generally exists and is the same across sessions; > it's more "account state"; or I may just have a different > understanding of what "session" means. Not that it matters for this > discussion. Some of those have state attached to the session, like whether to receive roster updates or the currently active privacy list. -- Kim "Zash" Alvefur signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Tue, Feb 7, 2017 at 7:20 AM, Matthew Wild wrote: > Stream state pertains to a single stream/connection: > > - encrypted > - authenticated > - compressed > - bound > - active/inactive Yes, you're right of course, CSI is more "stream state", my mistake. Thanks! > Session state pertains to a user's account: > > - Roster > - Privacy/block lists > - Private XML > - PEP > - ... I think the roster generally exists and is the same across sessions; it's more "account state"; or I may just have a different understanding of what "session" means. Not that it matters for this discussion. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On 7 February 2017 at 04:50, Sam Whited wrote: > On Mon, Feb 6, 2017 at 3:53 AM, Evgeny Khramtsov wrote: >> And do I have privacy list with another entity? Private XML storage? In >> more general, why couldn't an external component maintain my CSI state >> via XEP-0356? > > I think the difference is that CSI is a part of the session state, Yes, but I think a lack of standard terminology clouds discussion here. In my mind (as author and implementer of CSI) there are indeed different levels of state, to me: stream state and session state. Stream state pertains to a single stream/connection: - encrypted - authenticated - compressed - bound - active/inactive Session state pertains to a user's account: - Roster - Privacy/block lists - Private XML - PEP - ... In general, in the context of XEP-0198, stream state does *not* carry after resumption, but session state does. Binding is about the only exception to this. In general, stream state is managed through nonzas, and session state through stanzas (typically addressed to the user's account JID, but sometimes to another service). Carbons is an example of something I'd consider stream state that is managed through a stanza. Fetching a roster from your account also has special effects on the stream state. The reality is that no, XMPP is not 100% consistent, no system designed through collaboration of so many individuals over nearly two decades ever could be. But I still think we've done a pretty good job, and we're continuing to learn and iterate - bind2 is a part of this. Regards, Matthew ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Mon, Feb 6, 2017 at 3:53 AM, Evgeny Khramtsov wrote: > And do I have privacy list with another entity? Private XML storage? In > more general, why couldn't an external component maintain my CSI state > via XEP-0356? I think the difference is that CSI is a part of the session state, which should always stay with the server (in my mind), while a roster is just a "list" that we're requesting (and is more or less independant of the session). However, your argument is fair, if we think it makes sense for multiple entities to handle CSI, maybe an IQ is the correct choice. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
Mon, 6 Feb 2017 14:57:10 + Kevin Smith wrote: > Not really, that’s just how extensions work. I disagree. Extensions should extend, not replace, the RFC. Replacing RFCs by XEPs is some new phenomenon introduced in recent years. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On 6 Feb 2017, at 12:25, Evgeny Khramtsov wrote: > > Mon, 6 Feb 2017 12:03:15 + > Kevin Smith wrote: > >> Nothing stops further specs from changing the core rules by >> negotiation. This is not a violation, it’s agreeing to do something >> different. > > I guess that's your opinion? Or where is it stated in the RFC? xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> is a mandatory-to-negotiate > feature (at least if included), thus, clients MUST NOT ignore it. Not really, that’s just how extensions work. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
Mon, 6 Feb 2017 12:03:15 + Kevin Smith wrote: > Nothing stops further specs from changing the core rules by > negotiation. This is not a violation, it’s agreeing to do something > different. I guess that's your opinion? Or where is it stated in the RFC? is a mandatory-to-negotiate feature (at least if included), thus, clients MUST NOT ignore it. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On 6 Feb 2017, at 12:01, Evgeny Khramtsov wrote: > > Mon, 6 Feb 2017 12:44:49 +0100 > Florian Schmaus wrote: > >> Maybe I don't understand the question, but Bind2 still does resource >> binding. > > Yes, but in a different way. While RFC6120 tells how to *exactly* bind > a resource: > >> the client MUST bind a resource to the stream as described in the >> following sections > > Furthermore, XEP-0198 already violates this requirement on > stream resumption. Nothing stops further specs from changing the core rules by negotiation. This is not a violation, it’s agreeing to do something different. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
Mon, 6 Feb 2017 12:44:49 +0100 Florian Schmaus wrote: > Maybe I don't understand the question, but Bind2 still does resource > binding. Yes, but in a different way. While RFC6120 tells how to *exactly* bind a resource: > the client MUST bind a resource to the stream as described in the > following sections Furthermore, XEP-0198 already violates this requirement on stream resumption. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On 06.02.2017 10:05, Evgeny Khramtsov wrote: > Mon, 6 Feb 2017 09:22:22 +0100 > Dave Cridland wrote: > >> A combination of bind 2 and SASL 2 will sort this out. > > I'm wondering how all this new shiny stuff deals with RFC6120 > where, for example, resource binding is a MUST? Maybe I don't understand the question, but Bind2 still does resource binding. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On 06.02.2017 10:13, Kim Alvefur wrote: > On Sun, Feb 05, 2017 at 08:53:31PM +0100, Florian Schmaus wrote: >> On 05.02.2017 20:19, Georg Lukas wrote: >>> * Florian Schmaus [2017-02-05 19:41]: I've just submitted https://github.com/xsf/xeps/pull/402 >>> >>> I really really don't understand why 0198 should change any of the >>> session properties on resumption. This should be as transparent to the >>> client as any possible. >> >> CSI uses Nonzas, which are not covered by Stream Management, so you >> can't restore the CSI state after resumption. > > Can't? Why not? You don't know if the CSI nonza you sent right before the stream got interrupted was processed by the server or not. That said, I think you could do what XEP-0352 § 5.1 describes and only mark the CSI state change successful after you received a pong of a ping you send just after the CSI state change nonza. If everybody would do that, then we could say we restore the CSI state. But I don't believe that to be an option, since we can't enforce everybody to do it, - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
Mon, 6 Feb 2017 10:32:22 +0100 Kim Alvefur wrote: > ... you can have a roster with another entity, for example a transport > to another IM network. And do I have privacy list with another entity? Private XML storage? In more general, why couldn't an external component maintain my CSI state via XEP-0356? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Mon, Feb 6, 2017 at 3:16 AM, Evgeny Khramtsov wrote: > What does that "routable" mean? Are roster queries "routable"? Able to be forwarded by the server to another entity on the network on behalf of the sender. Only stanza's (message/presence/iq) with a "to" attribute are forwardable. Things that aren't encapsulated in a stanza, like those used in CSI, are not. Roster queries are routable; to repeat the current room discussion for context: I think it's possible to have a roster with a different entity as well as the main one on the server, however, nothing does this that I'm aware of (maybe that's something for MIX to consider). —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Mon, Feb 06, 2017 at 12:16:31PM +0300, Evgeny Khramtsov wrote: > Mon, 6 Feb 2017 03:14:54 -0600 > Sam Whited wrote: > > > Not at all; the nonzas are semantically correct here because it > > doesn't make sense to have the CSI enable/disable "commands" be > > routable. > > What does that "routable" mean? That they can be sent to another entity, anywhere on the XMPP network. Usually they are only routed between your client and your account, but... > Are roster queries "routable"? ... you can have a roster with another entity, for example a transport to another IM network. -- Zash signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
* Sam Whited [2017-02-06 10:15]: > > Ah right, another unfortunate design decision. > > Not at all; the nonzas are semantically correct here because it > doesn't make sense to have the CSI enable/disable "commands" be > routable. I principally agree with your point, and I'm not explicitly blaming CSI for using nonzas. On the other hand, nonzas were introduced in 0198 as a kind of meta-element that is required to count actual elements without interfering with them, and now CSI ended up (ab)using them as well. If I were going to redesign everything in XMPP, I'd probably differentiate between "stanzas" (routable elements), "nonzas" (non- routed elements between the user's client and their server; these could also be used for other XEPs like Carbons to avoid devs' security sloppyness), and "SM nonzas" which are the only ones explicitly excempt from XEP-0198 counters. 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 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
Mon, 6 Feb 2017 03:14:54 -0600 Sam Whited wrote: > Not at all; the nonzas are semantically correct here because it > doesn't make sense to have the CSI enable/disable "commands" be > routable. What does that "routable" mean? Are roster queries "routable"? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Sun, Feb 5, 2017 at 2:07 PM, Georg Lukas wrote: > * Florian Schmaus [2017-02-05 20:54]: >> CSI uses Nonzas, which are not covered by Stream Management, so you >> can't restore the CSI state after resumption. > > Ah right, another unfortunate design decision. Not at all; the nonzas are semantically correct here because it doesn't make sense to have the CSI enable/disable "commands" be routable. If CSI were an IQ like the Google version and you accidentally sent one to another client, what does that even mean? Probably nothing. And while most likely nothing bad will happen, that's just "most likely". The more things we can make sure the server handles without having to special case it (eg. the current bind IQ) the better. Of course, as this thread demonstrates there are problems with this to solve, however, we should do just that: solve them, not take an easy way out that introduces its own slightly different issues. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On Sun, Feb 05, 2017 at 08:53:31PM +0100, Florian Schmaus wrote: > On 05.02.2017 20:19, Georg Lukas wrote: > > * Florian Schmaus [2017-02-05 19:41]: > >> I've just submitted https://github.com/xsf/xeps/pull/402 > > > > I really really don't understand why 0198 should change any of the > > session properties on resumption. This should be as transparent to the > > client as any possible. > > CSI uses Nonzas, which are not covered by Stream Management, so you > can't restore the CSI state after resumption. Can't? Why not? -- Zash signature.asc Description: PGP signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
Mon, 6 Feb 2017 09:22:22 +0100 Dave Cridland wrote: > A combination of bind 2 and SASL 2 will sort this out. I'm wondering how all this new shiny stuff deals with RFC6120 where, for example, resource binding is a MUST? ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
A combination of bind 2 and SASL 2 will sort this out. On 5 Feb 2017 21:07, "Georg Lukas" wrote: > * Florian Schmaus [2017-02-05 20:54]: > > CSI uses Nonzas, which are not covered by Stream Management, so you > > can't restore the CSI state after resumption. > > Ah right, another unfortunate design decision. > > ___ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > ___ > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
* Florian Schmaus [2017-02-05 20:54]: > CSI uses Nonzas, which are not covered by Stream Management, so you > can't restore the CSI state after resumption. Ah right, another unfortunate design decision. signature.asc Description: Digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
On 05.02.2017 20:19, Georg Lukas wrote: > * Florian Schmaus [2017-02-05 19:41]: >> I've just submitted https://github.com/xsf/xeps/pull/402 > > I really really don't understand why 0198 should change any of the > session properties on resumption. This should be as transparent to the > client as any possible. CSI uses Nonzas, which are not covered by Stream Management, so you can't restore the CSI state after resumption. - Florian signature.asc Description: OpenPGP digital signature ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] CSI and Carbons state after SM resumption
* Florian Schmaus [2017-02-05 19:41]: > I've just submitted https://github.com/xsf/xeps/pull/402 I really really don't understand why 0198 should change any of the session properties on resumption. This should be as transparent to the client as any possible. 0198 simply happens when the user is roaming networks, or when their DSL connection is force-reconnected by an evil ISP. In an ideal world, this would be handled transparently by the XMPP client library without even notifying the client application. In a less ideal world, we can at least make it keep the session state as-is. If we have every XEP define the post-resumption behavior, we are going straight into madness land. It would mean that the client needs to special-case resumption with a list of "crazy" XEPs that just forget their state, and push the according state over the wire a-new (or that the library needs to cache the respective state on behalf of the client and perform this black magic). For a mobile client, most 0198 resumptions happen without the user interacting with the client at all, and there is really no reason to assume that the logical CSI state changes beteen "home wifi" and "mobile"... 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 ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___