Skip to main content

Last Call Review of draft-ietf-imapapnd-rfc2088bis-04
review-ietf-imapapnd-rfc2088bis-04-opsdir-lc-jethanandani-2016-03-23-00

Request Review of draft-ietf-imapapnd-rfc2088bis
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-04-19
Requested 2016-03-11
Authors Alexey Melnikov
I-D last updated 2016-03-23
Completed reviews Genart Last Call review of -04 by Joel M. Halpern
Opsdir Last Call review of -04 by Mahesh Jethanandani
Secdir Last Call review of -04 by Klaas Wierenga
Assignment Reviewer Mahesh Jethanandani
State Completed
Request Last Call review on draft-ietf-imapapnd-rfc2088bis by Ops Directorate Assigned
Reviewed revision 04
Result Ready
Completed 2016-03-23
review-ietf-imapapnd-rfc2088bis-04-opsdir-lc-jethanandani-2016-03-23-00
I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.
 These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed in last
call may be

included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

Document reviewed:

draft-ietf-imapapnd-rfc2088bis-04

Status:

Ready

Summary:

This document specifies an alternate form of literal that does not require a
network round trip of client waiting for the server to send a command
continuation request between sending the octet count and the string data. This
form of literal is called non-synchronizing literal.

The server advertises the capability of supporting non-synchronizing literal in
the CAPABILITY command. By default the server is required to support the
synchronizing literal. As such other than configuring the server to advertise
the particular capability, there is no operational requirement that I could
discern from the document.

The idnits check passed with no errors, flaws, or warnings.

Thanks.

Mahesh Jethanandani

mjethanandani at gmail.com