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

Alexey Melnikov <> Wed, 02 March 2016 14:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FEBE1B2ABF for <>; Wed, 2 Mar 2016 06:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.007
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ePFsJsaBPVzN for <>; Wed, 2 Mar 2016 06:06:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 374E81B2ABE for <>; Wed, 2 Mar 2016 06:06:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1456927561;; s=selector;; 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 [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Wed, 2 Mar 2016 14:06:01 +0000
To: S Moonesamy <>,
References: <>
From: Alexey Melnikov <>
Message-ID: <>
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: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [imapext] Review of draft-ietf-imapapnd-rfc2088bis-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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" 

> 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 
> 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,