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

From: S Moonesamy <[email-masked]>
Date: Tue, 01 Mar 2016 22:38:46 -0800

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?

Regards,
S. Moonesamy

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 2 Mar 2016 14:05:59 +0000

Hi SM,
Thank you for your comments.

On 02/03/2016 06:38, S Moonesamy wrote:
> 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.
>
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.

> I did not find a section for "LITERAL+".  Where is "LITERAL+" specified?
In the "Specification" section.
> The word "bytes" is missing in the above sentence.
This was rewritten based on feedback from Jamie.

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

> obsolete RFC 2088.
I added a sentence on this.

> The IANA
I added a short sentence on that.

Best Regards,
Alexey

---

From: S Moonesamy <[email-masked]>
Date: Wed, 02 Mar 2016 07:25:22 -0800

Hi Alexey,
At 06:05 02-03-2016, Alexey Melnikov wrote:
>"Requirements Notation" section after it, before the "Specification" section.

draft-ietf-imapapnd-rfc2088bis-03 is a significant improvement over -02.

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

What I meant was that you could use a "may" (It may then proceed ...).

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 2 Mar 2016 15:29:17 +0000

Hi SM,

> At 06:05 02-03-2016, Alexey Melnikov wrote:
  [snip]
>> (as per section 3), or do something else. I would be Ok with changing 
>> MAY to SHOULD.
>

IMHO, it is an implementation choice, so use of MAY is appropriate.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 02 Mar 2016 07:37:47 -0800

Hi Alexey,
>IMHO, it is an implementation choice, so use of MAY is appropriate.

I am okay with that.

Regards,
S. Moonesamy