Re: [xmpp] the stream negotiation process

[Justin Karneges <justin at affinix.com>]

On Friday 23 October 2009 12:22:45 you wrote:
> 2009/10/23 Justin Karneges <justin at affinix.com>:
> > 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.
>
> The RFC could define a recommended order, TLS <= SASL, SASL < binding,
> etc..

It already does.  However it's a bit more than "recommended".  It's the 
required sequence.  If a server offers binding before SASL, for example, it's 
not like the client is going to use binding and say "woo-hoo I'm in!".  
Instead the client going to disconnect and present an error to the user, 
since the server is speaking nonsense.

-Justin