Matthew Wild wrote:
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 :)
+1 I would not expect problems either, because the TLS+SASL PLAIN path exists.
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..
xep 0170 does that already :-p
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.