[imapext] Referencing RFC 2088 (was: AD review of draft-ietf-imapapnd-appendlimit-extension-06)

S Moonesamy <sm+ietf@elandsys.com> Tue, 08 December 2015 15:07 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 38F371B2EE6; Tue, 8 Dec 2015 07:07:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 t8wgdP__1yqs; Tue, 8 Dec 2015 07:07:28 -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 C041F1B2EE2; Tue, 8 Dec 2015 07:07:22 -0800 (PST)
Received: from SUBMAN.elandsys.com ([197.226.210.246]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id tB8F6wPv005469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Dec 2015 07:07:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1449587234; x=1449673634; bh=emonHSL/ZdqX/OcNLuMEVmwkrLTDxmoG+cUst+A9OJc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=QwOTnv8azohG7fNOqtHXXLgOlPXc1eVizJPi8+nCTcxtIruo8D5qnxZ5oLBeS7wfV TYEIEUqtlWimAJERi/5F/O8u40lZ5g6xPFu06my9WJytjL/F/YW+qHCg8aIyyJvPfX VtDRSwikWmadEDkMhUQfxcWNyFCDLfbLcsum+ZXQ=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1449587234; x=1449673634; i=@elandsys.com; bh=emonHSL/ZdqX/OcNLuMEVmwkrLTDxmoG+cUst+A9OJc=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=MDLij9eThPHox3qBsQk9uOEjvuooR+m/kUVAuoUsS2yJa1N8I9ogLXv7on+vIlDz1 sl3Wa+O5FZ5CR24q/pe5Dry6yeZp5n7hN305O9C0qd+/GO1nQEShUyHDaSEmIjXONY bRXjx08IMf1iPZHtKeAkZF+0Bv0zwuhbJFzEHeNc=
Message-Id: <6.2.5.6.2.20151208064825.0cbfd5f8@resistor.net>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 08 Dec 2015 07:05:57 -0800
To: imapext@ietf.org, Jayantheesh S B <j.sb@sea.samsung.com>, Narendra Bisht <ns.bisht@sea.samsung.com>, Alexey Melnikov <alexey.melnikov@isode.com>
From: S Moonesamy <sm+ietf@elandsys.com>
In-Reply-To: <CALaySJLE_6+vbeB-SeMk1VHDAtq2VvS9yKe9dhQ2LTzr4y=oTg@mail.g mail.com>
References: <CALaySJLE_6+vbeB-SeMk1VHDAtq2VvS9yKe9dhQ2LTzr4y=oTg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/aWPIFsVCLGhps61kncy6-JWvslM>
Cc: draft-ietf-imapapnd-appendlimit-extension@ietf.org, Barry Leiba <barryleiba@computer.org>, imapext@ietf.org
Subject: [imapext] Referencing RFC 2088 (was: AD review of 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: Tue, 08 Dec 2015 15:07:30 -0000

Hi Jay, Naren, Alexey,

Although I did not mention all the working group participants by 
name, please comment if you have an opinion about this.

At 10:24 07-12-2015, Barry Leiba wrote:
>-- Section 4 --
>
>"Client can avoid use of LITERAL+ [RFC2088], when maximum upload size
>  supported by the IMAP server is unknown."
>
>What?
>Don't you mean "The client SHOULD avoid"?  I'd even use this as an
>opportunity to make it firmer, and say "The client MUST avoid".  No?
>If not, why not?
>
>And please don't say "LITERAL+"; please say "non-synchronizing
>literals".  (We should use capability strings only when we're talking
>about what's in the CAPABILITY response.)

draft-ietf-imapapnd-appendlimit-extension-06 references RFC 
2088.  Alexey is editing the second draft of the Working Group.  That 
draft proposes to replace RFC 2088 and obsolete it in a few months 
(if there is agreement to do that).

The alternatives are:

   (a) Keep the reference to RFC 2088

   (b) Change the reference to draft-ietf-imapapnd-rfc2088bis

If draft-ietf-imapapnd-rfc2088bis does not become an RFC, the 
reference can be changed back to RFC 2088.  The impact on 
draft-ietf-imapapnd-appendlimit-extension is that its publication as 
a RFC will be delayed until draft-ietf-imapapnd-rfc2088bis is 
published as a RFC.

Which alternative do you prefer?

Regards,
S. Moonesamy (as document shepherd)