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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 02 March 2016 14:06 UTC

Return-Path: <alexey.melnikov@isode.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 7FEBE1B2ABF for <imapext@ietfa.amsl.com>; Wed, 2 Mar 2016 06:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
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 ePFsJsaBPVzN for <imapext@ietfa.amsl.com>; Wed, 2 Mar 2016 06:06:02 -0800 (PST)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 374E81B2ABE for <imapext@ietf.org>; Wed, 2 Mar 2016 06:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1456927561; d=isode.com; s=selector; i=@isode.com; bh=B8tXnGGK2P1UwYMhT6iYBTeBHlFydA8eHh08ck+y4DE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ppCncQ5KyXLWJ40hSIQXN/v5HBETOjJq92hJyaQGePdiQi+D9C8W3V3uo4m3HdhY5ab4Lm 9XwOEgiUxu9FoIThTOWX7vb12mAgx00TopJUTI57IYW/SpsttJb2JM3BCe3YRDBzx+a3Nu UjsUy8XIFDg8qHkz0PYP+yyf73wR6Fk=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <VtbzSABBeA-j@statler.isode.com>; Wed, 2 Mar 2016 14:06:01 +0000
To: S Moonesamy <sm+ietf@elandsys.com>, imapext@ietf.org
References: <6.2.5.6.2.20160301215244.0d624dc0@elandnews.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <56D6F347.6010007@isode.com>
Date: Wed, 02 Mar 2016 14:05:59 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <6.2.5.6.2.20160301215244.0d624dc0@elandnews.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/B_1rLtHRV11y40O33SiLXl-HCFk>
Subject: Re: [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 14:06:08 -0000

Hi SM,
Thank you for your comments.

On 02/03/2016 06:38, S Moonesamy wrote:
> 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 ...).
As Jamie pointed out, "as" was missing before "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:".
I addressed all of the above by adding a short Introduction section 
(which is almost identical to the Abstract). Then I moved the 
"Requirements Notation" section after it, before the "Specification" 
section.

> In Section 4:
>
>   '"LITERAL-" extension is almost identical to "LITERAL+"'
>
> I did not find a section for "LITERAL+".  Where is "LITERAL+" specified?
In the "Specification" section.
>
>   " When any literal is larger than 4096, RFC 3501 synchronizing
>   literals MUST be used instead."
>
> The word "bytes" is missing in the above sentence.
This was rewritten based on feedback from Jamie.

>   "It then MAY proceed as described in Section 3."
>
> Why is there is a RFC 2119 "MAY"?
Because an implementation can eat the literal or send BYE response (as 
per section 3), or do something else. I would be Ok with changing MAY to 
SHOULD.
> Section 9 is about "To Do".  What is this section about?
Yes, Jay already spotted that, so this was deleted in my copy.

> 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.
I added a sentence on this.

> The IANA
> IMAP4 capabilities registry references RFC 2088 for "LITERAL+".
>
> Why is RFC 3502 an informative reference?
I added a short sentence on that.

Best Regards,
Alexey