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

Ralph Meijer <ralphm@ik.nu> Tue, 10 June 2014 07:19 UTC

Return-Path: <ralphm@ik.nu>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705BB1A0422 for <xmpp@ietfa.amsl.com>; Tue, 10 Jun 2014 00:19:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6S5eR58D8kIh for <xmpp@ietfa.amsl.com>; Tue, 10 Jun 2014 00:19:54 -0700 (PDT)
Received: from mag.ik.nu (mag.ik.nu [83.98.201.61]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7811A1A023C for <xmpp@ietf.org>; Tue, 10 Jun 2014 00:19:54 -0700 (PDT)
Received: from mag.ik.nu (localhost [127.0.0.1]) by mag.ik.nu (Postfix) with ESMTP id BE39DA1065 for <xmpp@ietf.org>; Tue, 10 Jun 2014 09:19:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at ik.nu
Received: from mag.ik.nu ([127.0.0.1]) by mag.ik.nu (mag.ik.nu [127.0.0.1]) (amavisd-new, port 10024) with SMTP id PYsTdvMoxPBI for <xmpp@ietf.org>; Tue, 10 Jun 2014 09:19:51 +0200 (CEST)
Received: from [192.168.3.215] (s53751670.adsl.online.nl [83.117.22.112]) by mag.ik.nu (Postfix) with ESMTPSA id D3322A1047 for <xmpp@ietf.org>; Tue, 10 Jun 2014 09:19:50 +0200 (CEST)
Message-ID: <5396B196.6060309@ik.nu>
Date: Tue, 10 Jun 2014 09:19:50 +0200
From: Ralph Meijer <ralphm@ik.nu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <CAKHUCzwJrykJrOscQowXOKZY1Aq7MA+YRWz=XanDknY+7zq6qg@mail.gmail.com> <B97418EC-47DF-439E-85C2-835761F6D694@andyet.net> <5395DF40.2030509@stpeter.im> <292F40A9-A302-477B-AF26-57B1D3024BEC@mumbo.ca> <CAKHUCzyoB04UM63afZctwsCTRKCs=WJ_DjSZrS4Vw8w3iqUarg@mail.gmail.com> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca>
In-Reply-To: <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/sVaoAbKsFoPKRXuWrcfYC7c8q24
Subject: Re: [xmpp] draft-cridland-xmpp-session-00
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2014 07:19:57 -0000

On 2014-06-10 05:44, Curtis King wrote:
> 
> On Jun 9, 2014, at 9:54 AM, Dave Cridland <dave@cridland.net> wrote:
> 
>> On 9 June 2014 17:36, Curtis King <cking@mumbo.ca> 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).
> 
> 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.

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