[Standards] RFC 6120 vs. Bind2 XEP (was: CSI and Carbons state after SM resumption)

Marvin Gülker m-guelker at phoenixmail.de
Mon Feb 6 14:53:41 UTC 2017


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
me)

> [...] 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
RFC.

Greetings
Marvin


More information about the Standards mailing list