[Standards] RFC 6120 vs. Bind2 XEP
ralphm at ik.nu
Wed Feb 8 11:26:43 UTC 2017
On 06-02-17 15:53, Marvin Gülker wrote:
> On Mon, Feb 06, 2017 at 03:25:15PM +0300, Evgeny Khramtsov wrote:
>> I guess that's your opinion? Or where is it stated in the RFC? <bind
>> xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> is a mandatory-to-negotiate
>> feature (at least if included), thus, clients MUST NOT ignore it.
> I tend to agree with this. RFC 6120, section 7.1. says that clients must
> do resource binding, section 7.2. declares support for it mandatory in
> the client, and in section 7.4. it is definitely stated that (hilight by
>> [...] the server MUST include a <bind/>
>> element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace
>> in the stream features it presents to the client.
>> 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<<<<.
> This, in my opinion, means that RFC 6120 has to be officially amended to
> support Bind2 as in case of conflicts between a XEP and the RFC, the RFC
> must take precedence.
> Apart from the formal argument, disregarding RFC 6120 and revising core
> XMPP functionality via a XEP means that a good part of RFC 6120 (namely
> section 7) does not reflect the reality anymore when Bind2 is
> accepted. Someone creating a new XMPP client naturally starts by
> implementing RFC 6120, only to discover that it is obsoleted by
> practice. I do think that such severe revisions deserve a note in the
This is simply not true. Nobody is disregarding RFC 6120. Traditional
resource binding remains mandatory to implement and any new XMPP client
can do everything described in RFC 6120/6121 as normal. Bind2 just
provides an alternative with attractive additional properties, like
We are in the process of defining Bind2 and figuring out if it can
replace the traditional resource binding eventually. If and when we do
think this is the case, then yes, we should go and do another round of
revised specifications at the IETF. This has already been mentioned as
the future process.
More information about the Standards