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 protected]> 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 protected]); [email protected]; >> General >> Area Review Team ([email protected]) >> Cc: Black, David; Barry Leiba ([email protected]); [email protected]; >> [email protected] >> 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 protected] Mobile: +1 (978) 394-7754 >> ---------------------------------------------------- > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
