Gaston Dombiak wrote:
I'm trying to figure out with stream errors should the server return under these circumstances:1) client requested TLS and the server never offered it (i.e. TLS is disabled on the server)
Realistically this does not seem very likely, since a server that does not support TLS is probably an XMPP 0.9 (old-style Jabber) server and a server that supports XMPP 1.0 MUST offer TLS. However, I suppose it is possible for an XMPP 1.0 server to support TLS in the implementation but have that support be disabled in the deployment (even though I think that violates the spec). In that case, it seems to me that there are two options:
1. silently ignore the TLS request2. return a TLS <failure/> and close the stream (though why should you do that if you don't even support TLS, eh?)
3. return a <not-authorized/> stream errorI think #1 is most appropriate, since that is what (I think) an XMPP 0.9 server would do.
2) server required TLS and client ignored it (i.e. never secured the connection and went ahead with SASL or iq:auth)
I think this is <not-authorized/>. The initiating entity is attempting to proceed with communications before completing the necessary authentication precondition.
Peter -- Peter Saint-Andre Jabber Software Foundation http://www.jabber.org/people/stpeter.shtml
smime.p7s
Description: S/MIME Cryptographic Signature
