[Jabber-IETF] STARTTLS support for XMPP streams

David Waite mass at akuma.org
Fri Oct 11 00:51:09 CDT 2002

Robert Norris wrote:

>So, to fit this into the new capabilities structure we've put together,
>the dialogue might look something like this:
>C: <stream:stream xmlns='jabber:client' xmlns:stream='http://...' to='jabber.org' version='1.0'>
>S: <stream:stream xmlns='jabber:client' xmlns:stream='http://...' from='jabber.org' version='1.0' id='123456768'>
>     <stream:capabilities>
>       <mechanisms xmlns='http://sasl'>
>         <mechanism>DIGEST-MD5</mechanism>
>       </mechanisms>
>       <starttls xmlns='http://starttls'/>
>     </stream:capabilities>
>C:   <starttls xmlns='http://starttls'/>
>S: </stream:stream>
Just curious, should we even bother reporting tls as a capability? Since 
it isn't sent to the client in a 'secure' way, the client shouldn't 
downgrade based on the lack of the capability, but should just fail. I 
say 'should' because I'm not sure if there is or is not a valid use for 
optional security.

I suppose since the existing internet draft specifies that unknown 
"chunks" must be ignored rather than returned with an errror, we cannot 
use any feature which has not been negotiated beforehand. If a user or 
policy requires TLS, it should just fail if the server does not return 
the tls capability.

Or, perhaps we should state that unknown chunks (first-level elements 
outside the valid elements for the 'jabber:client' namespace, indicated 
in the following by a 'jabber' prefix) should have any jabber:to and 
jabber:from attributes swapped, have a jabber:type attribute added or 
updated to hold the value error, and include a jabber:error element with 
a jabber:code attribute of 400 and optionally a text message as CDATA 
indicating the bad request.

-David Waite

More information about the xmppwg mailing list