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 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?
>

It's what Prosody does and it's working great as far as I can see. If
it really does violate the RFC (I don't see why) then I propose we fix
the RFC :)

> 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..

Matthew.