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?
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. 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.
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.
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? How about a stream feature advertising an entity's ability to receive feature updates?
--
Waqas Hussain