Re: [xmpp] the stream negotiation process

[Joe Hildebrand <joe.hildebrand at webex.com>]

(as individual)

On 10/16/09 9:24 AM, "Peter Saint-Andre" <stpeter at stpeter.im> wrote:

> You are recommending instead something like this:
> 
> R: <stream:features>
>      <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
>        <stream:required restart='true'/>
>      </starttls>
>    </stream:features>
> 
> Now, what we've said is that the use of <required/> and <optional/> is a
> convention that we will follow in defining all stream features, but I
> think you're right that it's better to define one qualified name for
> this, and probably place it in the streams namespace (we could define a
> new namespace just for optionality of stream features, but I don't see a
> compelling reason to do that).

+1.  I really like that approach.

>> 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?
> 
> IMHO it's better to be explicit than implicit in what's required
> throughout the stream negotiation process.

It also makes writing clients much easier, because they can process stream
restarts generically.

> Well, <required/> and <optional/> are really not ideal because they're
> defining a boolean. It would be better to have something like this:
> 
> R: <stream:features>
>      <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
>        <stream:usage required='true' restart='true'/>
>      </starttls>
>    </stream:features>
> 
> Here both attributes would default to FALSE.

As well, servers SHOULD allow SASL restarts even if restart='false', for
backward-compatibility.

>> How about a stream feature advertising an entity's
>> ability to receive feature updates?
> 
> Nothing in RFC 3920 forbids this behavior, and in any case what you want
> is a feature that could be advertised by the initiating entity (so that
> it can tell the receiving entity "yes I support feature updates").
> 
> But that gets into the question of feature declarations from the
> initiating entity to the receiving entity, which is also interesting but
> not yet defined.

The question is whether late stream features will break existing client
software.  I think there is a possibility.  I've had several bad ideas about
how to have clients and servers know that they both support this, but all of
them are heavy-weight compared to a) the utility and b) the risk.

Maybe we should just do some client/library testing to see what happens. :)

-- 
Joe Hildebrand