Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 (Section 2)

S Moonesamy <sm+ietf@elandsys.com> Thu, 10 December 2015 06:55 UTC

Return-Path: <sm@elandsys.com>
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 EF4BC1B31DD; Wed, 9 Dec 2015 22:55:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.8
X-Spam-Level:
X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 AKwCdY84Mx67; Wed, 9 Dec 2015 22:55:17 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 606941B31DF; Wed, 9 Dec 2015 22:55:08 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.226.210.92]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id tBA6snM1005108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Dec 2015 22:54:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1449730502; x=1449816902; bh=JXrLW+vxCJfUUh04y8yMuWgBE/xg+ojFHSXLUiLB+Pg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=r8QDUol/ClZSPADTGK3+VNPNd868AtKXbwvU365My0NyCdJM2JAzgzGpARhFPcGkC dQLjlSnUp01OXjDDguHx5OmkmD4pKFteG98uK4N7OirukoCDMdxP7OEXK+O9rogz9j jcjy9+DQn2F9oc26uaTLKvXf8ZssUJiIDRg307H0=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1449730502; x=1449816902; i=@elandsys.com; bh=JXrLW+vxCJfUUh04y8yMuWgBE/xg+ojFHSXLUiLB+Pg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=oOz0keAJkfwRjTSGMGX6u29F1qZNkxVB7JMZ64kPfAIwowVLBOeI6frET5UkL/gKi Mg02P3vhePg9BzdM46D8RWnuqxXh2HOCXYianrSAmw3wCtmL43/EYA81Hm9l5a8G/U 8vqcvzGU84cXpXQ3rFlzISNUBJogqVYzK9jMELfM=
Message-Id: <6.2.5.6.2.20151209223348.0d1a66e0@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Wed, 09 Dec 2015 22:54:23 -0800
To: Narendra Bisht <ns.bisht@sta.samsung.com>, draft-ietf-imapapnd-appendlimit-extension@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <DEA84B8F15992B4EA87D5CF3D0EC5F98AE4FCFD8@DRTW-EXMB04.telec om.sna.samsung.com>
References: <CALaySJLE_6+vbeB-SeMk1VHDAtq2VvS9yKe9dhQ2LTzr4y=oTg@mail.gmail.com> <DEA84B8F15992B4EA87D5CF3D0EC5F98AE4FCFD8@DRTW-EXMB04.telecom.sna.samsung.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/_XHbhGA_ExHcQceClzX55zHMrX8>
Cc: Barry Leiba <barryleiba@computer.org>, imapext@ietf.org
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 (Section 2)
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: Thu, 10 Dec 2015 06:55:18 -0000

Hi Naren,
At 08:52 09-12-2015, Narendra Bisht wrote:
>-- Section 2 --
>
>"An IMAP server that supports APPENDLIMIT extension advertises this 
>by  including the name APPENDLIMIT in its capability list. IMAP 
>server  MAY advertise this capability after user has logged in."
>
>This says nothing about whether the server is allowed to advertise 
>the capability before the user has logged in.  I also don't think 
>this is an appropriate use of 2119 "MAY".  If you mean, "The IMAP 
>server MUST NOT advertise this capability until after the user has logged in,"
>then you should say it that way.  (And if that's not what you mean, 
>please discuss it with me and clarify.)
>
>[Naren] We purposefully marked it as a MAY, because it alerts 
>implementations to the possibility, but doesn't have any effect in 
>interoperability.
>What we mean here is client should be ready to handle this no matter 
>when the capability is sent.

Barry highlighted that the MAY can be interpreted in two ways:

   1. The IMAP server must not advertise this capability until after the user
      has logged in.

   2. The IMAP server may advertise this capability after the user 
has logged in.

Your explanation could be read as meaning that:

   (a) The IMAP server can advertise this capability before the user 
has logged in.

   (b) The IMAP server can advertise this capability after the user 
has logged in.

Does the second sentence in the first paragraph of Section 2 mean (a) and (b)?

Regards,
S. Moonesamy (as document shepherd)