Re: [xmpp] the stream negotiation process

[Dave Cridland <dave at cridland.net>]

On Tue Oct 20 05:48:41 2009, Joe Hildebrand wrote:
> On 10/19/09 3:46 PM, "Dave Cridland" <dave at cridland.net> wrote:
>
> > 1) You probably don't want to require features. Instead, you only
> > want to drop the ones the clients not allowed to use right now.
>
> We at least need to require TLS, because in some installations you  
> want it
> required (high security), and in others it needs to be optional  
> (e.g. mobile
> clients on a trusted network).  In the past we've used "required"  
> for this,
> and there's no good reason to switch it to "optional".
But my point here is that you either offer a method to authenticate  
without encryption, or you don't. If you offer no SASL mechanisms at  
all, then you're effectively requiring TLS. If you offer some  
selected SASL mechanisms, you're requiring some security policy  
embodied by that selection, like encryption, or no plaintext  
passwords. If you offer all your mechanisms, then you're signalling  
you have a very liberal security policy.

IMAP, ACAP, ESMTP, Submission - none of these have the need to signal  
that TLS is required explicitly. That's not to say we couldn't  
improve on this, but that's only possible if there *is* a better  
solution.

> > 2) Optional might not be needed either. If it is, it's only for  
> the
> > session feature, and that only if it's actually required to be
> > listed, and that could be solved by a new feature, pipelining, or  
> a
> > specific child for session's feature.
>
> My understanding was that we had some consensus to drop session  
> start.  In
> order to deal with backward-compatibility, we need to signal to new  
> clients
> that the feature is optional.
Agreed. There are a handful of server implementations out there that  
require session start. My client implementation (written a few years  
ago, now) simply doesn't bother with session start unless it sees the  
<session/> feature advertised, but I doubt that all clients will cope  
without the feature being advertised at all, sadly.


> TLS and session don't need to use the same syntax for expressing  
> these
> optional or required, but some have expressed that desire.  That's  
> how we've
> gotten to this point.  We could also (obviously) decide that this  
> is out of
> scope.
The thing is, there's no need at all to signal that TLS is optional.  
All features are optional, the only exception is session-start, which  
historically has been mandatory, and we now need to explicitly signal  
that it's optional.

So let's pick a method of doing so, and not turn this into a  
forced-march into the weeds.

Dave.
--
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
 - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
 - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade