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

Ralph Meijer <> Tue, 10 June 2014 08:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 386891A020B for <>; Tue, 10 Jun 2014 01:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IEwQBx5CqDid for <>; Tue, 10 Jun 2014 01:26:29 -0700 (PDT)
Received: from ( [IPv6:2001:16f8:4::61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 085261A02D9 for <>; Tue, 10 Jun 2014 01:26:29 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id CA0CFA1021 for <>; Tue, 10 Jun 2014 10:26:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with SMTP id WiD6p01WxrDw for <>; Tue, 10 Jun 2014 10:26:26 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id F3176A100F for <>; Tue, 10 Jun 2014 10:26:25 +0200 (CEST)
Message-ID: <>
Date: Tue, 10 Jun 2014 10:26:25 +0200
From: Ralph Meijer <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] draft-cridland-xmpp-session-00
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Jun 2014 08:26:31 -0000

On 2014-06-10 10:07, Kevin Smith wrote:
> On Tue, Jun 10, 2014 at 8:43 AM, Dave Cridland <> wrote:
>>> 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.
> 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

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.

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

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

>> 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 disagree. Clients only need to implement this if they want to benefit
from the removal of a roundtrip with servers advertising this flag.

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

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.