[jdev] Which stream error should the server return?

[Jacek Konieczny]

On Mon, Nov 14, 2005 at 08:32:44PM -0800, Peter Saint-Andre wrote:
> 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. 

It must only implement TLS. Offering it is not required (sometimes it
may be forbidden by local regulations, or something).

> 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 request
> 2. 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 error
> 
> I think #1 is most appropriate, since that is what (I think) an XMPP 0.9 
> server would do.

I don't think that is a good idea. If a client  requests TLS it expects
some answer. If the server doesn't answer, then client would wait and
finally timeout. IMHO it is better to close the stream as soon as the
error is detected. There is no need to keep a connection to a _broken_
client.

And, I guess, XMPP 0.9 server would return a stream error, as
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> is not a valid
stazna.

Greets,
        Jacek