Re: [xmpp] <optional> and <required/>

Waqas Hussain <waqas20@gmail.com> Sun, 13 March 2011 18:53 UTC

Return-Path: <waqas20@gmail.com>
X-Original-To: xmpp@core3.amsl.com
Delivered-To: xmpp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5902B3A6B5A for <xmpp@core3.amsl.com>; Sun, 13 Mar 2011 11:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level:
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1+N2YOC5Uir for <xmpp@core3.amsl.com>; Sun, 13 Mar 2011 11:53:21 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 4B50A3A6B32 for <xmpp@ietf.org>; Sun, 13 Mar 2011 11:53:21 -0700 (PDT)
Received: by yic13 with SMTP id 13so2333649yic.31 for <xmpp@ietf.org>; Sun, 13 Mar 2011 11:54:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=QFDrgaoz++tfvR55HydvCyq3cMW+sQ/07TOD+/Bm2xc=; b=HJSRHeGejFyj5dUIfQxwQRPnQ1jpjfYaGhqLu58mbV9K2FoHomBK8l9TWaVN6uHElP jzD0tkHXQ4shXtpyYRFJ+f8hSyYanO9VsgJOCmcruvltRYucMfy3Zx4JVnikKjuqpBro ZHZKFbxg980fy84cjCeeWvoZ4NUEsykaR0c1s=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=UjCCifGuiZkWCgTu2RETr1/Eyw8Jaaa24mcnmijsYg6UsI4mXyARgt0GH6NJHWsxGf hS1QMxWEbk3l5gJh71tfQNQHz6LubS2ZfzRoFGPyOcG57+qeyR6hAzVrBpDp+Fro2Qag twH1AKPgDCBJnQ2ZOBHK/8qgMpR8OvifbQEbM=
Received: by 10.151.117.5 with SMTP id u5mr751931ybm.135.1300042482116; Sun, 13 Mar 2011 11:54:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.151.106.7 with HTTP; Sun, 13 Mar 2011 11:54:22 -0700 (PDT)
In-Reply-To: <4D76EE02.2010807@stpeter.im>
References: <1299638843.18776.76.camel@spinachia> <4D76EE02.2010807@stpeter.im>
From: Waqas Hussain <waqas20@gmail.com>
Date: Sun, 13 Mar 2011 23:54:22 +0500
Message-ID: <AANLkTi=S7v4UjH+LVxUT_LaBR_20Jocye=pve41mS+UF@mail.gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: xmpp@ietf.org
Subject: Re: [xmpp] <optional> and <required/>
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Sun, 13 Mar 2011 18:53:22 -0000

On Wed, Mar 9, 2011 at 8:03 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> On 3/8/11 7:47 PM, Kim Alvefur wrote:
>> Hi!
>>
>> Just to point out that these sections[1][2] seems to conflict with this
>> tread[3]. Otherwise, how does it make sense for roster versioning to be
>> required?
>>
>> [1]: http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-22#section-4.9.3.23
>> [2]: http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-20#section-2.6.1
>> [3]: http://www.ietf.org/mail-archive/web/xmpp/current/msg01125.html
>
> There are two different topics here:
>
> 1. Whether any given feature is mandatory-to-negotiate or
> voluntary-to-negotiate.
>
> 2. Whether to define a generalized mechanism for such signalling, which
> would apply to all features.
>
> The mailing list post you've cited applies to #2. Section 2.6.1 of
> 3921bis applies to #1.
>
> I see your point about the <unsupported-feature/> stream error: it might
> not make much sense to define such an error condition if there is no
> generalized mechanism for signalling that any given feature is
> mandatory-to-negotiate...
>
> Peter
>

I think the <optional/> in 3921bis should go.

3921bis defines two stream features. Both are optional. One wants
<optional/> inside, the other doesn't. I think this <optional/> is a
leftover from when we tried having a generalized mechanism for
required features, and the only purpose it serves in this instance is
to add redundant inconsistency.

--
Waqas Hussain