If the server does not enable TLS, then it should not even broadcast
the <starttlsfeature namespace within the <stream:features
element. Thus, in your client, you should double check first if the
feature exists before proceeding with the TLS negotiation.

However, if you D proceed with TLS and the server does not support
it, then I would think it's reasonable for the server to return a
<failureand disconnect the connection.

Thanks,
Chris

Jul 22, 2005, at 12:02 PM, David Waite wrote:

how about the server deployment not being enabled with TLS? Would that
also result in failure (if the client ignored the server capabilities
because it is configured to require TLS)?

-David Waite

7/22/05, Peter Saint-Andre <stpeter (AT) jabber (DOT) orgwrote:
>
>Chen, Hao wrote:
>>
>>
In the rfc3920 document (XMPP: Core), section 5.2 Narrative, step 5
states that: "The receiving entity MUST reply with either a
<proceed/>
element or a <failure/element"

My question is upon what conditions the receiving entity replies
with
a <proceed/and upon what conditions it replies with a <failure/>?

>>
>Hmm, that could be better specified, eh? We'll have to fix that in
>rfc3920bis.
>>
>I can see two reasons for returning a <failure/>:
>>
>1. The server is temporarily not prepared to offer TLS negotiation
>(some
>internal server problem).
>>
>2. The STARTTLS command is malformed (i.e., something other than
><starttls xmlns=''/because the
>namespace is wrong, there is XML character data contained in the
><starttls/element, or whatever).
>>
>the server would return <proceed/>, I think.
>>
>Peter
>>
>--
>Peter Saint-Andre
>Jabber Software Foundation
>
>>
>>
>
>jdev mailing list
>jdev (AT) jabber (DOT) org
>
>>
>>
>>
>>

jdev mailing list
jdev (AT) jabber (DOT) org

jdev mailing list
jdev (AT) jabber (DOT) org

Fri, Jul 22, 2005 at 09:58:11AM -0600, Peter Saint-Andre wrote:
Hmm, that could be better specified, eh? We'll have to fix that in
rfc3920bis.

I can see two reasons for returning a <failure/>:

[]

2. The STARTTLS command is malformed (i.e., something other than
<starttls xmlns=''/because the
namespace is wrong,

If the namespace is wrong, then that is not a StartTLS request and
server should not treat it this way. It should not even be treated as
a malformed StartTLS request, as if the namespace is not know, then
there is no way to say what the element means (element name doesn't
matter).

Greets,
Jacek

jdev mailing list
jdev (AT) jabber (DOT) org