[jdev] Re: stream features and jabber:iq:auth

[Peter Saint-Andre]

Christoph Schmidt wrote:
>> As far as I see, the presence of a 'version=1.0' attribute in the 
>> opening stream tag doesn't indicate that you MUST NOT use 
>> jabber:iq:auth. It does indicate that there might be more suitable 
>> options available, because the presence of 'version=1.0' indicates 
>> that TLS/SASL is implemented, as described in RFC 3920. The precense 
>> of 'version=1.0' does not indicate wether or not JEP-0078 (iq-auth) 
>> has been implemented.
> 
> 
> 'version=1.0' indicates XMPP v1.0 compliance, which *requires* use of 
> SASL (and recommends TLS). This implies that you MUST NOT use 
> jabber:iq:auth.
> 

A client should not include the version='1.0' flag if it cannot do TLS, 
SASL, resource binding, etc. (all the RFC 3920 goodness). If the client 
includes the XMPP 1.0 flag, then the server should not advertise support 
for the "jabber:iq:auth" feature to that client. If the client does not 
include the XMPP 1.0 flag, then the server should advertise support for 
the "jabber:iq:auth" feature to that client (if, that is, the server 
supports old-style non-SASL authentication). The same is true for 
server-to-server connections.

A client or server that supports SASL authentication might -- in fact, 
should (per JEP-0073) -- also support old-style non-SASL authentication 
in order to manage connections with entities that have not yet 
implemented SASL authentication. Support for SASL authentication does 
*not* imply that an implementation must not support non-SASL authentication.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3511 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20050913/5159d88d/attachment-0002.bin>