Re: [xmpp] the stream negotiation process

[Justin Karneges <justin at affinix.com>]

On Friday 23 October 2009 10:03:29 Matthew Wild wrote:
> 2009/10/23 Peter Saint-Andre <stpeter at stpeter.im>:
> > Basically you and others are saying that until the initiating entity is
> >  cleared to send stanzas, it needs to treat a feature as required if the
> > server advertises only that feature. Correct?
>
> It needs to treat the list of features offered by the server as
> "choose one of these to continue", so yes if TLS is mandatory before
> any other negotiation can continue, it would appear on its own. I'm
> trying to differentiate from the earlier "mark a feature as MTN by
> offering it alone", because if there are multiple MTN features in
> which negotiation order does not matter, they could all be offered
> together.

I'm not opposed to deferring features from appearing as a way of making other 
features required.  But first: does anyone know if not offering SASL on the 
first pass could cause a problem with existing code?  Or if it may violate 
RFC 3920?

This approach could also be used to force the client to enable features in a 
certain sequence, though for most features there is already a defined order 
that the server can't muck with.  For example, a server can't make a client 
negotiate TLS after SASL, or make it negotiate resource binding without 
having done SASL.  These would be considered protocol errors by the client.

-Justin