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: [email protected]
_______________________________________________
