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

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

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

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

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

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

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

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

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

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

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

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

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

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

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,

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

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

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

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