-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/29/09 6:43 AM, Peter Saint-Andre wrote: > On 10/29/09 3:32 AM, Matthew Wild wrote: >> 2009/10/26 Dave Cridland <dave at cridland.net>: >>> On Fri Oct 23 18:58:04 2009, Justin Karneges wrote: >>>> 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? >>> Just to pick up on this point, features can surely only be advertised if >>> they're available. >>> >>> If they're not available - because the client cannot use them in this >>> stream, since it needs to do the TLS dance and make a new stream - then they >>> shouldn't be advertised. >>> >>> If you're reading RFC 3920 as saying that all possible features - even those >>> not yes available - must be listed, then I'd think that would need >>> clarification. >>> >> Agreed, this is how I interpret it also. > > The text in 3920bis (and I think also 3920) talks about "available > features", but if need be we can clarify this a bit further. I've added a few minor clarifications about this to my working copy. 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/ iEYEARECAAYFAkrpmS4ACgkQNL8k5A2w/vwoigCguURY3fkFmw7dVv/n6rnRg6w2 o1IAn28cP6HMaoID+0VsizyidO7WpWwK =QRZw -----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.