[Standards] RFC 6120 vs. XEP

Marvin Gülker m-guelker at phoenixmail.de
Tue Feb 7 12:41:30 UTC 2017


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 <features/> 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!


More information about the Standards mailing list