Re: Review of draft-ietf-imapapnd-rfc2088bis-02

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

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext