Re: [Standards] RFC 6120 vs. XEP
On 8 February 2017 at 08:53, Evgeny Khramtsov wrote: > Wed, 8 Feb 2017 08:19:17 + > Dave Cridland wrote: > >> Right, I understand, and largely agree. I might scribble a draft to >> address this, by clarifying what we really meant here. > > I see also two issues here ;) > Yup, I understand what you're saying, and I agree that's an entirely reasonable interpretation of the document. It's also clearly against the spirit of our understanding, otherwise, as you say, XEP-0198 would have also run into this problem. It's also not what we want. Given that, I'm suggesting this is a technical errata in RFC 6120. > 1. RFC6120, section 7.1 says: > >> After a client authenticates with a server, it MUST bind a specific >> resource to the stream so that the server can properly address the >> client. > > Thus, a client is unable to resume a session in any case. > > 2. While almost everybody here argued that "resource binding" is any > binding mechanism, including Bind2, RFC6120 clearly defines "resource > binding": > > Section 7.3.1: > >> The parties to a stream MUST consider resource binding as mandatory- >> to-negotiate. > > And section 7.1 defines: > >> The XML namespace name for the resource binding extension is >> 'urn:ietf:params:xml:ns:xmpp-bind'. > > In my book, "resource binding" is exactly something within > 'urn:ietf:params:xml:ns:xmpp-bind' namespace, unambiguously. > ___ > 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] RFC 6120 vs. XEP
On 08.02.2017 21:42, Evgeny Khramtsov wrote: Wed, 8 Feb 2017 20:06:19 +0100 "Ruslan N. Marchenko" wrote: RFC restricts nowhere binding process to this extension Actually it does, Section 14.4: 14 is a namespace section, so apparently it defines namespace relevant to the given RFC. A URN sub-namespace for resource binding in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in [XML-REG].) URI: urn:ietf:params:xml:ns:xmpp-bind Here, the word "extension" is omited, so it will be harder to juggle with words pretending you're making an argument ;) I still don't see it as a requirement. Requirements are in section 7. And here real noncompliance lays afaik just at 7.3.2, SM does not follow this rule for obvious reason. Although stream restart is not a big overhead and again - does not mandate session restart. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Wed, 8 Feb 2017 20:06:19 +0100 "Ruslan N. Marchenko" wrote: > RFC restricts nowhere > binding process to this extension Actually it does, Section 14.4: > A URN sub-namespace for resource binding in the Extensible Messaging > and Presence Protocol (XMPP) is defined as follows. (This namespace > name adheres to the format defined in [XML-REG].) > URI: urn:ietf:params:xml:ns:xmpp-bind Here, the word "extension" is omited, so it will be harder to juggle with words pretending you're making an argument ;) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Allow me to put my two cents On 08.02.2017 09:53, Evgeny Khramtsov wrote: Wed, 8 Feb 2017 08:19:17 + Dave Cridland wrote: Right, I understand, and largely agree. I might scribble a draft to address this, by clarifying what we really meant here. I see also two issues here ;) 1. RFC6120, section 7.1 says: After a client authenticates with a server, it MUST bind a specific resource to the stream so that the server can properly address the client. Thus, a client is unable to resume a session in any case. I think the misunderstanding roots in similarity of the BINDing requirement and BINDing process (using IQ with BINDing extension namespace). Resumption *IS* doing binding. After resumption - connection is uniquely bound and addressable. No RFC violation. In fact server implementation may execute similar calls to bind newly authenticated connection to existing session. 2. While almost everybody here argued that "resource binding" is any binding mechanism, including Bind2, RFC6120 clearly defines "resource binding": Section 7.3.1: The parties to a stream MUST consider resource binding as mandatory- to-negotiate. Yes, this is where SM should be mandatory to negotiate. Currently it's just written as a fallback condition (failure to resume must be followed by proper binding) And section 7.1 defines: The XML namespace name for the resource binding extension is 'urn:ietf:params:xml:ns:xmpp-bind'. Yes, for the extension which is described by RFC, RFC restricts nowhere binding process to this extension, just tells it's mandatory to negotiate. I.e. any RFC6120 compatible server and client MUST support this extension for the binding purpose. But aren't limited to that. In my book, "resource binding" is exactly something within 'urn:ietf:params:xml:ns:xmpp-bind' namespace, unambiguously. ___ 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] RFC 6120 vs. XEP
Wed, 8 Feb 2017 08:19:17 + Dave Cridland wrote: > Right, I understand, and largely agree. I might scribble a draft to > address this, by clarifying what we really meant here. I see also two issues here ;) 1. RFC6120, section 7.1 says: > After a client authenticates with a server, it MUST bind a specific > resource to the stream so that the server can properly address the > client. Thus, a client is unable to resume a session in any case. 2. While almost everybody here argued that "resource binding" is any binding mechanism, including Bind2, RFC6120 clearly defines "resource binding": Section 7.3.1: > The parties to a stream MUST consider resource binding as mandatory- > to-negotiate. And section 7.1 defines: > The XML namespace name for the resource binding extension is > 'urn:ietf:params:xml:ns:xmpp-bind'. In my book, "resource binding" is exactly something within 'urn:ietf:params:xml:ns:xmpp-bind' namespace, unambiguously. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Right, I understand, and largely agree. I might scribble a draft to address this, by clarifying what we really meant here. On 8 Feb 2017 06:30, "Evgeny Khramtsov" wrote: > Tue, 7 Feb 2017 21:22:17 + > Dave Cridland wrote: > > > On 7 February 2017 at 16:29, Evgeny Khramtsov > > wrote: > > > Tue, 7 Feb 2017 19:18:39 +0300 > > > Evgeny Khramtsov wrote: > > >> Indeed (section 4.3.2). Then we're ok here *if* we make Bind2 > > >> mandatory-to-negotiate. > > > > > > For the record, it should be also pointed in XEP-0198 that > > > feature is mandatory to negotiate. > > > > I'm missing something - why would need to be mandatory to > > negotiate? > > Seems like everybody is missing something on this topic :) > Let me describe how I see it. Let's say a client gets the following > features (copied from XEP-0198): > > > > > > > In this case, RFC6120, Section 7.4 states: > > > 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. > > Thus, a client MUST bind a resource, it cannot resume a session. > However, Section 4.3.2 says: > > > A element MAY contain more than one mandatory-to- > > negotiate feature. This means that the initiating entity can choose > > among the mandatory-to-negotiate features at this stage of the stream > > negotiation process. > > Thus, if is mandatory-to-negotiate, a client is not required to > a resource because and is now free to choose which > mandatory feature to negotiate. So it may resume session in this case > without binding. > ___ > 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] RFC 6120 vs. XEP
Tue, 7 Feb 2017 21:22:17 + Dave Cridland wrote: > On 7 February 2017 at 16:29, Evgeny Khramtsov > wrote: > > Tue, 7 Feb 2017 19:18:39 +0300 > > Evgeny Khramtsov wrote: > >> Indeed (section 4.3.2). Then we're ok here *if* we make Bind2 > >> mandatory-to-negotiate. > > > > For the record, it should be also pointed in XEP-0198 that > > feature is mandatory to negotiate. > > I'm missing something - why would need to be mandatory to > negotiate? Seems like everybody is missing something on this topic :) Let me describe how I see it. Let's say a client gets the following features (copied from XEP-0198): In this case, RFC6120, Section 7.4 states: > 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. Thus, a client MUST bind a resource, it cannot resume a session. However, Section 4.3.2 says: > A element MAY contain more than one mandatory-to- > negotiate feature. This means that the initiating entity can choose > among the mandatory-to-negotiate features at this stage of the stream > negotiation process. Thus, if is mandatory-to-negotiate, a client is not required to a resource because and is now free to choose which mandatory feature to negotiate. So it may resume session in this case without binding. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
On 7 February 2017 at 16:29, Evgeny Khramtsov wrote: > Tue, 7 Feb 2017 19:18:39 +0300 > Evgeny Khramtsov wrote: > >> Tue, 7 Feb 2017 09:57:07 -0600 >> Sam Whited wrote: >> >> > The rules for required stream features say that if multiple required >> > features are listed, the client picks between them. In this case, >> > clients that support it would simply pick the new bind mechanism and >> > 6120 is perfectly satisfied. >> >> Indeed (section 4.3.2). Then we're ok here *if* we make Bind2 >> mandatory-to-negotiate. > > For the record, it should be also pointed in XEP-0198 that > feature is mandatory to negotiate. I'm missing something - why would need to be mandatory to negotiate? Dave. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
On 2/7/17 9:18 AM, Evgeny Khramtsov wrote: Tue, 7 Feb 2017 09:57:07 -0600 Sam Whited wrote: The rules for required stream features say that if multiple required features are listed, the client picks between them. In this case, clients that support it would simply pick the new bind mechanism and 6120 is perfectly satisfied. Indeed (section 4.3.2). Then we're ok here *if* we make Bind2 mandatory-to-negotiate. Yes, this is an important part of the story! ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Tue, 7 Feb 2017 19:18:39 +0300 Evgeny Khramtsov wrote: > Tue, 7 Feb 2017 09:57:07 -0600 > Sam Whited wrote: > > > The rules for required stream features say that if multiple required > > features are listed, the client picks between them. In this case, > > clients that support it would simply pick the new bind mechanism and > > 6120 is perfectly satisfied. > > Indeed (section 4.3.2). Then we're ok here *if* we make Bind2 > mandatory-to-negotiate. For the record, it should be also pointed in XEP-0198 that feature is mandatory to negotiate. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Tue, 7 Feb 2017 09:57:07 -0600 Sam Whited wrote: > The rules for required stream features say that if multiple required > features are listed, the client picks between them. In this case, > clients that support it would simply pick the new bind mechanism and > 6120 is perfectly satisfied. Indeed (section 4.3.2). Then we're ok here *if* we make Bind2 mandatory-to-negotiate. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
On Tue, Feb 7, 2017 at 9:15 AM, Evgeny Khramtsov wrote: > The problem is, formally speaking, it cannot ignore RFC's binding, > because there are MUSTs in the document (Marvin already listed them). Not at all; from 6120: > Support for resource binding is REQUIRED in XMPP client and server > implementations. We're not violating this by introducing a new bind mechanism, you just have to support the old one too (which you'd want to do anyways for interoperability, as Peter said) > After a client authenticates with a server, it MUST bind a specific resource > to the stream so that the server can properly address the client. And we're not violating this, because the client is still binding a resource (just with a different mechanism, or possibly with the old one still if it doesn't support the new one). The rules for required stream features say that if multiple required features are listed, the client picks between them. In this case, clients that support it would simply pick the new bind mechanism and 6120 is perfectly satisfied. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
On 2/7/17 8:15 AM, Evgeny Khramtsov wrote: Tue, 7 Feb 2017 14:04:59 +0100 Ralph Meijer wrote: A client that understands Bind2 can simply see the feature appearing next to the RFC 6120 one, and choose to negotiate it instead of that. The problem is, formally speaking, it cannot ignore RFC's binding, because there are MUSTs in the document (Marvin already listed them). A client needs to bind a resource. RFC 6120 does not and cannot forbid anyone from defining and experimenting with an alternative binding mechanism (among other things, this is why we use namespaces). If those experiments lead to improved functionality, then we'll consider porting Bind2 to rfc6120bis. There are no protocol police and I'm not sure why we'd want them to shut down useful experiments. Peter ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Tue, 7 Feb 2017 14:04:59 +0100 Ralph Meijer wrote: > A client that understands Bind2 can simply see the feature appearing > next to the RFC 6120 one, and choose to negotiate it instead of that. The problem is, formally speaking, it cannot ignore RFC's binding, because there are MUSTs in the document (Marvin already listed them). ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
On 2/7/17 5:41 AM, Marvin Gülker wrote:
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.
Okay, I get this now. Clients and servers are not supposed to drop
original RFC 6120 binding support.
Of course not - interoperability matters. After all, there are still
servers and clients that support pre-SASL authentication and other
ancient protocols. Extensibility enables us to improve things over time.
If it weren't for this "as described
in the following sections" in RFC 6120 I could accept your understanding
of the text, but it still is unsatisfactory to interpret "MUST bind a
specific resource to the stream" in section 7.1 as meaning "with any
resource binding process, be it RFC 6120 bind or something later defined
in a XEP", and interpreting "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" in section 7.4 differently as
meaning "only if you want to do RFC 6120 resource binding you have to
follow the following sections". In both cases, the similar use of terms
("bind a resource" vs. "resource binding") suggests that the terms are
intended to mean the same, not different things.
At the time we wrote RFC 3920 and RFC 6120, we didn't envision defining
another resource binding mechanism. C'est la vie.
Don't get me wrong. I'm not trying to troll you, I just have the
impression that the your original intention doesn't show up as clear in
RFC 6120 as it should.
Hey, I only spent 3,000+ hours on RFC 3920 and RFC 6120. There's always
room for improvement.
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).
By no means I meant to discredit the IETF. I just wanted to make a
suggestion in case the IETF is perceived as too slow. I did not mean to
imply that. I'm sorry, and yes, the security improvements are definitely
very important.
The IETF is always perceived as slow. The XSF is perceived as slow, too.
Standards take time. We used to do things much more quickly, though
(compare MUC to MIX or 3920 to 6120).
tl;dr Let's do the best we can on Bind2 and then cross the IETF bridge when
we come to it.
I agree with Evgeny in this regard: with this, all my points become void
anyway. Let's make XMPP better together!
+1
Peter
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
Re: [Standards] RFC 6120 vs. XEP
On 2/7/17 6:04 AM, Ralph Meijer wrote: On 07-02-17 13:41, Marvin Gülker wrote: Hi, On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote: RFC 6120 author here. :-) Great! :-) Note that the order of features matters. In the Bind2 proposal, the order is this: I have to disagree. RFC 6120, section 4.3.2 says this, though it is marked as an Implementation Note: Implementation Note: The order of child elements contained in any given element is not significant. Thus, I'm not really sure whether I agree with your understanding of RFC 6120's text. I don't see why this is a debate at all. The order isn't even relevant. A client that understands Bind2 can simply see the feature appearing next to the RFC 6120 one, and choose to negotiate it instead of that. A protocol is an agreement on how to do things. The agreement here is to bind a resource *instead of the original way*. If the server advertises it and the client uses it, you're done. Yes. Sorry about the error regarding 6120 rules - I should know them by heart. :-) ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
On 07-02-17 13:41, Marvin Gülker wrote: Hi, On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote: RFC 6120 author here. :-) Great! :-) Note that the order of features matters. In the Bind2 proposal, the order is this: I have to disagree. RFC 6120, section 4.3.2 says this, though it is marked as an Implementation Note: Implementation Note: The order of child elements contained in any given element is not significant. Thus, I'm not really sure whether I agree with your understanding of RFC 6120's text. I don't see why this is a debate at all. The order isn't even relevant. A client that understands Bind2 can simply see the feature appearing next to the RFC 6120 one, and choose to negotiate it instead of that. A protocol is an agreement on how to do things. The agreement here is to bind a resource *instead of the original way*. If the server advertises it and the client uses it, you're done. -- ralphm ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] RFC 6120 vs. XEP
Hi,
On Mon, Feb 06, 2017 at 04:46:58PM -0700, Peter Saint-Andre wrote:
> RFC 6120 author here. :-)
Great! :-)
> Note that the order of features matters. In the Bind2 proposal, the order is
> this:
I have to disagree. RFC 6120, section 4.3.2 says this, though it is
marked as an Implementation Note:
> Implementation Note: The order of child elements contained in any
> given element is not significant.
Thus, I'm not really sure whether I agree with your understanding of RFC
6120's text.
> > 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.
Okay, I get this now. Clients and servers are not supposed to drop
original RFC 6120 binding support. If it weren't for this "as described
in the following sections" in RFC 6120 I could accept your understanding
of the text, but it still is unsatisfactory to interpret "MUST bind a
specific resource to the stream" in section 7.1 as meaning "with any
resource binding process, be it RFC 6120 bind or something later defined
in a XEP", and interpreting "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" in section 7.4 differently as
meaning "only if you want to do RFC 6120 resource binding you have to
follow the following sections". In both cases, the similar use of terms
("bind a resource" vs. "resource binding") suggests that the terms are
intended to mean the same, not different things.
Don't get me wrong. I'm not trying to troll you, I just have the
impression that the your original intention doesn't show up as clear in
RFC 6120 as it should.
> 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).
By no means I meant to discredit the IETF. I just wanted to make a
suggestion in case the IETF is perceived as too slow. I did not mean to
imply that. I'm sorry, and yes, the security improvements are definitely
very important.
> tl;dr Let's do the best we can on Bind2 and then cross the IETF bridge when
> we come to it.
I agree with Evgeny in this regard: with this, all my points become void
anyway. Let's make XMPP better together!
Greetings
Marvin
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___
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] 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 ___
