Subject: [xmpp] the stream negotiation process

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Oct 2009 18:50:43 -0600

Earlier today I rewrote the section of 3920bis on stream features,
expanding it to cover the stream negotiation process in general. Thanks
to Jehan Pagès for pointing out to me in private conversation that this
topic was underspecified. My provisional text follows. I will review
this again next, but as always feedback is welcome.

######

5.2.  Stream Negotiation

5.2.1.  Overview

   Because the receiving entity for a stream acts as a gatekeeper to the
   domains it services, it imposes certain conditions for connecting as
   a client or as a peer server.  At a minimum, the initiating entity
   needs to authenticate with the receiving entity before it is allowed
   to send stanzas to the receiving entity, typically using SASL as
   described under Section 7.  However, the receiving entity can require
   other conditions in addition to authentication, such as encryption
   using TLS as described under Section 6.  The receiving entity informs
   the initiating entity about such conditions by communicating STREAM
   FEATURES: the set of particular protocol interactions that are
   mandatory for the initiating entity to complete before the receiving
   entity will accept XML stanzas from the initiating entity (e.g.,
   authentication), as well as any protocol interactions that are
   voluntary but that might improve the handling of an XML stream (e.g.,
   establishment of application-layer compression).

   The existence of such conditions implies that streams need to be
   negotiated, and the order of layers (TCP, then TLS, then SASL, then
   XMPP; see Section 14.5) implies that stream negotiation is a well-
   defined process.  Furthermore, stream features can be either
   mandatory or voluntary; this imposes further structure on the
   negotiation process.  Finally, for security reasons, the parties to a
   stream need to discard knowledge that they gained during the
   negotiation process after successfully completing the protocol
   interactions defined for certain features (e.g., TLS and SASL); this
   is done by flushing the old stream context and exchanging new stream
   headers over the existing TCP connection.

5.2.2.  Stream Features Format

   If the initiating entity includes the 'version' attribute set to a
   value of at least "1.0" in the initial stream header, after sending
   the response stream header the receiving entity MUST send a
   <features/> child element (prefixed by the streams namespace prefix)
   to the initiating entity in order to announce any conditions for
   continuation of the stream negotiation process.  Each condition takes
   the form of a child element of the <features/> element, qualified by
   a namespace that is different from the streams namespace and the
   default namespace.

   If negotiation of a particular stream feature is mandatory, the
   stream feature advertisement MUST include an empty <required/> child
   element.

   If negotiation of a particular stream feature is voluntary, the
   stream feature advertisement MAY include an empty <optional/> child
   element.  However, because every stream feature defaults to
   voluntary, the inclusion of an empty <optional/> child element is not
   necessary to indicate that a stream feature is voluntary.

   For security reasons, certain stream features necessitate the
   initiating entity to send a new initial stream header upon successful
   negotiation of the feature (e.g., TLS and SASL).  If a stream restart
   is necessary for any given feature, the <optional/> or <required/>
   child element MUST include a boolean 'restart' attribute with a value
   of "true" or "1" (this optional attribute defaults to false).
   Although it is expected that stream restarts will be necessary only
   for mandatory features, voluntary features are also allowed to
   necessitate restarts.

   Aside from the <optional/> child element, <required/> child element,
   and 'restart' attribute, the syntax and semantics of each particular
   feature are defined by an appropriate specification of that feature;
   several such features are defined in this document but stream
   features can be defined by other documents, as well.

   A <features/> element that contains at least one mandatory feature
   indicates that the stream negotiation is not complete and that the
   initiating entity MUST negotiate further features.

   R: <stream:features>
        <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
          <required/>
        </starttls>
      </stream:features>

   A <features/> element MAY contain more than one mandatory feature.
   This means that the initiating entity can choose among the mandatory
   features.  For example, perhaps a future technology will perform
   roughly the same function as TLS, so the receiving entity might
   advertise support for both TLS and the future technology.

   A <features/> element that contains only voluntary features indicates
   that the stream negotiation is complete and that the initiating
   entity is cleared to send XML stanzas, but that the initiating entity
   MAY negotiate further features if desired.

   R: <stream:features>
        <session xmlns='urn:ietf:params:xml:ns:xmpp-session'>
          <optional/>
        </session>
        <compression xmlns='http://jabber.org/features/compress'>
          <method>zlib</method>
          <method>lzw</method>
          <optional/>
        </compression>
      </stream:features>

   A <features/> element that contains both mandatory and voluntary
   features indicates that the negotiation is not complete but but that
   the initiating entity MAY complete the voluntary feature(s) before it
   attempts to negotiate the mandatory feature(s).

   R: <stream:features>
        <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
          <required/>
        </bind>
        <compression xmlns='http://jabber.org/features/compress'>
          <method>zlib</method>
          <method>lzw</method>
          <optional/>
        </compression>
      </stream:features>

   An empty <features/> element indicates that the stream negotiation is
   complete and that the initiating entity is cleared to send XML
   stanzas.

   R: <stream:features/>

      Note: The order of child elements contained in any given
      <features/> element is not significant.

   If the initiating entity does not understand or support a feature
   that has been advertised, it MUST still inspect the feature
   advertisement to determine if negotiation of the feature is
   mandatory.  If negotiation of an unsupported feature is mandatory and
   the receiving entity has offered no other mandatory features at that
   stage of the negotiation process, then the initiating entity MUST
   abort the stream negotiation process and SHOULD return an
   <unsupported-feature/> stream error to the receiving entity.  If
   negotiation of an unsupported feature is voluntary, the entity MUST
   silently ignore the associated feature advertisement and proceed with
   the stream negotiation process.

      Note: Implementations based on an earlier revision of this
      specification do not include the <optional/> child element and
      they include the <required/> child element only in the case of the
      STARTTLS feature.  Entities MUST accept stream feature
      advertisements without the child elements, and MUST consider
      negotiation of such features to be voluntary.

5.2.3.  Restarts

   On successful negotiation of a feature that requires a stream
   restart, both parties MUST consider the previous stream to be
   replaced but MUST NOT terminate the underlying TCP connection;
   instead, the parties MUST reuse the existing connection, which might
   be in a new state (e.g., encrypted as a result of TLS negotiation).
   The initiating entity then MUST send a new initial stream header,
   which SHOULD be preceded by an XML declaration as described under
   Section 12.5.  When the receiving entity receives the new initial
   stream header, it MUST generate a new stream ID (instead of re-using
   the old stream ID) before sending a new response stream header (which
   SHOULD be preceded by an XML declaration as described under
   Section 12.5).

5.2.4.  Resending Features

   After completing negotiation of any stream feature (even stream
   features that do not require a stream restart), the receiving entity
   MUST send an updated list of stream features to the initiating
   entity, where the list MAY be empty if there are no further features
   to be advertised.

   At any time after stream establishment and before closing of the
   stream, the receiving entity MAY send additional or modified stream
   feature advertisements to the initiating entity (e.g., because a new
   feature has been enabled).

5.2.5.  Completion of Stream Negotiation

   The receiving entity indicates completion of the stream negotiation
   process by sending to the initiating entity either an empty
   <features/> element or a <features/> element that contains only
   voluntary features.  Once stream negotiation is complete, the
   initiating entity is cleared to send XML stanzas over the stream for
   as long as the stream is maintained by both parties.

   The initiating entity MUST NOT attempt to send XML stanzas
   (Section 9) over the stream until stream negotiation has been
   completed.  However, if it does attempt to do so, the receiving
   entity MUST NOT accept such stanzas and MUST return a <not-
   authorized/> stream error.  This rule applies to XML stanzas only
   (i.e., <message/>, <presence/>, and <iq/> elements qualified by the
   default namespace) and not to XML elements used for stream
   negotiation (e.g., elements used to complete TLS negotiation
   (Section 6) or SASL negotiation (Section 7)).

5.2.6.  State Chart

   We summarize the foregoing rules in the following non-normative state
   chart, presented from the perspective of the initiating entity.

     +------------+
     |  open TCP  |
     | connection |
     +------------+
           |
    +---------------+
    | send initial  |<-------------------------------------------+
    | stream header |                                            |
    +---------------+                                            |
           |                                                     |
   +------------------+                                          |
   | receive response |                                          |
   | stream header    |                                          |
   +------------------+                                          |
           |                                                     |
    +----------------+                                           |
    | receive stream |                                           |
    | features       |                                           |
    +----------------+                                           |
           |                                                     |
        {empty?} ---> {all voluntary?} ---> {some mandatory?}    |
           |      no        |           no         |             |
           | yes            | yes                  |             |
           |                |                      |             |
           |          +---------------+     +----------------+   |
           |          | MAY negotiate |     | MUST negotiate |   |
           |          | any feature   |     | one feature    |   |
           |          +---------------+     +----------------+   |
           |                |                      |             |
           |                +--->-------+---<------+             |
           |                            |                        |
           |                    [restart required?] ------------>+
           |                            |              yes
           |                        no  |
           |                            |
           |                     +-------------+
           |                     | negotiation |
           +-------------------->| complete    |
                                 +-------------+

######

---

From: Waqas Hussain <[email-masked]>
Date: Sat, 3 Oct 2009 17:25:47 +0500

>   necessary to indicate that a stream feature is voluntary.

What namespace are these elements under? Just inheriting the namespace of
whatever feature they are included in is pretty evil. Elements are qualified
by their names AND namespaces. A name without a namespace and a namespace
without a name are meaningless. Specifying that a name has a given meaning
under any and all namespaces goes against the spirit of XML namespaces and,
if you think about it, is just plain Wrong(TM). Can we have a fixed
namespace for these elements please?

>   features can be defined by other documents, as well.

I'm afraid I missed the discussion where the <optional/> element and the
'restart' attribute were defined. Whether a feature requires a stream
restart or not is part of the definition of the feature (e.g., it's part of
the definitions of the SASL and STARTTLS features). If an entity understands
a feature, then it already knows whether a restart is required or not. What
value does the 'restart' attribute add? Are there any use-cases where the
'restart' attribute saves the day?

The only case where the 'restart' attribute might be useful is for features
which can work both with and without restarts, and the server needs to
specify at runtime whether it feels like doing a stream restart or not. I
don't see any need for such features. This brings to mind the restart-less
SASL/etc negotiation discussed last year, but those would be new features
with new definitions under new namespaces, and wouldn't need the 'restart'
attribute.

If the 'restart' attribute wasn't a MUST, the <optional/> element wouldn't
need to be defined either. There is just one case where it may be useful:
for indicating that the im-session feature is optional, and saving a round
trip, but then it might as well be defined for just that feature.

>   feature has been enabled).

This is pretty interesting. Features can change at runtime, and I had been
looking for a way to advertise that. One thing which does make me hesitate
in resending features is concern about how well existing clients and servers
would cope with receiving them. Does anyone have any experience with this?
How about a stream feature advertising an entity's ability to receive
feature updates?

--
Waqas Hussain

---

From: Jehan Pagès <[email-masked]>
Date: Mon, 5 Oct 2009 00:55:08 +0900

Hi,

On Sat, Oct 3, 2009 at 9:50 AM, Peter Saint-Andre <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

My general feedback is that it looks very good. :-) Exactly how I had
it in mind. Now it really becomes a "systematic" procedure, which can
very easily be implemented on both clients and servers as a simple
state machine.

Just a simple note on the graph: after "restart required?" state, the
"no" leads to "Receive stream features", and not to "Negotiation
complete". Negotiation may be complete, but the server still needs to
send an update <features> (even though it may be empty) for the client
to know it. This is well explained in your text, only the graph has
the bug.

On Sat, Oct 3, 2009 at 9:25 PM, Waqas Hussain <[email-masked]> wrote:
> On Sat, Oct 3, 2009 at 5:50 AM, Peter
> Saint-Andre <[email-masked]> wrote:
>>

Right, I wondered this as well. I think the <optional> and <required>
element should be under the stream namespace.

> with new definitions under new namespaces, and wouldn't need the 'restart'

I agree that 'restart' is not useful because, as you point it, if you
know/negotiate the feature, you know whether or not the restart will
be needed. And as you, I don't see a use case where it is useful...
but maybe there will be in future, then it is better to plan it?

That's the same thing as the <optional> element, I guess, but for
another reason: it is the default value. It adds semantic. But except
from this, it is useless. Hence <optional> may probably be safely
removed if everyone wants to.

> How about a stream feature advertising an entity's ability to receive

There don't need any feature (I guess by "stream feature", you meant
in fact an entity capability? Because a stream feature is sent by a
receiving entity, hence a server only) for that as it is already
currently in the core spec (rfc 3920bis at least, I have not read the
old 3920 for a while). So an entity is already supposed to be able to
receive feature updates (even though it is not forced to do anything
with it).
Now I don't know if there is any current implementation doing something with it.

I have another note to make about sending updated features while the
stream has already been negotiated. I raised it to Peter on private
the other day, but he had to go, so we couldn't finish the discussion.
Hence let's make it public now: what if the updated feature (in an
already established stream) contains a "required" feature?

Should the <required> element be forbidden in features updated after
stream establishement?

If not, does it mean that it suspends your stream as long as you have
not negotiated the new required feature (for instance a server which
strengthens live its stream negotiation and want to force any existing
connections to update?). Hence you cannot anymore send/receive
stanzas, and an unavailable presence to all your roster is implied...
Anyway something should be added about this (either an interdiction or
an explanation about how to deal with such a case).

Bye!

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Oct 2009 09:24:12 -0600

My apologies for the delayed reply.

On 10/3/09 6:25 AM, Waqas Hussain wrote:
> On Sat, Oct 3, 2009 at 5:50 AM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> What namespace are these elements under? Just inheriting the namespace
> of whatever feature they are included in is pretty evil. Elements are
> qualified by their names AND namespaces. A name without a namespace and
> a namespace without a name are meaningless. Specifying that a name has a
> given meaning under any and all namespaces goes against the spirit of
> XML namespaces and, if you think about it, is just plain Wrong(TM). Can
> we have a fixed namespace for these elements please?

I tend to agree. In fact I thought about it the morning after I wrote up
the text I posted, but never replied on the list. :)

In RFC 3920, the only feature that used <required/> was TLS. So we had
feature declarations like this:

R: <stream:features>

You are recommending instead something like this:

R: <stream:features>
     <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
       <stream:required restart='true'/>
     </starttls>
   </stream:features>

Now, what we've said is that the use of <required/> and <optional/> is a
convention that we will follow in defining all stream features, but I
think you're right that it's better to define one qualified name for
this, and probably place it in the streams namespace (we could define a
new namespace just for optionality of stream features, but I don't see a
compelling reason to do that).

> 'restart' attribute were defined. 

We're having that discussion now, at least for the 'restart' attribute
(when writing up the state chart for the stream negotiation process I
realized that it would be better to define restart explicitly instead of
saying that it's implicit in certain features).

> Whether a feature requires a stream
> restart or not is part of the definition of the feature (e.g., it's part
> of the definitions of the SASL and STARTTLS features). If an entity
> understands a feature, then it already knows whether a restart is
> required or not. What value does the 'restart' attribute add? Are there
> any use-cases where the 'restart' attribute saves the day?

IMHO it's better to be explicit than implicit in what's required
throughout the stream negotiation process.

> The only case where the 'restart' attribute might be useful is for
> features which can work both with and without restarts, and the server
> needs to specify at runtime whether it feels like doing a stream restart
> or not. I don't see any need for such features. This brings to mind the
> restart-less SASL/etc negotiation discussed last year, but those would
> be new features with new definitions under new namespaces, and wouldn't
> need the 'restart' attribute.

One example is SASL: certain SASL mechanisms might require a stream
restart (because they enable the negotiation of security layers) and
certain SASL mechanisms might not (in fact the IETF seems to be moving
away from security layers and toward channel bindings, so in the future
an XMPP server might not offer any SASL mechanisms that would truly
require a restart). In this case, why force a stream restart when it
isn't really necessary?

> If the 'restart' attribute wasn't a MUST, the <optional/> element
> wouldn't need to be defined either. There is just one case where it may
> be useful: for indicating that the im-session feature is optional, and
> saving a round trip, but then it might as well be defined for just that
> feature.

Well, <required/> and <optional/> are really not ideal because they're
defining a boolean. It would be better to have something like this:

R: <stream:features>
     <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
       <stream:usage required='true' restart='true'/>
     </starttls>
   </stream:features>

Here both attributes would default to FALSE.

> This is pretty interesting. Features can change at runtime, and I had
> been looking for a way to advertise that. One thing which does make me
> hesitate in resending features is concern about how well existing
> clients and servers would cope with receiving them. Does anyone have any
> experience with this? 

AFAIK, no XMPP software supports this behavior now.

> How about a stream feature advertising an entity's
> ability to receive feature updates?

Nothing in RFC 3920 forbids this behavior, and in any case what you want
is a feature that could be advertised by the initiating entity (so that
it can tell the receiving entity "yes I support feature updates").

But that gets into the question of feature declarations from the
initiating entity to the receiving entity, which is also interesting but
not yet defined.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Hildebrand <[email-masked]>
Date: Fri, 16 Oct 2009 15:49:44 -0600

(as individual)

> compelling reason to do that).

+1.  I really like that approach.

> throughout the stream negotiation process.

It also makes writing clients much easier, because they can process stream
restarts generically.

> Here both attributes would default to FALSE.

As well, servers SHOULD allow SASL restarts even if restart='false', for
backward-compatibility.

> initiating entity to the receiving entity, which is also interesting but

The question is whether late stream features will break existing client
software.  I think there is a possibility.  I've had several bad ideas about
how to have clients and servers know that they both support this, but all of
them are heavy-weight compared to a) the utility and b) the risk.

Maybe we should just do some client/library testing to see what happens. :)

-- 
Joe Hildebrand

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 19 Oct 2009 22:48:41 -0600

On 10/19/09 3:46 PM, "Dave Cridland" <[email-masked]> 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".

> 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.

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.

> So really, I think we're chasing ghosts, here. If there's
> optimizations to be made, let's please figure them out and make them.
> But making things too generic is simply over-engineering something
> that actually works just fine right now.

Hence the "several bad ideas" I referred to in my previous mail.  I don't
think anyone has proposed an acceptable solution to modifying stream
features on the fly, so in the absence of an extraordinarily compelling use
case, I agree that keeping it simple makes sense.

-- 
Joe Hildebrand

---

From: Dave Cridland <[email-masked]>
Date: Mon, 19 Oct 2009 22:46:41 +0100

> +1.  I really like that approach.
I think this is better than the original proposition, but my worry is  
that it only makes sense when there is, for sake of example, only one  
way to skin a cat.

When there are multiple features that fulfill the requirements, it  
seems that the logic becomes fairly complex. I don't see this  
happening for cases like TLS, in fact, for reasons I'll go into in a  
second, but for post-auth cases, I think we're trying to solve a  
problem for which we have no use cases.

For preauth, what the server is actually trying to express is  
generally security requirements. Perhaps the logical thing to do, if  
we really want to radically change the old <required/>, is to have  
the server provide security requirements in some form - that form  
seems like something for some other working group to solve, though.

But really, what we're trying to do is usually pretty simple -  
require encryption or not.

The simple approach here is to provide features like:

<s:features>
	<starttls/>
	<mechanisms><mechanism>GSSAPI</mechanism></mechanisms>
</s:features>

Then the client gets to pick one of those two. Picking <starttls/>  
gives it TLS, and the servers offers more mechanisms - mechanisms  
without a security layer as well, probably.

Notice I've not used <required/>. I'm not convinced that <required/>  
is even needed here. The interesting case is actually <optional/>,  
which *is* required for the old session stuff - if it weren't for the  
fact you can pipeline it. (And here I assume there may be good  
reasons to list the feature for old clients, but I'm not convinced).

> It also makes writing clients much easier, because they can process  
I think you must write clients in a wholly different way to me. My  
XMPP client (the one I wrote for myself) has precisely two lines  
devoted to the thorny issue of stream restarts. I just don't see the  
problem. Surely the definition of the feature is very explicit in  
whether or not the feature requires a stream restart?

(Incidentally, I just looked at the relevant places in our server  
code, and there's *four* lines, there. It's sheer madness, escalating  
out of control, and it must stop now! Or maybe not.)

I mean, if I suddenly decide that the resource binding requires a  
stream restart, what on earth should a client do? Restart the stream  
once it receives an <iq type='result'/>? With what from attribute?  
What does a server do if the client doesn't restart? Reject it? With  
what error?

> As well, servers SHOULD allow SASL restarts even if  
Yay. But you can only not require a restart for TLS and SASL if you  
also allow for mid-stream feature updates.

We need this because the security properties of the stream may  
change, and it's *far* easier to mandate a restart in all cases of  
TLS and SASL, instead of merely "when the security properties  
change". (It'd be marginally easier with SASL, actually, since when  
the security properties change the client generally knows about it,  
but still.)

I really don't think that leaving this to server choice is very wise  
at all.

> them are heavy-weight compared to a) the utility and b) the risk.

Right. And without this there is no longer any value to avoiding  
restarts for TLS, certainly, and SASL, probably.

> Maybe we should just do some client/library testing to see what  

Yes, because luckily, we're confident we can exhaustively test all  
extant XMPP clients with all possible feature changes.

The XMPP community is pretty close-knit, but not that close-knit.

Besides which, features are for stream properties - by the time the  
stream is established, it's too late to change these. If the change  
is, say, mandating TLS, then you *want* to kick off all your  
connections.

Instead, if people really want to shave a restart off SASL, have an  
extra parameter to <auth/> which causes the server to drop support  
for security layers, and pipeline a <stream:features/> after the  
<success/>. Perhaps - because it's a zero-octet switchover, it makes  
some sense there.

Doing the same for TLS is much harder - in principle it's possible,  
but won't save any round-trips if client session resumption is being  
used, if memory serves. (More round-trips are saved by batshit crazy  
stuff like Stunt Buffering, as Tony Finch once called it).

So, here's a summary:

3) Altering restart behaviour on the fly is only possible if features  
can be sent on the fly.

4) And they can't - it's simply too big a change for the protocol.

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

---

From: Dave Cridland <[email-masked]>
Date: Tue, 20 Oct 2009 08:58:18 +0100

> 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.

> 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.

> gotten to this point.  We could also (obviously) decide that this  
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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 21 Oct 2009 08:45:15 -0600

On 10/20/09 1:58 AM, Dave Cridland wrote:

<snip/>

Dave, let me see if I can summarize your perspective...

1. Negotiation of all stream features is optional. If the receiving
entity considers negotiation of a given feature to be mandatory, it will
advertise only that feature; and if the initiating entity does not
negotiate that feature (e.g., by attempting to send stanzas before it is
allowed to do so), then the receiving entity will return an error to the
initiating entity. Therefore, we have no need to specify over the wire
if a given stream feature must be negotiated at any given stage of the
stream negotiation process.

2. Whether a stream restart is mandatory is defined by the stream
feeature and does not need to be specified on the wire. All that 3920bis
needs to say is that the definition of a stream feature must specify
whether stream restarts are necessary after negotiation of that feature.

Is that an accurate summary?

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Oct 2009 14:08:08 -0600

My apologies for the long post...

> Dave, let me see if I can summarize your perspective...

Because I am working to publish revised versions of 3920bis and 3921bis
by the I-D cutoff date on Monday, I shall assume that my summary is
accurate. :)

> stream negotiation process.

For TLS, we felt the need in RFC 3920 to define a method whereby the
server could flag negotiation of TLS as mandatory to negotiate ("MTN")
in order to enforce local service policies. The discussions since then
have always assumed that we need a way to flag (some) features as MTN.
The thread here has attempted to define MTN in a standardized way,
rather than assuming that MTN will be explicit in the definition of some
features (TLS) but not others (everything else), implicit in the
definition of a given feature (SASL is always mandatory) or implicit via
the inclusion of a given feature and only that feature at a particular
point in the stream negotiation process (what Mr. Cridland appears to be
suggesting).

I think the following are very different:

(a) As the first stream features, inform the initating entity that TLS
is MTN.

   <stream:features>

(b) At some point in the stream negotiation process, inform the
initiating entity that SASL is MTN.

   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
     </mechanisms>
   </stream:features>

(c) As the last stream features (after resource binding), inform the
initiating entity that stream compression is voluntary to negotiate ("VTN").

   <stream:features>

If we say that a feature is MTN if it is the only feature advertised at
a particular point in the stream negotiation process, then (c) would
mean compression is MTN after resource binding. Because that is
non-sensical, I must conclude that all features are VTN unless
explicitly defined otherwise (i.e., we cannot deduce that a feature is
MTN simply by the absence of other features in that particular instance
of stream features advertisement).

The initiating entity can implicitly know that a given feature is MTN
(we "just know" that SASL is MTN because you must authenticate) or the
receiving entity can explicitly inform the intitiating entity (we don't
"just know" and therefore need a way for the receiving entity to inform
the initiating entity that Feature X is MTN).

I don't like these things to be implicit (the stream feature approach is
open-ended and we don't know what features people might define in the
future), which is why I think that we need some kind of method for
explicitly signalling that a feature is MTN. We have two options:

1. Place the burden on each stream feature. Therefore we might end up
with things like this:

   <stream:features>

vs.

   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
                 mandatory='true'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
     </mechanisms>
   </stream:features>

vs.

   <stream:features>
     <compression xmlns='http://jabber.org/features/compress'>
       <method>zlib</method>
       <method>lzw</method>
       <you-gotta-negotiate-this/>
     </compression>
   </stream:features>

2. Define a generalized data structure that can be re-used by all stream
features.

   <stream:features>
     <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
       <stream:usage mandatory='true'/>
     </starttls>
   </stream:features>

   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
       <stream:usage mandatory='true'/>
     </mechanisms>
   </stream:features>

   <stream:features>
     <compression xmlns='http://jabber.org/features/compress'>
       <method>zlib</method>
       <method>lzw</method>
       <stream:usage mandatory='true'/>
     </compression>
   </stream:features>

Option #2 is a lot cleaner, it can be re-used by any stream feature that
people might define in the future, it simplifies processing by the
initiating entity, and it reduces the chance of nasty surprises (e.g.,
disconnections because the initiating entity assumed that Feature X was
VTN while the receiving entity assumed that Feature X was MTN).

> whether stream restarts are necessary after negotiation of that feature.

Here again, I think it would be helpful to be explicit about whether a
restart is needed or not. In general, stream restarts apply to any
protocol in which the entities need to discard information received in
an insecure manner before the given feature was negotiated. Right now
that is true only for TLS and for SASL-with-security-layers. It is
probably unlikely that we will define new technologies that also force
stream restarts (since they would essentially be replacements for TLS or
for SASL-with-security-layers), so I am not as worked up about defining
an explicit signalling method here. However, it seems to me that if we
are defining an explicit signalling method for MTN vs. VTN then we might
as well define one for restarts while we're at it. I will update -03
along these lines and flag this as an item for discussion on the list
and in Hiroshima.

There is one more issue that is still unclear in -02: how to handle
stream feature advertisements that contain multiple features. The
following combinations are possible:

(a) 1+ features, all of which are MTN.
(b) 1+ features, 1 or 1+ (but not all) of which are MTN.
(c) 1+ features, none of which are MTN.

In the case of (a) I think the initiating just picks one MTN feature to
negotiate based on local preferences.

In the case of (b) I think the initiating entity can negotiate one of
the VTN features (say, in-band registration instead of SASL) or one of
the MTN features, but it needs to negotiate something.

In the case of (c) I think the initiating entity can negotiate any of
the features or none of the features.

I tried to capture this in the state chart, but I've made a few edits to
the chart since -02 and those will show up in -03.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 23 Oct 2009 05:49:30 +0500

> have always assumed that we need a way to flag (some) features as MTN.

And that's the assumption being questioned here :-)

> of stream features advertisement).

As far as I can see, the need here isn't for individual features to be MTN
or VTN, but a way for the server to indicate its readiness for normal XMPP
IM. From what I have seen, the algorithm clients (and servers) tend to use
is to negotiate all negotiable features they are able and configured to
negotiate, and as the last step they bind a resource. At this point they
assume the server is ready for XMPP IM. This seems reasonable enough, and I
have not seen clients actually testing individual features for being MTN or
VTN.

While what I just said applies to C2S, the process used by other initiating
entities isn't any different. The initiating entities are only interested in
the stream's readiness for their purposes, not about individual features
being MTN or VTN (or non-negotiable; not all features are negotiable).

> VTN while the receiving entity assumed that Feature X was MTN).

If the MTN vs. VTN distinction was really necessary, I would agree.

> along these lines and flag this as an item for discussion on the list

If the MTN vs. VTN distinction was really necessary, this would be still be
arguable.

> the MTN features, but it needs to negotiate something.

So, basically as far as the initiating entity is concerned, there is no
distinction between (a) and (b). The initiating entity will do the same
thing for either case: Pick any one feature it likes.

> the features or none of the features.

And only (c) really matters. That is, all that matters is a signal that
negotiation is complete. Currently, for C2S this is assumed to be the case
after resource binding, and for S2S this is assumed to be the case after
auth (SASL or dialback). Your goal seems to be making this explicit.
Wouldn't a simple stream feature making this explicit be enough? What would
an MTN/VTN flag on each feature buy us that a <negitiation-complete/> (or
more appropriately <xmpp-im/>, etc) feature will not?

--
Waqas Hussain

---

From: Justin Karneges <[email-masked]>
Date: Thu, 22 Oct 2009 18:07:52 -0700

> point in the stream negotiation process (what Mr. Cridland appears to be

I feel similar to Dave on this matter, that the suggested changes to stream 
features amount to overengineering.

If we want a future feature to be required, it should be enough to state in 
the spec that it is required.  A client isn't going to say to an 
end-user: "Sorry, the server requires the 'ugly-long-namespace' feature in 
order to log in."  Either the client will display a generic error ("Sorry, 
the server requires a feature not supported by this client"), or it will be 
spec-aware and display ("Sorry, the server requires the Foo feature, which is 
not supported by this client" (except that it sort of is, if the client can 
write such a message..)).

Sure, a generic way to flag any feature as required would allow a client to 
easily display the generic "feature not supported" error message.  Otherwise, 
as mentioned, the client would have to send a stanza and receive an error in 
order to determine that there was an unnegotiated required feature.  I'm 
partial to using an error as a solution, since it requires the least amount 
of change to XMPP.  I'd suggest a stream error here and not (or not merely) a 
stanza error.

Finally, I want to say that very few features should be required at all 
anyway.  TLS, SASL, and resource binding are the only ones that matter.  
Everything else should almost always be optional.  Is anyone really planning 
to require compression or stream management for example, to the point where 
the client can't even use the service without them?  I don't think you will, 
but in the chance that you do, you can bounce the client off with a stream 
error.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Oct 2009 21:32:12 -0600

On 10/22/09 7:07 PM, Justin Karneges wrote:
> the spec that it is required.  

Sometimes TLS is required and sometimes it isn't -- that depends on the
local service policy.

The case of SASL or dialback for s2s is interesting, but we have never
clearly defined that. It might be that the receiving entity would
require either SASL or dialback in some situations, in which case SASL
is not required in all circumstances (again, it depends on the context).

> A client isn't going to say to an 

Of course it must be a stream error -- the initiating entity hasn't
necessarily sent any stanzas (e.g., if it hasn't completed SASL
negotiation yet).

> anyway.  TLS, SASL, and resource binding are the only ones that matter.  

TLS or something very much like it. SASL or something very much like it.
Resource binding or something very much like it. But, in case we should
ever design or re-use things very much like TLS, SASL, and resource
binding then most likely those features would be defined as required, too.

> but in the chance that you do, you can bounce the client off with a stream 

Sure, if people find that acceptable. My concern is not so much with
endless extensibility and future-proofing, but with features that right
now can be either mandatory or voluntary depending on local service
policies.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Oct 2009 21:56:37 -0600

On 10/22/09 6:49 PM, Waqas Hussain wrote:
> On Fri, Oct 23, 2009 at 1:08 AM, Peter Saint-Andre <[email-masked]

Do you question the assumption that local service policies might
necessitate flagging TLS as mandatory to negotiate? If so, then either
you are saying that a service can never force TLS on c2s or s2s
connections or that TLS must always be mandatory to negotiate.

> As far as I can see, the need here isn't for individual features to be
> MTN or VTN, but a way for the server to indicate its readiness for
> normal XMPP IM. From what I have seen, the algorithm clients (and
> servers) tend to use is to negotiate all negotiable features they are
> able and configured to negotiate, and as the last step they bind a
> resource. At this point they assume the server is ready for XMPP IM.
> This seems reasonable enough, and I have not seen clients actually
> testing individual features for being MTN or VTN.

That seems reasonable. However, let's say my client is configured to
prefer TLS connections, whereas the server I connect to is configured to
mandate TLS. I try to connect but the server offers only TLS. Does my
client negotiate TLS or not? I suppose it does ("use TLS if available"
is the usual configuration option in mail and IM clients).

> While what I just said applies to C2S, the process used by other
> initiating entities isn't any different. The initiating entities are
> only interested in the stream's readiness for their purposes, not about
> individual features being MTN or VTN (or non-negotiable; not all
> features are negotiable).

Correct.

> If the MTN vs. VTN distinction was really necessary, I would agree.

It is necessary for TLS and (depending on your interpretation of
TLS-plus-dialback vs. SASL) it might be necessary for SASL. Other than
that, I tend to agree.

> If the MTN vs. VTN distinction was really necessary, this would be still
> be arguable.

I suppose you would argue that stream restarts are mandatory after TLS
and SASL but are not needed for any other features. In today's world
that is valid. We can simply say that stream features need to define
whether they require a stream restart after being negotiated (and right
now that would apply only to TLS and SASL).

> thing for either case: Pick any one feature it likes.

Quite possibly, yes. I need to think about that a bit more.

> negotiation is complete. Currently, for C2S this is assumed to be the
> case after resource binding, and for S2S this is assumed to be the case
> after auth (SASL or dialback). Your goal seems to be making this
> explicit.

Not only this. I don't like all this implicit stuff in the protocol
because it seems to open up potential problems. But perhaps I'm worried
about things that aren't deserving of worry.

> Wouldn't a simple stream feature making this explicit be
> enough? What would an MTN/VTN flag on each feature buy us that a
> <negitiation-complete/> (or more appropriately <xmpp-im/>, etc) feature
> will not?

If we had status messages instead of only error messages, we could
handle this with some kind of stream status. It doesn't quite seem like
a stream feature:

   <stream:features>
     <you-are-now-cleared-for-sending-stanzas/>
   </stream:features>

But, as you say, perhaps it's enough to say that for c2s you are cleared
for sending stanzas after resource binding, and for s2s after SASL or
dialback. That seems to have worked just fine for the last 10 years, so
there's probably no reason to fix it. :)

>     the chart since -02 and those will show up in -03.

Interestingly, the state chart pretty much stays the same (perhaps
except for the distinction between (a), (b), and (c) above) no matter
whether we define things explicitly or implicitly...

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Justin Karneges <[email-masked]>
Date: Thu, 22 Oct 2009 21:56:54 -0700

On Thursday 22 October 2009 20:32:12 you wrote:
> > I feel similar to Dave on this matter, that the suggested changes to
> > stream features amount to overengineering.
> >
> > If we want a future feature to be required, it should be enough to state
> > in the spec that it is required.
>

Yes, I should have been more clear: the spec would define the feature's 
requiredness, whether that means always required or only sometimes.  For 
example, TLS is required if <required/> is present as a child element, and 
resource binding is always required.

I understand the rationale for wanting to make <required/> a generic concept, 
because it might be handy if we find ourselves defining such a flag for lots 
of features.  I guess my question is if anyone is really wanting to make all 
those features flaggable.  Right now, only TLS has this flag, and the rest of 
the features are defined as either required or optional.

> is not required in all circumstances (again, it depends on the context).

Something to define, then. :)

> > end-user: "Sorry, the server requires the 'ugly-long-namespace' feature
> > in order to log in."  Either the client will display a generic error
> > ("Sorry, the server requires a feature not supported by this client"), or
> > it will be spec-aware and display ("Sorry, the server requires the Foo
> > feature, which is not supported by this client" (except that it sort of
> > is, if the client can write such a message..)).
> >
> > Sure, a generic way to flag any feature as required would allow a client
> > to easily display the generic "feature not supported" error message. 
> > Otherwise, as mentioned, the client would have to send a stanza and
> > receive an error in order to determine that there was an unnegotiated
> > required feature.  I'm partial to using an error as a solution, since it
> > requires the least amount of change to XMPP.  I'd suggest a stream error
> > here and not (or not merely) a stanza error.
>

How else would the receiving entity know to send an error?  If I negotiate TLS 
and then just sit there and not negotiate SASL, the server shouldn't boot me 
(well except due to a timeout, but that's not the same thing as skipping over 
a required feature).  The server pretty much has to wait for me to make a 
wrong move.  Maybe you mean if I try to negotiate a stream feature out of 
sequence?  That would be one non-stanza way of me doing something wrong.

> binding then most likely those features would be defined as required, too.

If an alternative feature to SASL existed (let's call it NGAuth), I think the 
best approach would be for the new feature to define not only itself but its 
relationship to SASL.  For example, if both are offered, then the NGAuth is 
preferred, else SASL is used.

I don't think <required/> flags would be enough to drive this.  You'd need a 
way to specify that one deprecates the other or should be tried before the 
other, and that only one of them should be used.

In the case of ensuring only one of these features is used, and not both, of 
course the server could be smart about how the features are offered.  For 
example, on the first pass it could offer both NGAuth and SASL, but if NGAuth 
is used and succeeds then the next set of stream features would not contain 
either of them.  That said, the client shouldn't be so dumb that it relies on 
the server for this logic.  A client shouldn't auth twice, and it should know 
that it only needs one of NGAuth or SASL because it would say so in the spec.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Oct 2009 07:51:38 -0600

> sequence?  That would be one non-stanza way of me doing something wrong.

A stanza is <iq/>, <message/>, or <presence/>. If the server is
expecting SASL and I try to negotiate XEP-0198 support or dialback or
whatever, I haven't sent a stanza so how can the server return a stanza
error to me?

> that it only needs one of NGAuth or SASL because it would say so in the spec.

That seems reasonable.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 23 Oct 2009 16:20:52 +0200

Peter Saint-Andre wrote:
[...]
> whatever, I haven't sent a stanza so how can the server return a stanza

In the case of dialback that is rather easy now that we have dialback
errors in xep 220. The additional error conditions might be:
* policy-violation: dialback without tls when tls is required by policy
* forbidden: dialback with tls but invalid certificate

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Oct 2009 10:24:56 -0600

On 10/23/09 7:59 AM, Dave Cridland wrote:
> On Fri Oct 23 14:51:38 2009, Peter Saint-Andre wrote:
> Well, why would you try to negotiate XEP-0198 if you're not yet
> authenticated?

Because you're stupid. Well, you aren't, but your software is. :)

> That's surely an error in all cases.

It is. But it's not a stanza error. That's my only point here.

> So you'd have to do SASL (or XEP-0078, or XEP-0220, both of which have
> defined errors if they're attempted when in fact disabled) first.

Indeed.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Oct 2009 10:27:46 -0600

On 10/23/09 8:20 AM, Philipp Hancke wrote:
> Peter Saint-Andre wrote:
> [...]
>>> How else would the receiving entity know to send an error?  If I
>>> negotiate TLS and then just sit there and not negotiate SASL, the
>>> server shouldn't boot me (well except due to a timeout, but that's
>>> not the same thing as skipping over a required feature).  The server
>>> pretty much has to wait for me to make a wrong move.  Maybe you mean
>>> if I try to negotiate a stream feature out of sequence?  That would
>>> be one non-stanza way of me doing something wrong.
>>

Correct. My only point in this context is that the server can't send you
a stanza error out of the blue -- you need to send a stanza first. If
you haven't sent any stanzas yet but you have sent other things over the
stream before you are authenticated or cleared for sending stanzas, then
the server needs to send you a stream error, not a stanza error. A very
simple point. :)

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 23 Oct 2009 10:44:58 -0600

On 10/23/09 8:39 AM, Matthew Wild wrote:
> I disengage from mailing lists for 24 hours and look where it gets me... :)

I assume that you meant to reply-to-all, so I am replying to the list.

> Apologies for the semi-top-post, but I'd like to summarise my response
> to some earlier posts in the thread. Give a shout if I've missed the
> gist of anything.
> 
> I agree with Justin that any required/optional/restart flags are
> over-engineering. The current process works just fine. To clarify,
> this is how I see it working now:
> 
> Loop
>    Server offers a set of features available to the client at the current time
>    Client chooses and negotiates its most preferred option
> Until connection complete
> 
> That is to say, if TLS is required... what we really mean is that "TLS
> is required before you can authenticate" (or compress, or etc.). So we
> would end up with TLS being the only feature published to the client
> at the start.

Basically you and others are saying that until the initiating entity is
 cleared to send stanzas, it needs to treat a feature as required if the
server advertises only that feature. Correct?

> The feature negotiation process is not a shopping list, but a tree.
> The current system also allows use to advertise different SASL
> mechanisms depending on whether the client has negotiated TLS or not
> yet.

Indeed.

> Now the most interesting thing is how to detect when the server is
> ready for you to send stanzas. Isn't this when it offers resource
> binding to the client? 

Yes.

> If we really need to define anything else,
> could we perhaps re-use the IM session feature (which Dave has been
> muttering about for a while).

At the very first XMPP Summit and interop event in July 2006, we had
strong consensus among all the server and client developers present that
the im-session feature was a no-op. I haven't seen anything since then
that would lead me to change my mind.

> More follows...
> 
> 2009/10/23 Peter Saint-Andre <[email-masked]>:
> I disagree (even if we have abandoned the "smart servers, simple
> clients" philosophy which used to be so prevalent round here). The
> logic *is* defined by the server (and its admin), it's the server that
> is choosing what is required and what is not, and so I'd consider it a
> bug for the server to offer an authentication method when the stream
> is already authenticated.
> 
> The current system is nice and flexible, I don't see anything that
> needs changing. What did I miss?

Nothing. Version -03 of 3920bis will keep things as-is, just explain the
state transitions more clearly.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Matthew Wild <[email-masked]>
Date: Fri, 23 Oct 2009 18:03:29 +0100

> I assume that you meant to reply-to-all, so I am replying to the list.

Indeed yes, too long away from mailing lists, like I said :)

> server advertises only that feature. Correct?

It needs to treat the list of features offered by the server as
"choose one of these to continue", so yes if TLS is mandatory before
any other negotiation can continue, it would appear on its own. I'm
trying to differentiate from the earlier "mark a feature as MTN by
offering it alone", because if there are multiple MTN features in
which negotiation order does not matter, they could all be offered
together.

> that would lead me to change my mind.

Agreed. I'll leave it for Dave if he does want to resume this in the
context of this thread.

> state transitions more clearly.

All good to me, thanks,
Matthew

---

From: Justin Karneges <[email-masked]>
Date: Fri, 23 Oct 2009 11:58:04 -0700

> which negotiation order does not matter, they could all be offered

I'm not opposed to deferring features from appearing as a way of making other 
features required.  But first: does anyone know if not offering SASL on the 
first pass could cause a problem with existing code?  Or if it may violate 
RFC 3920?

This approach could also be used to force the client to enable features in a 
certain sequence, though for most features there is already a defined order 
that the server can't muck with.  For example, a server can't make a client 
negotiate TLS after SASL, or make it negotiate resource binding without 
having done SASL.  These would be considered protocol errors by the client.

-Justin

---

From: Matthew Wild <[email-masked]>
Date: Fri, 23 Oct 2009 20:22:45 +0100

> first pass could cause a problem with existing code?  Or if it may violate

It's what Prosody does and it's working great as far as I can see. If
it really does violate the RFC (I don't see why) then I propose we fix
the RFC :)

> having done SASL.  These would be considered protocol errors by the client.

The RFC could define a recommended order, TLS <= SASL, SASL < binding, etc..

Matthew.

---

From: Justin Karneges <[email-masked]>
Date: Fri, 23 Oct 2009 12:30:12 -0700

On Friday 23 October 2009 12:22:45 you wrote:
> > This approach could also be used to force the client to enable features
> > in a certain sequence, though for most features there is already a
> > defined order that the server can't muck with.  For example, a server
> > can't make a client negotiate TLS after SASL, or make it negotiate
> > resource binding without having done SASL.  These would be considered
> > protocol errors by the client.
>

It already does.  However it's a bit more than "recommended".  It's the 
required sequence.  If a server offers binding before SASL, for example, it's 
not like the client is going to use binding and say "woo-hoo I'm in!".  
Instead the client going to disconnect and present an error to the user, 
since the server is speaking nonsense.

-Justin

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 23 Oct 2009 21:30:59 +0200

> it really does violate the RFC (I don't see why) then I propose we fix

+1
I would not expect problems either, because the TLS+SASL PLAIN path
exists.

> The RFC could define a recommended order, TLS <= SASL, SASL < binding, etc..

xep 0170 does that already :-p

---

From: Matthew Wild <[email-masked]>
Date: Fri, 23 Oct 2009 20:34:15 +0100

> not like the client is going to use binding and say "woo-hoo I'm in!".

If the server offers binding then I see no reason it couldn't do exactly that :)

> since the server is speaking nonsense.

If the server speaks nonsense, all hope is lost. It's an
implementation issue, and not a protocol issue.

Matthew

---

From: Dave Cridland <[email-masked]>
Date: Fri, 23 Oct 2009 14:59:17 +0100

So you'd have to do SASL (or XEP-0078, or XEP-0220, both of which  
have defined errors if they're attempted when in fact disabled) first.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 26 Oct 2009 11:36:59 +0000

> first pass could cause a problem with existing code?  Or if it may  

Just to pick up on this point, features can surely only be advertised  
if they're available.

If they're not available - because the client cannot use them in this  
stream, since it needs to do the TLS dance and make a new stream -  
then they shouldn't be advertised.

If you're reading RFC 3920 as saying that all possible features -  
even those not yes available - must be listed, then I'd think that  
would need clarification.

Dave.

---

From: Matthew Wild <[email-masked]>
Date: Thu, 29 Oct 2009 09:32:31 +0000

2009/10/26 Dave Cridland <[email-masked]>:
> Just to pick up on this point, features can surely only be advertised if
> they're available.
>
> stream, since it needs to do the TLS dance and make a new stream - then they
> shouldn't be advertised.
>
> If you're reading RFC 3920 as saying that all possible features - even those
> not yes available - must be listed, then I'd think that would need
> clarification.
>

Agreed, this is how I interpret it also.

Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Oct 2009 06:43:29 -0600

> Agreed, this is how I interpret it also.

The text in 3920bis (and I think also 3920) talks about "available
features", but if need be we can clarify this a bit further.

Peter

- --
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Oct 2009 07:31:26 -0600

> features", but if need be we can clarify this a bit further.

I've added a few minor clarifications about this to my working copy.

Peter

- --
Peter Saint-Andre
https://stpeter.im/