Tue, 7 Feb 2017 21:22:17 +0000 Dave Cridland <[email protected]> wrote:
> On 7 February 2017 at 16:29, Evgeny Khramtsov <[email protected]> > wrote: > > Tue, 7 Feb 2017 19:18:39 +0300 > > Evgeny Khramtsov <[email protected]> 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. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
