Re: [xmpp] the stream negotiation process

[Matthew Wild <mwild1 at gmail.com>]

2009/10/23 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!".

If the server offers binding then I see no reason it couldn't do exactly that :)

> Instead the client going to disconnect and present an error to the user,
> since the server is speaking nonsense.
>

If the server speaks nonsense, all hope is lost. It's an
implementation issue, and not a protocol issue.

Matthew