-----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. > Apologies for the semi-top-post, but I'd like to summarise my response > to some earlier posts in the thread. Give a shout if I've missed the > gist of anything. > > I agree with Justin that any required/optional/restart flags are > over-engineering. The current process works just fine. To clarify, > this is how I see it working now: > > Loop > Server offers a set of features available to the client at the current time > Client chooses and negotiates its most preferred option > Until connection complete > > 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? > The feature negotiation process is not a shopping list, but a tree. > The current system also allows use to advertise different SASL > mechanisms depending on whether the client has negotiated TLS or not > yet. Indeed. > Now the most interesting thing is how to detect when the server is > ready for you to send stanzas. Isn't this when it offers resource > binding to the client? Yes. > 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. > More follows... > > 2009/10/23 Peter Saint-Andre <stpeter at stpeter.im>: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 10/22/09 10:56 PM, Justin Karneges wrote: >>> On Thursday 22 October 2009 20:32:12 you wrote: >>>> On 10/22/09 7:07 PM, Justin Karneges wrote: >>>> > >>> In the case of ensuring only one of these features is used, and not both, of >>> course the server could be smart about how the features are offered. For >>> example, on the first pass it could offer both NGAuth and SASL, but if NGAuth >>> is used and succeeds then the next set of stream features would not contain >>> either of them. That said, the client shouldn't be so dumb that it relies on >>> the server for this logic. A client shouldn't auth twice, and it should know >>> that it only needs one of NGAuth or SASL because it would say so in the spec. > > I disagree (even if we have abandoned the "smart servers, simple > clients" philosophy which used to be so prevalent round here). The > logic *is* defined by the server (and its admin), it's the server that > is choosing what is required and what is not, and so I'd consider it a > bug for the server to offer an authentication method when the stream > is already authenticated. > > 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. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkrh3YoACgkQNL8k5A2w/vz6twCggkMSIjUMapiJW88cnaiEDNFB 2AsAoOcqLiJ1QM0ddCdQA/8ugm6w5oAr =baiF -----END PGP SIGNATURE-----
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.