Re: [imapext] WGLC for draft-ietf-imapapnd-rfc2088bis-02

The content looks good. I assembled some grammatical nits.

Throughout the document:

   - "non synchronizing" -> "non-synchronizing". I think the hyphen is more
   grammatically correct and is used in RFC 2088.
   - "that" vs "which" (https://www.google.com/search?q=which+that).
   Specific issues called out below.

Abstract:

   - "...alternate form of literal *which* does not require..." ->
   "...alternate form of literal *that* does not require..."
   - "...in all IMAP command." -> "...in all IMAP command*s*."
   - "...but disallow the alternate..." -> "...but disallow*s* the
   alternate"
   - consider just writing "LITERAL+" and "LITERAL-" instead of "the
   former" and "the latter"

Section 1:

   - "The non-synchronizing literal is added an alternate form of
   literal..." This sentence doesn't quite parse. Should it read,
   "The non-synchronizing literal is added *as* an alternate form of
   literal..." or "The non-synchronizing literal is an alternate form of
   literal..."?
   - "...any IMAP server implementation *which* returns..." -> "...any IMAP
   server implementation *that* returns..."

Section 3:

   - "difficilt" -> "difficult"
   - "...used by a client *which* is too big..." -> "...used by a client
   *that* is too big..."
   - "When a non synchronizing literal is used by a client which is too big
   for the server to accept..." -> "When a client uses a non-synchronizing
   literal that is too big for the server to accept..."
   - "non optimal -> "non-optimal"
   - "...if the literal size is big." could be more concisely written
   "...if the literal is large."
   - "Send *the* untagged BYE response..." -> "Send *an* untagged BYE
   response..."
   - "Some server implementations impose limits on literal..." -> "Some
   server implementations impose limits on literal*s*..."
   - "...in order *to protect from* Denial Of Service attacks..." -> "...in
   order *to protect themselves from* Denial Of Service attacks..." or
   better "...in order* to defend against* Denial Of Service attacks..."
   You could also get rid of "in order".

Section 4:

   - ""LITERAL-" extension is almost..." -> "*The* "LITERAL-" extension is
   almost..."
   - "When any literal is larger than 4096, RFC 3501 synchronizing literals
   MUST be used instead." How about, "Any literal larger than 4096 bytes MUST
   be sent as an RFC 3501 synchronizing literal."
   - "A "LITERAL-" compliant server *which* encounters a *non synchronizing*
   literal in APPEND larger than 4096 bytes MUST reject such APPEND command
   with a tagged BAD response that contains TOOBIG response code [RFC4469]."
   -> "A "LITERAL-" compliant server *that* encounters a *non-synchronizing*
   literal in APPEND larger than 4096 bytes MUST reject such APPEND command
   with a tagged BAD response that contains *the* TOOBIG response code
   [RFC4469]."

Section 7:

   - "...creation of "LITERAL-" extension..." -> "...creation of *the*
   "LITERAL-" extension..."

On Thu, Feb 25, 2016 at 8:32 AM, Jayantheesh S B <j.sb@sea.samsung.com>
wrote:

> All,
>
> Kindly share your review comments for this draft (This Working Group Last
> Call will end on Saturday 20th February)
>
> Regards,
> Jay
> -----Original Message-----
> From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of S Moonesamy
> Sent: Friday, February 05, 2016 3:17 PM
> To: imapext@ietf.org
> Subject: [imapext] WGLC for draft-ietf-imapapnd-rfc2088bis-02
>
> Hello,
>
> This message starts a Working Group Last Call for "IMAP4 non-synchronizing
> literals" (draft-ietf-imapapnd-rfc2088bis-02).  The I-D can be accessed at
> https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-02
>
> This Working Group Last Call will end on Saturday 20th February.  Please
> review the I-D and send comments to the imapext@ietf.org mailing list.
>
> Regards,
> S. Moonesamy (as imapapdb WG Chair)
>
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext
>
> _______________________________________________
> imapext mailing list
> imapext@ietf.org
> https://www.ietf.org/mailman/listinfo/imapext
>