[Standards] RFC 6120 vs. XEP
stpeter at stpeter.im
Tue Feb 7 14:47:07 UTC 2017
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
>> 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!
More information about the Standards