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

Curtis King <cking@mumbo.ca> Tue, 10 June 2014 03:44 UTC

Return-Path: <cking@mumbo.ca>
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 5EBA11A0398 for <xmpp@ietfa.amsl.com>; Mon, 9 Jun 2014 20:44:33 -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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 PYVjVozQOA8o for <xmpp@ietfa.amsl.com>; Mon, 9 Jun 2014 20:44:32 -0700 (PDT)
Received: from monet.mumbo.ca (monet.mumbo.ca [204.109.63.66]) by ietfa.amsl.com (Postfix) with ESMTP id D27771A0383 for <xmpp@ietf.org>; Mon, 9 Jun 2014 20:44:31 -0700 (PDT)
Received: from rembrandt.mumbo.ca (unknown [184.66.12.24]) by monet.mumbo.ca (Postfix) with ESMTPSA id 02AB245021; Mon, 9 Jun 2014 20:44:29 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E26DCCB0-EC3E-478B-AF2F-CC232AFE4EC7"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Curtis King <cking@mumbo.ca>
In-Reply-To: <CAKHUCzyoB04UM63afZctwsCTRKCs=WJ_DjSZrS4Vw8w3iqUarg@mail.gmail.com>
Date: Mon, 9 Jun 2014 20:44:27 -0700
Message-Id: <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca>
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>
To: Dave Cridland <dave@cridland.net>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/tDTONLHTk8DgWp4F0xGhUBnD6YE
Cc: XMPP Working Group <xmpp@ietf.org>
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 03:44:33 -0000

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.

cheers,

ck