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

Kevin Smith <> Tue, 10 June 2014 08:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B6E551A020B for <>; Tue, 10 Jun 2014 01:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bC74IFVcGR4t for <>; Tue, 10 Jun 2014 01:34:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A18A1A01B3 for <>; Tue, 10 Jun 2014 01:34:00 -0700 (PDT)
Received: by with SMTP id w62so2646630wes.10 for <>; Tue, 10 Jun 2014 01:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zEd//bZAOBz0Z7SgD2DS2DmNstyqVf1kCkw49UVjivU=; b=tmR/YSuXbrFHvsKRlfcjkgaw0bHLtILTv+ClFoHTH4ktcf67IIuDjBEscXLCxSdXZQ y4OjyZPFSckz+TX1d2U4XwkZ+1Ul7sP+SCE478izP5/XX/WMHIFKyXLE0sfGKcXC0jRJ ybgdt9Ve2Uql6osxuF4w2PbWANqe94J0848Zm4tjuqNLxNYXFiZ/ln1qe65CwRVrbHv7 YWZbDIlrpMpRBvjDSctO8U3V1LvBh5IG1PXAmidPG8SnuIid7Zo2S7YcxdXsU3hq7SfC jofo7hyiaTZw7Me0aORbAHdpVpAE4D33xa8Vn7l7hJRL58o42nKRi+TCNSG9ODJKRWSS YWJw==
MIME-Version: 1.0
X-Received: by with SMTP id n7mr39225841wjx.8.1402389238854; Tue, 10 Jun 2014 01:33:58 -0700 (PDT)
Received: by with HTTP; Tue, 10 Jun 2014 01:33:58 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Tue, 10 Jun 2014 09:33:58 +0100
X-Google-Sender-Auth: xTZ2RX_-ugA5xdVAh95A4dJTuck
Message-ID: <>
From: Kevin Smith <>
To: Ralph Meijer <>
Content-Type: text/plain; charset=UTF-8
Cc: XMPP Working Group <>
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:34:02 -0000

On Tue, Jun 10, 2014 at 9:26 AM, Ralph Meijer <> wrote:
> 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.

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

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

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

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

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.

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

Yes. I think this is worth being explicit about.