[jdev] Re: Which stream error should the server return?

[Gaston Dombiak]

Thanks guys. I finally implemented for both cases that a <not-authorized/> 
stream error is returned and the connection closed. Peter, I would like to 
hear from you if you think that this is not appropriate for option 1. I 
personally agree with Jacek.

Thanks,

  -- Gato

"Jacek Konieczny" <jajcus at jajcus.net> wrote in message 
news:20051115074350.GB8025 at serwis2.beta...
> 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
>