Last Call Review of draft-ietf-qresync-rfc5162bis-09
review-ietf-qresync-rfc5162bis-09-genart-lc-black-2014-01-27-00

Request Review of draft-ietf-qresync-rfc5162bis
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-01-27
Requested 2014-01-16
Draft last updated 2014-01-27
Completed reviews Genart Last Call review of -09 by David Black (diff)
Genart Telechat review of -10 by David Black
Secdir Last Call review of -09 by Phillip Hallam-Baker (diff)
Assignment Reviewer David Black
State Completed
Review review-ietf-qresync-rfc5162bis-09-genart-lc-black-2014-01-27
Reviewed rev. 09 (document currently at 10)
Review result Ready with Issues
Review completed: 2014-01-27

Review
review-ietf-qresync-rfc5162bis-09-genart-lc-black-2014-01-27

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<

http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-qresync-rfc5162bis-09
Reviewer: David L. Black
Review Date: January 26, 2014
IETF LC End Date: January 27, 2014

Summary:
This draft is basically ready for publication, but has minor issues that
should be fixed before publication.

This draft consolidates RFC 4551 (IMAP Conditional STORE) and RFC 5162
(IMAP Quick Mailbox Resynchronization) into a single document and makes
a few minor updates.  It also updates the command line length
recommendation in RFC 2683 to support the longer command lines that
can occur with these extensions.

As this is an update, I checked the diffs against RFC 4551 and RFC 5162;
they look reasonable.  I found one minor issue that should be relatively
easy to address.

Minor Issues:

The command line length change in Section 4 applies to all IMAP commands,
and hence affects old servers, including those that don't implement either
of the extensions in this draft. That raises a backwards compatibility
concern - what happens when a new client sends a > 1000 character command
line to an old server that isn't expecting more than 1000 characters?

One possibility would be to apply the larger length recommendation only
after the client determines that the server supports at least one of
these extensions.

Nits/editorial comments:

The update to RFC 2683 would be easier to find from the table of contents
if the title of Section 4 were changed to "Long Command Lines (Update to
RFC 2683)".

idnits 2.13.01 got confused by the command line examples, and flagged a
downref:

  ** Downref: Normative reference to an Informational RFC: RFC 2683

That downref appears to be ok and intended, as noted in the shepherd's
writeup.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------