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

[Peter Saint-Andre]

Sure, I think that is fine. Jacek is right that ignoring the TLS request 
would not be so good.

Peter

Gaston Dombiak wrote:
> 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
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20051116/0ad4d058/attachment-0002.bin>