Re: [xmpp] the stream negotiation process

[Peter Saint-Andre <stpeter at stpeter.im>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My apologies for the delayed reply.

On 10/3/09 6:25 AM, Waqas Hussain wrote:
> On Sat, Oct 3, 2009 at 5:50 AM, Peter Saint-Andre <stpeter at stpeter.im
> <mailto: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?

I tend to agree. In fact I thought about it the morning after I wrote up
the text I posted, but never replied on the list. :)

In RFC 3920, the only feature that used <required/> was TLS. So we had
feature declarations like this:

R: <stream:features>
     <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
       <required/>
     </starttls>
   </stream:features>

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

>       For security reasons, certain stream features necessitate the
>       initiating entity to send a new initial stream header upon successful
>       negotiation of the feature (e.g., TLS and SASL).  If a stream restart
>       is necessary for any given feature, the <optional/> or <required/>
>       child element MUST include a boolean 'restart' attribute with a value
>       of "true" or "1" (this optional attribute defaults to false).
>       Although it is expected that stream restarts will be necessary only
>       for mandatory features, voluntary features are also allowed to
>       necessitate restarts.
> 
>       Aside from the <optional/> child element, <required/> child element,
>       and 'restart' attribute, the syntax and semantics of each particular
>       feature are defined by an appropriate specification of that feature;
>       several such features are defined in this document but stream
>       features can be defined by other documents, as well.
> 
> 
> I'm afraid I missed the discussion where the <optional/> element and the
> 'restart' attribute were defined. 

We're having that discussion now, at least for the 'restart' attribute
(when writing up the state chart for the stream negotiation process I
realized that it would be better to define restart explicitly instead of
saying that it's implicit in certain features).

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

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

One example is SASL: certain SASL mechanisms might require a stream
restart (because they enable the negotiation of security layers) and
certain SASL mechanisms might not (in fact the IETF seems to be moving
away from security layers and toward channel bindings, so in the future
an XMPP server might not offer any SASL mechanisms that would truly
require a restart). In this case, why force a stream restart when it
isn't really necessary?

> If the 'restart' attribute wasn't a MUST, the <optional/> element
> wouldn't need to be defined either. There is just one case where it may
> be useful: for indicating that the im-session feature is optional, and
> saving a round trip, but then it might as well be defined for just that
> feature.

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.

>     5.2.4.  Resending Features
> 
>       After completing negotiation of any stream feature (even stream
>       features that do not require a stream restart), the receiving entity
>       MUST send an updated list of stream features to the initiating
>       entity, where the list MAY be empty if there are no further features
>       to be advertised.
> 
>       At any time after stream establishment and before closing of the
>       stream, the receiving entity MAY send additional or modified stream
>       feature advertisements to the initiating entity (e.g., because a new
>       feature has been enabled).
> 
> 
> 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? 

AFAIK, no XMPP software supports this behavior now.

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

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrYkBsACgkQNL8k5A2w/vwN6wCgmpopFKkgMY776YxJPEO/q4QM
80UAniOD93CGeh6MDU6yZxUXuonItbRr
=Ld1p
-----END PGP SIGNATURE-----