[imapext] Review of draft-ietf-imapapnd-rfc2088bis-02

S Moonesamy <sm+ietf@elandsys.com> Wed, 02 March 2016 06:40 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 585201A1A43 for <imapext@ietfa.amsl.com>; Tue, 1 Mar 2016 22:40:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.796
X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.006, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rebrKh0WVx8a for <imapext@ietfa.amsl.com>; Tue, 1 Mar 2016 22:40:10 -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 29E711A1A42 for <imapext@ietf.org>; Tue, 1 Mar 2016 22:40:10 -0800 (PST)
Received: from SUBMAN.elandsys.com ([]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u226dvxY005774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2016 22:40:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1456900809; x=1456987209; bh=xT+IEp5hgiQXHNUXGv+iG/kNSiZ8v6gFhSpiiR7r43E=; h=Date:To:From:Subject; b=UCRPLBMco0sZp6k98s0+LEJM3fKBGBFjY5kGd2nfEEAt/JoVJMHinuUL+elTiGrbQ y+NtD391o/cerugtuTzrbCHtRRgsb8QWzD072E+ck6YlQaJipPXp7CUzwzhGTyUPsw s1dGJtK/N6EL+vF5kfdubbV+a5SbjPUOVpkWru4E=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1456900809; x=1456987209; i=@elandsys.com; bh=xT+IEp5hgiQXHNUXGv+iG/kNSiZ8v6gFhSpiiR7r43E=; h=Date:To:From:Subject; b=4QG421VZ6ZJ/SHA+W40SacD6HfqGEobCJL1Q42KOP+QGr/LFy18zKmlNoLJZMPsyt h2clEjm4pKuXjS7bOz2OVGcV2oNvRMpDqDkq7jn91LpTtJTPAplFRqL+D6hEJtFgNp aK9jSfIZ3kb8RWqyFtTgER1lfLk9IAf4nCOgHf1Y=
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 01 Mar 2016 22:38:46 -0800
To: Alexey Melnikov <alexey.melnikov@isode.com>, imapext@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/jfkD2VrWWE14ta3hxqWCFZSUdcA>
Subject: [imapext] Review of draft-ietf-imapapnd-rfc2088bis-02
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: Wed, 02 Mar 2016 06:40:11 -0000

Hi Alexey,

I reviewed draft-ietf-imapapnd-rfc2088bis-02 [1].

In Section 1:

   "The non-synchronizing literal is added an alternate form of literal,
    and may appear in communication from client to server instead of the
    IMAP [RFC3501] form of literal."

I found the sentence unclear (is added an alternate form ...).  The 
second paragraph in the Abstract is clear and I understood what the 
document specifies.

   "The non-synchronizing literal is distinguished from the original
    synchronizing literal by having a plus ('+') between the octet count
    and the closing brace ('}').  The server does not generate a command
    continuation request in response to a non-synchronizing literal, and
    clients are not required to wait before sending the octets of a non-
    synchronizing literal."

The above describes the "non-synchronizing literal".  The previous 
describes the usage of the "non-synchronizing literal".  I suggest 
describing the "non-synchronizing literal" and explain how it may be 
used after that.

In Section 1:

   "The non-synchronizing literal form MUST NOT be sent from server
    to client."

The requirements notation is in Section 2.

There are also the following RFC 2119 key words in Section 1:

   "If it finds this sequence, it is the octet count of a
    non-synchronizing literal and the server MUST treat the
    specified number of following octets and the following
    line as part of the same command.  A server MAY still
    process commands and reject errors on a line-by-line basis,
    as long as it checks for non-synchronizing literals at the
    end of each line."

Shouldn't the RFC 2119 be moved after Section 2?  There is also the 
example at the end of Section 1 which uses "C:" and "S:".

In Section 4:

   '"LITERAL-" extension is almost identical to "LITERAL+"'

I did not find a section for "LITERAL+".  Where is "LITERAL+" specified?

   " When any literal is larger than 4096, RFC 3501 synchronizing
   literals MUST be used instead."

The word "bytes" is missing in the above sentence.

   "It then MAY proceed as described in Section 3."

Why is there is a RFC 2119 "MAY"?

Section 9 is about "To Do".  What is this section about?

The Abstract or the rest of the document does not mention that the 
document will be obsoleting RFC 2088.  The document proposes to 
obsolete RFC 2088.  The IANA
IMAP4 capabilities registry references RFC 2088 for "LITERAL+".

Why is RFC 3502 an informative reference?

S. Moonesamy

1. https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-02