Re: [Standards] RFC 6120 vs. XEP
Mon, 6 Feb 2017 16:46:58 -0700 Peter Saint-Andre wrote: > tl;dr Let's do the best we can on Bind2 and then cross the IETF > bridge when we come to it. If the issue is to be addressed, it's fine by me. ___ 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] RFC 6120 vs. XEP
RFC 6120 author here. :-) In a message not quoted below, Kev said "Nothing stops further specs from changing the core rules by negotiation. This is not a violation, it’s agreeing to do something different." I tend to agree that the main point of stream feature negotiation is to make it possible to improve how we start up a session by adding new and better features over time. That's the whole idea of discovery (and stream features are a kind of discovery before you can use disco). Note that the order of features matters. In the Bind2 proposal, the order is this: Thus, if a client and server both support Bind2, the client could use Bind2 instead of 6120 binding. In RFC 6120, "mandatory-to-negotiate" does not mean that we can never replace such a feature, it means that the initiating entity must use the feature if it hasn't already negotiated something equivalent with the receiving entity. In this case, the client would use Bind2 and the server would not offer 6120 binding afterward. Therefore I see nothing in Bind2 that is technically problematic in this respect. Further process comments below. On 2/6/17 1:37 PM, Marvin Gülker wrote: On Mon, Feb 06, 2017 at 06:09:50PM +0300, Evgeny Khramtsov wrote: 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. Yes. An extension is something building on top of the RFC, not contradicting it. This is not really a contradiction, it is an intended improvement (without using the same namespace - *that* would be a contradiction) and eventual replacement. The word "eventual" is important here. What is not spelled out here, but I guess what is behind Kevin's position, is that amending RFC 6120 would be a time-consuming process as it needs to go through the IETF. Having authored both RFC 3920 and RFC 6120, I know better than anyone else here that updating or replacing RFCs is indeed time consuming. :) However, I don't think that's the main issue here. Indeed, we have always planned to publish an RFC that replaces 6120 and includes some fixes we know are needed (most of them relatively small). This Bind2 work would merely add to the list of changes. In the current changing world of mobile messaging, a time-consuming standardisation process is the last the XMPP universe needs. I can see this point, but in my opinion the approach taken currently is the wrong answer to this. RFC 6120 has the advantage that it covers and consolidates quite a lot of functionality (together with RFC 6121) at a central point. What happens currently is that parts of the RFC are superseded by some XEP here, another XEP there, etc. The result is an organisational mess. In the past the XSF has worked on proposals to update or improve core features of the streaming protocols - see for example XEPs 29, 32, 34 and 35. This enabled the community to experiment with improvements and then port them over to the RFC when we obtained some implementation and deployment experience. If replacing RFC 6120f. is what is wanted anyway, then why not make some kind of "super-XEP" that consolidates the entire thing into one document people can be pointed to, and have that document explicitely state "this XEP obsoletes and supersedes RFC 6120 for any modern use of XMPP; implementation of RFC 6120 is discouraged". It's not the place of the XSF to obsolete RFCs, because since 2002 we have worked closely with the IETF to standardize core work there. Preferably, the IETF should be asked to retire the RFC 6120 group. This sets things straight again and kicks the IETF out of the standardisation boat, where it appearently causes more problems than it helps. Our work with the IETF has been very beneficial, especially with regard to security because we have received input from security experts. That's not to say it is always easy, but it has led to stronger security (up to and including RFC 7590 / RFC 7525). If this sounds too radical, why not just submit the changes of the XEPs in question to the IETF and have a note in the XEPs that they defer to the resulting RFC once it has been approved by the IETF? After all, RFC 6120 has aged a little since it was published in 2011. Although in practice it's not quite that simple, in theory what I would propose is similar: let's define Bind2 to the best of our abilities in the XSF and gain some implementation and deployment experience with it, which we can do in a way that does not contradict RFC 6120 (see above) by using a separate namespace. In parallel, let's also figure out what other improvements are needed to RFC 6120 and RFC 6121 (to date I think the proposed fixes have been relatively minor - Bind2 would be the largest of the changes). Then, we start the process of formally updating the core RFCs. This will probably
Re: [Standards] RFC 6120 vs. XEP (was: CSI and Carbons state after SM resumption)
On Mon, Feb 06, 2017 at 06:09:50PM +0300, Evgeny Khramtsov wrote: > 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. Yes. An extension is something building on top of the RFC, not contradicting it. What is not spelled out here, but I guess what is behind Kevin's position, is that amending RFC 6120 would be a time-consuming process as it needs to go through the IETF. In the current changing world of mobile messaging, a time-consuming standardisation process is the last the XMPP universe needs. I can see this point, but in my opinion the approach taken currently is the wrong answer to this. RFC 6120 has the advantage that it covers and consolidates quite a lot of functionality (together with RFC 6121) at a central point. What happens currently is that parts of the RFC are superseded by some XEP here, another XEP there, etc. The result is an organisational mess. If replacing RFC 6120f. is what is wanted anyway, then why not make some kind of "super-XEP" that consolidates the entire thing into one document people can be pointed to, and have that document explicitely state "this XEP obsoletes and supersedes RFC 6120 for any modern use of XMPP; implementation of RFC 6120 is discouraged". Preferably, the IETF should be asked to retire the RFC 6120 group. This sets things straight again and kicks the IETF out of the standardisation boat, where it appearently causes more problems than it helps. If this sounds too radical, why not just submit the changes of the XEPs in question to the IETF and have a note in the XEPs that they defer to the resulting RFC once it has been approved by the IETF? After all, RFC 6120 has aged a little since it was published in 2011. Greetings Marvin (second attempt in changing the discussion title of this subthread) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. Bind2 XEP (was: CSI and Carbons state after SM resumption)
> On 6 Feb 2017, at 14:53, Marvin Gülker wrote: > Someone creating a new XMPP client naturally starts by > implementing RFC 6120, only to discover that it is obsoleted by > practice. But they would still interoperate, because 6120 is the baseline. Bind2 is not the only extension to 6120 that someone needs to implement to make a usable modern client. /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 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] RFC 6120 vs. Bind2 XEP (was: CSI and Carbons state after SM resumption)
Mon, 6 Feb 2017 15:53:41 +0100 Marvin Gülker wrote: > Someone creating a new XMPP client naturally starts by > implementing RFC 6120, only to discover that it is obsoleted by > practice. That's my main concern actually, not because I'm fastidious ;) ___ 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] RFC 6120 vs. Bind2 XEP (was: CSI and Carbons state after SM resumption)
On Mon, Feb 06, 2017 at 03:25:15PM +0300, Evgeny Khramtsov wrote: > 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. I tend to agree with this. RFC 6120, section 7.1. says that clients must do resource binding, section 7.2. declares support for it mandatory in the client, and in section 7.4. it is definitely stated that (hilight by me) > [...] the server MUST include a > element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace > in the stream features it presents to the client. > [...] > Upon being informed that resource binding is mandatory-to-negotiate, > the client MUST bind a resource to the stream as described in the > following sections. This, in my opinion, means that RFC 6120 has to be officially amended to support Bind2 as in case of conflicts between a XEP and the RFC, the RFC must take precedence. Apart from the formal argument, disregarding RFC 6120 and revising core XMPP functionality via a XEP means that a good part of RFC 6120 (namely section 7) does not reflect the reality anymore when Bind2 is accepted. Someone creating a new XMPP client naturally starts by implementing RFC 6120, only to discover that it is obsoleted by practice. I do think that such severe revisions deserve a note in the RFC. Greetings Marvin ___ 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 ___
