2009/10/23 Peter Saint-Andre <stpeter at stpeter.im>: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/23/09 8:39 AM, Matthew Wild wrote: >> I disengage from mailing lists for 24 hours and look where it gets me... :) > > I assume that you meant to reply-to-all, so I am replying to the list. > Indeed yes, too long away from mailing lists, like I said :) >> That is to say, if TLS is required... what we really mean is that "TLS >> is required before you can authenticate" (or compress, or etc.). So we >> would end up with TLS being the only feature published to the client >> at the start. > > 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. >> If we really need to define anything else, >> could we perhaps re-use the IM session feature (which Dave has been >> muttering about for a while). > > At the very first XMPP Summit and interop event in July 2006, we had > strong consensus among all the server and client developers present that > the im-session feature was a no-op. I haven't seen anything since then > that would lead me to change my mind. > Agreed. I'll leave it for Dave if he does want to resume this in the context of this thread. >> The current system is nice and flexible, I don't see anything that >> needs changing. What did I miss? > > Nothing. Version -03 of 3920bis will keep things as-is, just explain the > state transitions more clearly. > All good to me, thanks, Matthew
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.