Subject: Re: [Gen-art] Gen-ART review of draft-ietf-qresync-rfc5162bis-10

From: Jari Arkko <[email-masked]>
Date: Thu, 20 Feb 2014 00:00:48 +0100

David, thank you for the review. Alexey et al, thank you for the revisions.

Jari

On Jan 30, 2014, at 9:24 PM, "Black, David" <[email-masked]> wrote:

> 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 ([email-masked]); [email-masked]; General
>> Area Review Team ([email-masked])
>> Cc: Black, David; Barry Leiba ([email-masked]); [email-masked];
>> [email-masked]
>> 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
>> [email-masked]        Mobile: +1 (978) 394-7754
>> ----------------------------------------------------
>