If the server does not enable TLS, then it should not even broadcast
the <starttls> feature 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 DO proceed with TLS and the server does not support
it, then I would think it's reasonable for the server to return a
<failure> and disconnect the connection.
Thanks,
Chris
On 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
On 7/22/05, Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
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='urn:ietf:params:xml:ns:xmpp-tls'/> because the
namespace is wrong, there is XML character data contained in the
<starttls/> element, or whatever).
Otherwise the server would return <proceed/>, I think.
Peter
--
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml
_______________________________________________
jdev mailing list
[email protected]
http://mail.jabber.org/mailman/listinfo/jdev
_______________________________________________
jdev mailing list
[email protected]
http://mail.jabber.org/mailman/listinfo/jdev
_______________________________________________
jdev mailing list
[email protected]
http://mail.jabber.org/mailman/listinfo/jdev
