Re: [xmpp] the stream negotiation process

[Justin Karneges <justin at affinix.com>]

On Thursday 22 October 2009 13:08:08 Peter Saint-Andre wrote:
> On 10/21/09 8:45 AM, Peter Saint-Andre wrote:
> > 1. Negotiation of all stream features is optional. If the receiving
> > entity considers negotiation of a given feature to be mandatory, it will
> > advertise only that feature; and if the initiating entity does not
> > negotiate that feature (e.g., by attempting to send stanzas before it is
> > allowed to do so), then the receiving entity will return an error to the
> > initiating entity. Therefore, we have no need to specify over the wire
> > if a given stream feature must be negotiated at any given stage of the
> > stream negotiation process.
>
> For TLS, we felt the need in RFC 3920 to define a method whereby the
> server could flag negotiation of TLS as mandatory to negotiate ("MTN")
> in order to enforce local service policies. The discussions since then
> have always assumed that we need a way to flag (some) features as MTN.
> The thread here has attempted to define MTN in a standardized way,
> rather than assuming that MTN will be explicit in the definition of some
> features (TLS) but not others (everything else), implicit in the
> definition of a given feature (SASL is always mandatory) or implicit via
> the inclusion of a given feature and only that feature at a particular
> point in the stream negotiation process (what Mr. Cridland appears to be
> suggesting).

I feel similar to Dave on this matter, that the suggested changes to stream 
features amount to overengineering.

If we want a future feature to be required, it should be enough to state in 
the spec that it is required.  A client isn't going to say to an 
end-user: "Sorry, the server requires the 'ugly-long-namespace' feature in 
order to log in."  Either the client will display a generic error ("Sorry, 
the server requires a feature not supported by this client"), or it will be 
spec-aware and display ("Sorry, the server requires the Foo feature, which is 
not supported by this client" (except that it sort of is, if the client can 
write such a message..)).

Sure, a generic way to flag any feature as required would allow a client to 
easily display the generic "feature not supported" error message.  Otherwise, 
as mentioned, the client would have to send a stanza and receive an error in 
order to determine that there was an unnegotiated required feature.  I'm 
partial to using an error as a solution, since it requires the least amount 
of change to XMPP.  I'd suggest a stream error here and not (or not merely) a 
stanza error.

Finally, I want to say that very few features should be required at all 
anyway.  TLS, SASL, and resource binding are the only ones that matter.  
Everything else should almost always be optional.  Is anyone really planning 
to require compression or stream management for example, to the point where 
the client can't even use the service without them?  I don't think you will, 
but in the chance that you do, you can bounce the client off with a stream 
error.

-Justin