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

Dave Cridland <dave@cridland.net> Tue, 10 June 2014 07:43 UTC

Return-Path: <dave@cridland.net>
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 CF3A21A044D for <xmpp@ietfa.amsl.com>; Tue, 10 Jun 2014 00:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Level:
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 137s_RTvWmUT for <xmpp@ietfa.amsl.com>; Tue, 10 Jun 2014 00:43:41 -0700 (PDT)
Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71E571A0424 for <xmpp@ietf.org>; Tue, 10 Jun 2014 00:43:41 -0700 (PDT)
Received: by mail-ob0-f169.google.com with SMTP id wp18so4528592obc.14 for <xmpp@ietf.org>; Tue, 10 Jun 2014 00:43:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HvmuA9DrXD3oLUOpQvbCMxJ1GRzeiYnmwG7gvQjEhg0=; b=jIZEOmJ4bqzWxKVxW7Y8YPZFnH/h5EExeC/JfWW2c7K9gK6dBRZA9fjsTEiI/lb8Qp 6exiYJsII3EAdqbyNafaA2xFhdy/VsMKmgRCNQufF5ChCssIOYISgIPVyD9qlUO6yvIK nKlsNsNNLn3b9O1M5AmRR4YDOcPKVKf/clqhE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HvmuA9DrXD3oLUOpQvbCMxJ1GRzeiYnmwG7gvQjEhg0=; b=N4kDmGLuus41lJFbG0iS8h90DiNDYxDwRSovydMfbZPwsX5bjEVJn5vHQqueuiOOlM lfMcMcIe/8T/IFZmYwSu9VhQgNjbUGlRSDUlvF4x+ccFRxN/NtwK9VgUYmBOJ1uYVk0a BoAX/ZdZ9xuvtT7Dx4xia9y3FgEgWQUw7H7h0GYuBvEl9nc+x5r2iNpMH+f+2K3PUl1s XdpE9TzRK/g0bwXZ8XPvYXCduINnal+7dzDXmEIB9Ocpw2fEBfcbMb1xDTirbxss62xT ZTshqHAioD2dkS4VGdG7qJPK/UhR4mEimZnQtcaqvXgzpnaJGWvBPnU6LbtJsCnNcnmW KDeA==
X-Gm-Message-State: ALoCoQnLlryjCagznCLUVCuG3WTOA9f6HzmMAQT1whLfd7aJRGAio4Hb/8A+9gOvdoLRgThkftIT
MIME-Version: 1.0
X-Received: by 10.182.125.99 with SMTP id mp3mr29631939obb.40.1402386220861; Tue, 10 Jun 2014 00:43:40 -0700 (PDT)
Received: by 10.60.60.100 with HTTP; Tue, 10 Jun 2014 00:43:40 -0700 (PDT)
In-Reply-To: <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> <557B118B-21BE-43FD-905A-9B725836E66F@mumbo.ca>
Date: Tue, 10 Jun 2014 08:43:40 +0100
Message-ID: <CAKHUCzyamFr6LAk0B+fkdvFg7hoapakNj0bJ9yKPFTd3sET52Q@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: Curtis King <cking@mumbo.ca>
Content-Type: multipart/alternative; boundary=089e0122f628885f0c04fb767c62
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/KaXRb55Xz5VaGqQarGVBWlbmmPc
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 07:43:42 -0000

On 10 June 2014 04:44, Curtis King <cking@mumbo.ca> 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.
>
>
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.


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

I'm just documenting the status quo as deployed.


>
> cheers,
>
> ck
>
>