Subject: [xmpp] Stream Negotiation Clarification

From: Tobias Peciva <[email-masked]>
Date: Mon, 10 Oct 2011 13:26:02 +1300

Hi,

I have a question about the "stream-negotiation-complete" conformance requirement in section 15 of RFC 6120. This requirement states - as does section 4.3.5 - that stream negotiation is only complete after the receiving entity sends an empty stream features element, or one with only optional features.

In the client-to-server examples in section 9.1, however, no such element is sent. I would expect this to happen between 9.1.3 and 9.1.4, but it appears the entities immediately start exchanging stanzas, without completing stream negotiation explicitly.

Our experience with third party applications is that the behavior matches section 9.1 rather than sections 4.3.5 and 15: Clients appear to start sending messages immediately after successful resource binding, without waiting for an empty features element.

Are we interpreting the "stream-negotiation-complete" requirement wrong?

Thanks!

Best regards,
Tobias Peciva
Kaseya

---

From: Kim Alvefur <[email-masked]>
Date: Mon, 10 Oct 2011 02:45:25 +0200

Hello!

On Mon, 2011-10-10 at 13:26 +1300, Tobias Peciva wrote:
> I have a question about the "stream-negotiation-complete" conformance
> requirement in section 15 of RFC 6120. This requirement states - as
> does section 4.3.5 - that stream negotiation is only complete after
> the receiving entity sends an empty stream features element, or one
> with only optional features.

Section 4.3.5 has an informational note stating that resource binding is
an exception.

-- 
Kim Alvefur <[email-masked]>

---

From: Tobias Peciva <[email-masked]>
Date: Tue, 11 Oct 2011 14:12:00 +1300

Hey,

Right. What doesn't seem clear from the specification is what happens when there are additional, optional features to negotiate. Presumably these cannot be negotiated after resource binding, as it appears entities are allowed to start exchanging messages immediately after the resource binding completes.

So if optional features must be negotiated before resource binding, then presumably these optional features must be advertised at the same time (in the same <features> element) as resource binding? And if so, under what conditions would the receiving entity ever send an empty or "optional-features-only" <features> element, as mentioned in the stream-negotiation-complete requirement? It cannot send this after the resource binding is complete, as message stanzas are already flowing at this point - and it cannot send it before resource binding, because at this stage resource binding is still a required feature.

I suppose what we're really looking for is an example in the specification the shows how optional stream features are handled, and how they are sequenced relative to resource binding.

Thanks!

Best regards,
Tobias Peciva
Kaseya

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Oct 2011 17:48:44 -0600

On 10/10/11 7:12 PM, Tobias Peciva wrote:
> Hey,
> 
> Right. What doesn't seem clear from the specification is what happens
> when there are additional, optional features to negotiate. Presumably
> these cannot be negotiated after resource binding, 

I don't think that's true.

> as it appears
> entities are allowed to start exchanging messages immediately after
> the resource binding completes.

The server would probably send all of its optional features along with
the resource binding feature.

> So if optional features must be negotiated before resource binding,
> then presumably these optional features must be advertised at the
> same time (in the same <features> element) as resource binding? And
> if so, under what conditions would the receiving entity ever send an
> empty or "optional-features-only" <features> element, as mentioned in
> the stream-negotiation-complete requirement? It cannot send this
> after the resource binding is complete, as message stanzas are
> already flowing at this point 

Why couldn't the server send the <iq type='result'/> for resource
binding, immediately followed by another stream features element?

> - and it cannot send it before resource
> binding, because at this stage resource binding is still a required
> feature.

As Kim Alvefur pointed out, Section 4.3.5 notes that resource binding is
an exception in this regard.

> I suppose what we're really looking for is an example in the
> specification the shows how optional stream features are handled, and
> how they are sequenced relative to resource binding.

Here are some examples of stream features that have been defined outside
of the RFCs, in descending order of relevance to your questions:

http://xmpp.org/extensions/xep-0198.html#feature

http://xmpp.org/extensions/xep-0138.html#usecase

http://xmpp.org/extensions/xep-0077.html#streamfeature

http://xmpp.org/extensions/xep-0079.html#streamfeature

See also:

http://xmpp.org/extensions/xep-0170.html

Peter

-- 
Peter Saint-Andre
https://stpeter.im/