Subject: [apps-discuss] APPSDIR Early review of draft-ietf-qresync-rfc5162bis-03

From: Claudio Allocchio <[email-masked]>
Date: Fri, 22 Nov 2013 16:37:23 +0100 (CET)

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          [email-masked]
                         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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 25 Nov 2013 19:02:37 +0000

Hi Claudio,
Thank you for your review. My replies are below.

On 22/11/2013 15:37, Claudio Allocchio wrote:
> ​ 
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate 
> ).
>
> - 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."
Ok, changed.

> - 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.
Yes, this is somewhat related to Eliot's comments. I don't think this is 
a problem per se, but some restructuring might be in order.

> specification (and many people run on flat-rate data plans...)

It is still translates to cost of traffic in many environments, but the 
comment wasn't really adding much to the document, so I deleted it.

> this into a reccomendation? Or add a reccomendation that both should 
> be supported?
I think client implementors who look at this document would support both 
for the reason stated. But clients also need to be able to cope with 
servers that only support CONDSTORE (which is more widespread). So I can 
make it a recommendation, but it can't be normative.

> I suggest "One of these two response codes MUST be returned"
Done.
> needs to be an uppercase normative SHOULD.
I am not sure that normative language is needed here, but I think MUST 
is actually more appropriate.

> also returned in the tagged NO response."
Ok.
> processing "3:9" if it succeeded when message 7 was processed the
As this is an example, I would rather keep it non normative.
> the biggest value among "priv" and "shared" mod-sequences"
I think this is a MUST.

> " Server implementations should follow the following rule," (SHOULD?)
Actually, the text that follows already uses SHOULD NOT, so adding 
SHOULD here would not add clarity.

> again: " An advanced disconnected mail client should use the QRESYNC"
Changed.
> NOTE: All the above refers to client/serve actions, that's why I've 
> the feeling we shall use normative uppercase.
>
>
> Nits:
>
> none.

---

From: Claudio Allocchio <[email-masked]>
Date: Tue, 26 Nov 2013 11:00:39 +0100 (CET)

Thanks Alexey! all fine for me now!

On Mon, 25 Nov 2013, Alexey Melnikov wrote:

>> 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.
> Yes, this is somewhat related to Eliot's comments. I don't think this is a 
> problem per se, but some restructuring might be in order.
>
>> "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?
> I think client implementors who look at this document would support both for 
> the reason stated. But clients also need to be able to cope with servers that 
> only support CONDSTORE (which is more widespread). So I can make it a 
> recommendation, but it can't be normative.
>
>> 3.1.1
>> 
> I am not sure that normative language is needed here, but I think MUST is 
> actually more appropriate.
>
> Actually, the text that follows already uses SHOULD NOT, so adding SHOULD 
> here would not add clarity.
>
>> 6.
>>