Re: [xmpp] the stream negotiation process

[Jehan Pagès <jehan.marmottard at gmail.com>]

Hi,


On Sat, Oct 3, 2009 at 9:50 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Earlier today I rewrote the section of 3920bis on stream features,
> expanding it to cover the stream negotiation process in general. Thanks
> to Jehan Pagès for pointing out to me in private conversation that this
> topic was underspecified. My provisional text follows. I will review
> this again next, but as always feedback is welcome.

My general feedback is that it looks very good. :-) Exactly how I had
it in mind. Now it really becomes a "systematic" procedure, which can
very easily be implemented on both clients and servers as a simple
state machine.

Just a simple note on the graph: after "restart required?" state, the
"no" leads to "Receive stream features", and not to "Negotiation
complete". Negotiation may be complete, but the server still needs to
send an update <features> (even though it may be empty) for the client
to know it. This is well explained in your text, only the graph has
the bug.

On Sat, Oct 3, 2009 at 9:25 PM, Waqas Hussain <waqas20 at gmail.com> wrote:
> On Sat, Oct 3, 2009 at 5:50 AM, Peter
> Saint-Andre <stpeter at stpeter.im> wrote:
>>
>>   If negotiation of a particular stream feature is mandatory, the
>>   stream feature advertisement MUST include an empty <required/> child
>>   element.
>>
>>   If negotiation of a particular stream feature is voluntary, the
>>   stream feature advertisement MAY include an empty <optional/> child
>>   element.  However, because every stream feature defaults to
>>   voluntary, the inclusion of an empty <optional/> child element is not
>>   necessary to indicate that a stream feature is voluntary.
>
> What namespace are these elements under? Just inheriting the namespace of
> whatever feature they are included in is pretty evil. Elements are qualified
> by their names AND namespaces. A name without a namespace and a namespace
> without a name are meaningless. Specifying that a name has a given meaning
> under any and all namespaces goes against the spirit of XML namespaces and,
> if you think about it, is just plain Wrong(TM). Can we have a fixed
> namespace for these elements please?
>

Right, I wondered this as well. I think the <optional> and <required>
element should be under the stream namespace.

> I'm afraid I missed the discussion where the <optional/> element and the
> 'restart' attribute were defined. Whether a feature requires a stream
> restart or not is part of the definition of the feature (e.g., it's part of
> the definitions of the SASL and STARTTLS features). If an entity understands
> a feature, then it already knows whether a restart is required or not. What
> value does the 'restart' attribute add? Are there any use-cases where the
> 'restart' attribute saves the day?
> The only case where the 'restart' attribute might be useful is for features
> which can work both with and without restarts, and the server needs to
> specify at runtime whether it feels like doing a stream restart or not. I
> don't see any need for such features. This brings to mind the restart-less
> SASL/etc negotiation discussed last year, but those would be new features
> with new definitions under new namespaces, and wouldn't need the 'restart'
> attribute.

I agree that 'restart' is not useful because, as you point it, if you
know/negotiate the feature, you know whether or not the restart will
be needed. And as you, I don't see a use case where it is useful...
but maybe there will be in future, then it is better to plan it?

That's the same thing as the <optional> element, I guess, but for
another reason: it is the default value. It adds semantic. But except
from this, it is useless. Hence <optional> may probably be safely
removed if everyone wants to.

>
> This is pretty interesting. Features can change at runtime, and I had been
> looking for a way to advertise that. One thing which does make me hesitate
> in resending features is concern about how well existing clients and servers
> would cope with receiving them. Does anyone have any experience with this?
> How about a stream feature advertising an entity's ability to receive
> feature updates?

There don't need any feature (I guess by "stream feature", you meant
in fact an entity capability? Because a stream feature is sent by a
receiving entity, hence a server only) for that as it is already
currently in the core spec (rfc 3920bis at least, I have not read the
old 3920 for a while). So an entity is already supposed to be able to
receive feature updates (even though it is not forced to do anything
with it).
Now I don't know if there is any current implementation doing something with it.

I have another note to make about sending updated features while the
stream has already been negotiated. I raised it to Peter on private
the other day, but he had to go, so we couldn't finish the discussion.
Hence let's make it public now: what if the updated feature (in an
already established stream) contains a "required" feature?

Should the <required> element be forbidden in features updated after
stream establishement?

If not, does it mean that it suspends your stream as long as you have
not negotiated the new required feature (for instance a server which
strengthens live its stream negotiation and want to force any existing
connections to update?). Hence you cannot anymore send/receive
stanzas, and an unavailable presence to all your roster is implied...
Anyway something should be added about this (either an interdiction or
an explanation about how to deal with such a case).

Bye!

Jehan