[Standards] RFC 6120 vs. XEP

Evgeny Khramtsov xramtsov at gmail.com
Wed Feb 8 06:17:07 UTC 2017


Tue, 7 Feb 2017 21:22:17 +0000
Dave Cridland <dave at cridland.net> wrote:

> On 7 February 2017 at 16:29, Evgeny Khramtsov <xramtsov at gmail.com>
> wrote:
> > Tue, 7 Feb 2017 19:18:39 +0300
> > Evgeny Khramtsov <xramtsov at gmail.com> wrote:
> >> Indeed (section 4.3.2). Then we're ok here *if* we make Bind2
> >> mandatory-to-negotiate.  
> >
> > For the record, it should be also pointed in XEP-0198 that <sm/>
> > feature is mandatory to negotiate.  
> 
> I'm missing something - why would <sm/> need to be mandatory to
> negotiate?

Seems like everybody is missing something on this topic :)
Let me describe how I see it. Let's say a client gets the following
features (copied from XEP-0198):

<stream:features>
  <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
  <sm xmlns='urn:xmpp:sm:3'/>
</stream:features>

In this case, RFC6120, Section 7.4 states:

> 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.

Thus, a client MUST bind a resource, it cannot resume a session.
However, Section 4.3.2 says:

> A <features/> element MAY contain more than one mandatory-to-
> negotiate feature.  This means that the initiating entity can choose
> among the mandatory-to-negotiate features at this stage of the stream
> negotiation process.

Thus, if <sm/> is mandatory-to-negotiate, a client is not required to
<bind/> a resource because and is now free to choose which
mandatory feature to negotiate. So it may resume session in this case
without binding.


More information about the Standards mailing list