Subject: [xmpp] draft-cridland-xmpp-session-00

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Jun 2014 11:14:43 +0100

https://datatracker.ietf.org/doc/draft-cridland-xmpp-session/

After some discussion in the XSF's chatrooms, I've submitted this which I
think captures current practise and seems to be the least-unsensible option.

Happy to have the WG adopt this if the chairs and WG desire, otherwise I'll
go fishing for an AD sponsor.

The nub is as described in its Section 2:

2.  The Session Establishment Tombstone

   This specification formalizes the <optional/> marker and explicitly
   defines the Session Establishment request itself as a no-op.

Dave.

---

From: Lance Stout <[email-masked]>
Date: Mon, 9 Jun 2014 08:46:18 -0700

+1 for standardizing this. It's a pragmatic solution that lets us cut out a round-trip during session startup without worrying about older servers.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Jun 2014 10:22:24 -0600

> +1 for standardizing this. It's a pragmatic solution that lets us cut out a round-trip during session startup without worrying about older servers.

+1, seems fine. That was the thinking behind RFC 6121 but it seems that 
we neglected to make the <optional/> flag explicit.

Peter

---

From: Curtis King <[email-masked]>
Date: Mon, 9 Jun 2014 09:36:31 -0700

On Jun 9, 2014, at 9:22 AM, Peter Saint-Andre <[email-masked]> wrote:

> +1, seems fine. That was the thinking behind RFC 6121 but it seems that we neglected to make the <optional/> flag explicit.

Instead of adding an redundant flag into the XMPP spec. Why doesn’t this draft state the <optional/> flag explicit and give the session as an example? Otherwise we will be adding <optional/> to more features than session.

ck

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Jun 2014 17:38:12 +0100

A careful reading of RFC 3921 suggests that <session/> is itself optional -
if it's not there, it means you don't do it. So from a purely theoretical
standpoint, we were right to just drop it in 6121.

Unfortunately, it seems that existing clients (old versions of Smack, for
example) actually generate errors if it's not advertised, and in fairness,
it's not stand-out clear that <session/> wasn't mandatory for IM servers;
it certainly looks from 3921§C.1 that it's a requirement of XMPP (over
Jabber).

On 9 June 2014 17:22, Peter Saint-Andre <[email-masked]> wrote:

>> +1 for standardizing this. It's a pragmatic solution that lets us cut out
>> a round-trip during session startup without worrying about older servers.
>>
>
> +1, seems fine. That was the thinking behind RFC 6121 but it seems that we
> neglected to make the <optional/> flag explicit.
>
> Peter
>
>
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Dave Cridland <[email-masked]>
Date: Mon, 9 Jun 2014 17:54:01 +0100

On 9 June 2014 17:36, Curtis King <[email-masked]> wrote:

> Instead of adding an redundant flag into the XMPP spec. Why doesn’t this
> draft state the <optional/> flag explicit and give the session as an
> example? Otherwise we will be adding <optional/> to more features than
> session.
>

We've discussed, and rejected, this before, for example:

http://www.ietf.org/mail-archive/web/xmpp/current/msg02403.html
http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html

I'm not averse to reopening the discussion, though I'll still argue against
it. One or other of a generic <optional/> and <required/> will always be
redundant, and multiple <required/> elements will often conflict.

In any case, you'll note that <optional/> in this instance doesn't really
mean "optional" so much as "redundant" - in fact, I think the name is an
artifact of the discussion we had back then, though I can't find the thread
that proposes it in this case. (But both M-Link and Prosody do this, so I
assume it was discussed sometime).

Dave.

---

From: Curtis King <[email-masked]>
Date: Mon, 9 Jun 2014 20:44:27 -0700

On Jun 9, 2014, at 9:54 AM, Dave Cridland <[email-masked]> wrote:

> I'm not averse to reopening the discussion, though I'll still argue against it. One or other of a generic <optional/> and <required/> will always be redundant, and multiple <required/> elements will often conflict.
> 
> In any case, you'll note that <optional/> in this instance doesn't really mean "optional" so much as "redundant" - in fact, I think the name is an artifact of the discussion we had back then, though I can't find the thread that proposes it in this case. (But both M-Link and Prosody do this, so I assume it was discussed sometime).

It was in the 3921bis draft then removed. BTW, we are about to remove it from M-Link because it isn’t covered in any RFC or XEP.

This draft will require servers and client changes, you could accomplish the same goal by a pure informational draft pointing such features are optional. Then only certain clients need to change. Note: Good clients like Swift already ignore the session feature.

If you think it is clearer using a flag lets use a descriptive flag name like, rfc3921-compatibility.

cheers,

ck

---

From: Ralph Meijer <[email-masked]>
Date: Tue, 10 Jun 2014 09:19:50 +0200

> If you think it is clearer using a flag lets use a descriptive flag name like, rfc3921-compatibility.

The problem is that RFC 3921 said that you MUST negotiate Session
Establishment when advertised by the server [1]. RFC 6121 then had it
completely removed. While RFC 6120 says that by default stream features
are optional to negotiate, this one wasn't.

I think the idea is that if you do implement this flag (like Prosody and
M-Link), we know for certain that the server does indeed no longer
require Session Establishment.

If a client *requires* changes, this is because it has a bug:
negotiating session establishment while it has not been advertised. This
particular flag just makes it possible for a client to decide to not
negotiate Session Management as an optimization.

Eventually, when enough clients no longer show the above mentioned buggy
behaviour, we can remove this protocol from servers entirely.

[1] http://xmpp.org/rfcs/rfc3921.html#session

-- 
ralphm

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Jun 2014 08:43:40 +0100

On 10 June 2014 04:44, Curtis King <[email-masked]> wrote:

> I'm not averse to reopening the discussion, though I'll still argue
> against it. One or other of a generic <optional/> and <required/> will
> always be redundant, and multiple <required/> elements will often conflict.
>
> It was in the 3921bis draft then removed. BTW, we are about to remove it
> from M-Link because it isn’t covered in any RFC or XEP.
>
>
Right, this is an alternative way to solve that problem.

> This draft will require servers and client changes, you could accomplish
> the same goal by a pure informational draft pointing such features are
> optional. Then only certain clients need to change. Note: Good clients like
> Swift already ignore the session feature.
>
>
Then it's not a good client - the session feature, if advertised, is
mandatory. So if you remove the <optional/> marker from M-Link, every
conforming client has to negotiate it. You can't claim that if it's RFC
6121 only then it's exempt, because then certain servers won't work (I
think ejabberd is one that actually requires the <session/>, in line with
RFC 3921).

In an ideal world, we'd track down every client that requires the feature
to be advertised, unfortunately that means every client using Smack over a
certain age, which includes almost every Android client amongst others.

> like, rfc3921-compatibility.

I'm just documenting the status quo as deployed.

---

From: Lance Stout <[email-masked]>
Date: Tue, 10 Jun 2014 00:56:58 -0700

> I'm just documenting the status quo as deployed.

Coincidentally, I added support in stanza.io for the <optional/> flag the day before this I-D showed up, based on what Prosody does.

So there are both server and client implementations for this approach, as documented.

— Lance

---

From: Kevin Smith <[email-masked]>
Date: Tue, 10 Jun 2014 09:07:05 +0100

On Tue, Jun 10, 2014 at 8:43 AM, Dave Cridland <[email-masked]> wrote:
> mandatory.

Yeah, I don't believe this is true. Swift treats the session start as
unnecessary, but if it's offered by the server it'll negotiate it. The
relevant code is splattered around
http://swift.im/git/swift/tree/Swiften/Client/ClientSession.cpp

> So if you remove the <optional/> marker from M-Link, every
> conforming client has to negotiate it.

Every 3920/1 client, that is, rather than every 6120/1 client. yes?

> You can't claim that if it's RFC 6121
> only then it's exempt, because then certain servers won't work (I think
> ejabberd is one that actually requires the <session/>, in line with RFC
> 3921).

Right. Clients still need to implement this for old servers (I assume
modern ejabberd /doesn't/ require this, but very old versions are
undoubtedly out in the wild).

I think the draft is roughly the right thing to do. Nits:

od->of

<optional/> really isn't what this really is. Is there scope for
naming it <obsolete/>? How widely deployed are clients-servers that
use optional and are unlikely to be upgradable? I'm uncomfortable with
standardising that <optional/> means MUST NOT. If we have to do this,
we should probably add some text that <optional/> is only used in the
context of session startup.

/K

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Jun 2014 09:24:28 +0100

> I think the draft is roughly the right thing to do. Nits:
Thanks. I've also heard (from Openfire devs) that the statement explaining
where <optional/> should go isn't very clear, plus it could use an example
of the advertisement.

> context of session startup.
I think we do have to do this - as I say, this is based on deployed running
code. We get significant value by documenting the status quo over inventing
something new, and while I dislike <optional/> as a name, it's what we
have, and we know it works.

Looking back on it, though, saying <optional/> means "MUST NOT" is too
strong anyway; it should be "SHOULD NOT" at most, since it doesn't affect
interoperability. Perhaps "MAY", with a note saying it's a waste of a
round-trip?

I'll try some text.

Dave.

---

From: Ralph Meijer <[email-masked]>
Date: Tue, 10 Jun 2014 10:26:25 +0200

> http://swift.im/git/swift/tree/Swiften/Client/ClientSession.cpp

Oh, but it is. RFC 3921 says, section 3 says:

    Upon being so informed that session establishment is required [*]
    (and after completing resource binding), the client MUST establish
    a session [..]

[*] The part above that shows the stream feature being advertised, and
because of that wording I believe it implies that advertising Session
Establishment makes it required.

Then RFC 6121 only mentions that the protocol is unnecessary (Appendix
E), but doesn't explicitly make it optional when advertised. I.e. it
doesn't change the protocol, just doesn't document it any more.

> Every 3920/1 client, that is, rather than every 6120/1 client. yes?

I think you will find there are no pure forms of either, in reality.

> undoubtedly out in the wild).

I disagree. Clients only need to implement this if they want to benefit
from the removal of a roundtrip with servers advertising this flag.

> standardising that <optional/> means MUST NOT.

As I said before, adding this flag makes the client *choose* to not
negotiate Session Establishment, therefore making it optional. I don't
really care for renaming this with existing implementations (like your
own) already having this deployed in the field. I don't think it does
anyone a favour, except protocol purists. I do agree <optional/> should
mean 'SHOULD NOT negotiate'.

> If we have to do this, we should probably add some text that
> <optional/> is only used in the context of session startup.

I'm not sure what you mean here. To be sure, this flag is only being
defined for this namespace / stream feature.

-- 
ralphm

---

From: Kevin Smith <[email-masked]>
Date: Tue, 10 Jun 2014 09:33:58 +0100

> doesn't change the protocol, just doesn't document it any more.

You've said it's true that Swift's a bad client, then described
exactly what I said Swift does as being what a good client should do
:p

> I think you will find there are no pure forms of either, in reality.

True.

> from the removal of a roundtrip with servers advertising this flag.

'this' in this case being session establishment, not optional.

> mean 'SHOULD NOT negotiate'.

Well, protocol purists and potentially future implementers. I don't
think it's impossible that using 2119 language in protocol to mean
something very different from the 2119 meanings could cause
significant confusion.

But I'm not set against this, as I said earlier, I just wanted to
broach the question of doing the 'right' thing before we decide to
standardise the status quo.

> defined for this namespace / stream feature.

Yes. I think this is worth being explicit about.

/K

---

From: Curtis King <[email-masked]>
Date: Tue, 10 Jun 2014 01:34:11 -0700

> I'm just documenting the status quo as deployed.

Avoiding round trips is a good thing, since the <optional/> flag was not made explicit. I’m fine with draft.

ck

---

From: Ralph Meijer <[email-masked]>
Date: Tue, 10 Jun 2014 10:34:48 +0200

> It was in the 3921bis draft then removed. BTW, we are about to remove it from M-Link because it isn’t covered in any RFC or XEP.

Alas, <required/> elements are (or are not) defined per stream feature,
in whatever document specifies them, not in any generic way. You are
correct that we shot down that idea in the threads linked above.

This Draft proposes a flag to make optional negotiation explicit, while
RFC 3921 (the only document specifying the protocol) make it required by
default. Also, see my other messages.

As for the flag not being in any RFC or XEP, isn't that what this draft
is exactly about? It is not like there is any hurry in removing it from
your code base right now.

Chairs, I want to request this Draft to become a Workgroup item.

-- 
ralphm

---

From: Ralph Meijer <[email-masked]>
Date: Tue, 10 Jun 2014 10:44:00 +0200

On 2014-06-10 10:33, Kevin Smith wrote:
> [..]

Well, yeah:

 1) (New) clients need to implement negotiating Session Establishment to
interact with servers that advertise Session Establishment, but only if
advertized.

 2) Clients may have to negotiate Session Establishment to work around
broken servers that don't advertise, but do require it to be negotiated.
I hope this is never the case, though. If there are such implementations
in the wild, I hope to have them fixed *and* implement this draft.

 3) Clients already supporting Session Establishment, SHOULD (per the
upcoming version of this draft) skip negotiating Session Establishment.

> [..]

Agreed.

-- 
ralphm

---

From: Kevin Smith <[email-masked]>
Date: Tue, 10 Jun 2014 09:48:43 +0100

> interact with servers that advertise Session Establishment, but only if

Yes (and, post this Draft, only if not optional).

> in the wild, I hope to have them fixed *and* implement this draft.

Swift negotiates iff it is advertised. I'm not aware of any such broken servers.

> upcoming version of this draft) skip negotiating Session Establishment.

...when advertised as optional.

/K

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Jun 2014 09:58:20 +0100

On 10 June 2014 09:48, Kevin Smith <[email-masked]> wrote:

> On Tue, Jun 10, 2014 at 9:44 AM, Ralph Meijer <[email-masked]> wrote:>  3)
> Clients already supporting Session Establishment, SHOULD (per the
>

The odd thing about this draft is that <optional/> is mandatory. An
artifact of how one writes these things...

Right, I've gone for:

OLD: Clients SHALL ignore such advertisements.
NEW: Clients MAY ignore such advertisements, and are encouraged to do so.

So in RFC 2119 terms, it's truly optional, but for reasons other than
interoperability we're encouraging people to avoid the request.

Also, later on, I've added:

NEW: It is important to note that there is no value in performing this
request, and New clients are expected to elide the request when the
<optional/> marker is present.

https://github.com/surevine/openstd/commits/master/draft-cridland-xmpp-session-01.xml
(unsubmitted).

Dave.

---

From: Kevin Smith <[email-masked]>
Date: Tue, 10 Jun 2014 09:59:43 +0100

On Tue, Jun 10, 2014 at 9:58 AM, Dave Cridland <[email-masked]> wrote:
> The odd thing about this draft is that <optional/> is mandatory. An artifact
> of how one writes these things...
>
> Right, I've gone for:
>

Sounds great, thanks. An example of the stream feature, and a note
saying 'this is only defined in this namespace for this stream
feature' and I'll be happy.

/K

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Jun 2014 10:01:13 +0100

> feature' and I'll be happy.

I have the former, I'll do the latter now.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Jun 2014 10:11:45 +0100

Updated to -01: datatracker.ietf.org/doc/draft-cridland-xmpp-session/

Thanks for all the comments.

---

From: Kevin Smith <[email-masked]>
Date: Tue, 10 Jun 2014 10:21:54 +0100

> Updated to -01: datatracker.ietf.org/doc/draft-cridland-xmpp-session/

Apart from the one typo of > for <, this looks good. Thanks.

/K