Re: [imapext] AD review draft-ietf-imapapnd-appendlimit-extension-06

Dave Cridland <dave@cridland.net> Fri, 18 December 2015 10:55 UTC

Return-Path: <dave@cridland.net>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20061A882F for <imapext@ietfa.amsl.com>; Fri, 18 Dec 2015 02:55:31 -0800 (PST)
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 XZRy6eZ2JuxV for <imapext@ietfa.amsl.com>; Fri, 18 Dec 2015 02:55:30 -0800 (PST)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 891811A87EE for <imapext@ietf.org>; Fri, 18 Dec 2015 02:55:30 -0800 (PST)
Received: by mail-ob0-x22a.google.com with SMTP id 18so77287051obc.2 for <imapext@ietf.org>; Fri, 18 Dec 2015 02:55:30 -0800 (PST)
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=BWbqCFVZeRwIEyDSabZ+8HrAt2zUzQ5iijX1c3v+H8o=; b=D/PpMOVEyjk7t5WXrFTcCvbJ+u6m5w0ntnqb8xk3kZeHS0fDjHSwaMjWSVhCEOEWKi VCNF+cpIpdeHYKTfWL+d8ziELjHY7bryOOu0oZG9YJN8b/mep3bD/45+rHtougX780A2 kAyMwkoiCn97HiZa4UXxwFg0kTr885kjUlL+s=
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=BWbqCFVZeRwIEyDSabZ+8HrAt2zUzQ5iijX1c3v+H8o=; b=W8YOn8OJAYHiU+foos1eK+Uq/HnptEUSN2xq+Igj0/bdWCLPcIE0+zGFV5/AMJ0Q8x 3BAJlIaG5OHlXD99EZboM9NNEUphZZUWYNPzQh7YVb1/zQ3QlcgZ/N/8ZHLtU8x7C+Sm fVXTQQ7Z281fWBKkrzMBPdfoC2BNEz48b/Z2hH9TpBKi+6MkfARqRO3fdHgzR2P9BdDX GtUi1DKW5oClQtJYqUI3ofwZY9UzETi0OleJeE5Kc6PN/z+12KcpMbgJ16EhnINu+/9c WHDu8xgqg6FxqgP+xW7YhSdZE0+pcNrcm4zyj/bUOw6nONcEdTV4ujAB3Qnq2LmzSHDt fl4Q==
X-Gm-Message-State: ALoCoQlIKOFhl1qdGuF26+6G/1ns1DSKZzMcDeGg8bFgCq8z6u544cgiGxTYWaFLsydf2ypdQrtIczRnp92l/BWQXOMAw+CM4Gp/8SKqUdZRxo+AfvgbWQc=
MIME-Version: 1.0
X-Received: by 10.60.34.69 with SMTP id x5mr1302366oei.35.1450436129927; Fri, 18 Dec 2015 02:55:29 -0800 (PST)
Received: by 10.60.6.134 with HTTP; Fri, 18 Dec 2015 02:55:29 -0800 (PST)
In-Reply-To: <6.2.5.6.2.20151217130638.0d436848@resistor.net>
References: <emcf7f771e-a84b-4df3-b9ff-06dd5417a655@bodybag> <5A5084CC-6733-45DB-B3D5-4F73285257D0@isode.com> <6679218db47f443794b1ce28452623eb@SEAMBX07.sea.samsung.com> <5672EEDE.5060101@isode.com> <5672F2BE.8060404@teamaol.com> <6.2.5.6.2.20151217130638.0d436848@resistor.net>
Date: Fri, 18 Dec 2015 10:55:29 +0000
Message-ID: <CAKHUCzwVkC23NEoH9ou2DScdwE=PCYXXonfyW2fbovJHsucEDQ@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
To: S Moonesamy <sm+ietf@elandsys.com>
Content-Type: multipart/alternative; boundary="089e012953004b4d40052729fa5d"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/xDVPVz1HKLItrY_GxTV3LCrUOBM>
Cc: Stu Brandt <stuart.brandt@teamaol.com>, Narendra Bisht <ns.bisht@sea.samsung.com>, "imapext@ietf.org" <imapext@ietf.org>, Jayantheesh S B <j.sb@sea.samsung.com>
Subject: Re: [imapext] AD review draft-ietf-imapapnd-appendlimit-extension-06
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Dec 2015 10:55:31 -0000

On 17 December 2015 at 21:19, S Moonesamy <sm+ietf@elandsys.com> wrote:

> Hi Stu,
> At 09:37 17-12-2015, Stu Brandt wrote:
>
>> Since RFC 3501 section 4.5 states...
>>
>>    The special form "NIL" represents the non-existence of a particular
>>    data item that is represented as a string or parenthesized list, as
>>    distinct from the empty string "" or the empty parenthesized list ().
>>
>>
>> ...does the introduction of nil as an alternative to number now imply
>> that an update to this text is necessary?
>>
>
> Thanks for flagging this.
>
> I don't think so as it is ABNF in
> draft-ietf-imapapnd-appendlimit-extension which will be followed.  The
> following persons are in favor of using "NIL" [1][2][3][4]:
>
>   Barry Leiba (Area Director)
>   Bron Gondwana
>   Adrien de Croy
>   Alexey Melnikov
>
> I suggest going ahead with that.
>

I'm in favour too, but I'm also in favour of using it in the CAPABILITY
string as well. My reasonings:

1) I'd rather minimize the syntactic differences.

2) If a server advertises an appendlimit prior to authentication but wishes
to indicate no limit subsequent, there is currently no method for doing so.
I have no clue why a server would wish to do this, but the specification
seems adamant that changing the limit after login (rather than not
advertising it prior) is useful.

Dave.