[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmpp] the stream negotiation process



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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/

iEYEARECAAYFAkrpjfEACgkQNL8k5A2w/vzsQgCfeT+LWOCReRYJwT64+NvjwTmm
Cl8AoN3R8KUsjRTXbXk2V8cUIiz4abdV
=fviE
-----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.