Telechat Review of draft-ietf-qresync-rfc5162bis-10
review-ietf-qresync-rfc5162bis-10-genart-telechat-black-2014-02-17-00

The -10 version of this draft addresses all of the items noted in the
Gen-ART review of the -09 version.  It's ready for publication.

Thanks,
--David

> -----Original Message-----
> From: Black, David
> Sent: Sunday, January 26, 2014 9:07 PM
> To: Alexey Melnikov (alexey.melnikov at isode.com); dcridland at arcode.com; General
> Area Review Team (gen-art at ietf.org)
> Cc: Black, David; Barry Leiba (barryleiba at computer.org); imapext at ietf.org;
> ietf at ietf.org
> Subject: Gen-ART review of draft-ietf-qresync-rfc5162bis-09
> 
> 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
> ----------------------------------------------------