This is an Early Review, no IETF LC issued yet.

I have been selected as the Applications Area Directorate reviewer for
this draft (for background on appsdir, please see
​http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-qresync-rfc5162bis-03.txt
Title: IMAP Extensions for Conditional STORE Operation or Quick Flag
        Changes Resynchronization (CONDSTORE) and Quick Mailbox
        Resynchronization (QRESYNC)
Reviewer: Claudio Allocchio
Review Date: Nov 19th 2013
IETF Last Call Date: N/A
IESG Telechat Date: N/A

Summary: This draft is almost ready for publication as an Informational
RFC. It describes in details (maybe even in too much detail in the 
Introduction and Overview, but I do not see this as a problem) the 
extensions and possible scenarios. Just some minor issues to check.

Major issues:

none.

Minor issues:

Abstract:

- When you state "They must be able to guarantee that only one client can 
change message state (e.g., message flags) at any time." IMHO there is 
chance that one implementer might undestand that only one client at a time 
shall be granted permission to change message state/flags al ALL messages 
in the mailbox, while we just mean "message flags/state of the specific 
message you are looking at". Maybe a text like:

"They must be able to guarantee that only one client can change message 
state (e.g., message flags of the specific message being looked up) at any 
time."

1. Introduction and overview

- In general, this is more a "condensed summary" of the specification than 
an introduction or overview. Maybe a different title... I shall say that 
it is quite unusual to have such a precise summary of the specification 
(with references to following section) at the beginning of a 
specification. Nothing wrong, but again it make me thing the title of this 
section is wrong.

- When you talk about QRESYNC, saying that on a mobile client it can 
"reduce the expense" maybe is not appropriate for a technical 
specification (and many people run on flat-rate data plans...)

- "Since CONDSTORE is a relatively new extension, it is thought likely 
that clients that support it will also support QRESYNC." why not turn 
this into a reccomendation? Or add a reccomendation that both should be 
supported?

3.1.1

I suggest "One of these two response codes MUST be returned"

3.1.2

Note after Example 8.

" Note: A client trying to make an atomic change to the state of a
    particular metadata item (or a set of metadata items) should be
    prepared to deal with the case when the server returns the MODIFIED"

... it's inside a "note:" ... however I have some doubts that "should" 
needs to be an uppercase normative SHOULD.

Same (minor!) issue also later after Example 10 for the "may":

"The following example is based on the example from the Section 4.2.3
    of [RFC2180] and demonstrates that the MODIFIED response code may be
    also returned in the tagged NO response."

... again, after Example 11:

"the server must not fail the operation for message 7 as part of
    processing "3:9" if it succeeded when message 7 was processed the
    first time." (MUST NOT?)

3.1.4

again as above:

"  The last means that the server should use
       the biggest value among "priv" and "shared" mod-sequences"

(SHOULD?)

3.1.10

" Server implementations should follow the following rule," (SHOULD?)

6.

again: " An advanced disconnected mail client should use the QRESYNC"
(SHOULD?)

NOTE: All the above refers to client/serve actions, that's why I've the 
feeling we shall use normative uppercase.


Nits:

none.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca