Subject: [Gen-art] Gen-art review of draft-melnikov-imap-expunged-01.txt

From: Elwyn Davies <[email-masked]>
Date: Fri, 22 Sep 2006 09:32:21 +0100

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these (slightly belated - sorry) comments along with any 
other Last Call comments you may receive.

Summary
=======
If the open issue noted in s3.1 is resolved by maintaining the current 
proposal (REPORTEXPUNGED not allowed with FETCH command) then this 
document is almost ready to go as proposed standard, modulo the 
discussions in the imapext wg. If the decision goes the other way 
significant extra text will be needed to explain the semantics of the 
additional usage.  There are a few editorial nits to fix (especially the 
apparent espousal of magic in the abstract and s2).

Issues
======
s3.1: There is an open issue here: Whether the modifier is allowed with 
the FETCH command as well as the UID FETCH command.  This needs to be 
resolved before the doc goes to the IESG.  [Meta-issue: having different 
semantics for the same extension on UID FETCH and FETCH might be confusing.]

Editorial
=========
Abstract: 'gives a disconnected client ability to quickly learn about 
expunged messages'
I always said the Internet worked by magic :-) ... maybe 'gives a client 
that has been disconnected for a period the ability, on reconnection, ...'

s2/s4-para 2: Same point as for the abstract.  Might also help to modify 
'allows a client' to 'allows a reconnecting client' in s2.

s2: 'flag changes' is potentially ambiguous - it can also mean to 
provide notification.  I think 'synchronize changes in flag values 
relating to previously seen messages'.

s3.1, para 2: s/The REPORTEXPUNGES FETCH modifier/The REPORTEXPUNGES UID 
FETCH modifier/ - or some other way to make it clear that immediately 
that this is the semantics for UID FETCH only.

s3.1, para 4: s/flag changes/flag value changes/

s3.2, first example display: s/\Deleted messaged/\Deleted messages/?

s3.2, para before last example display: s/can look like/might look like/

s4, para 3: s/NOMODSEQ/a NOMODSEQ/, s/more general instructions/the more 
general instructions/

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Sep 2006 13:41:05 +0100

Elwyn Davies wrote:

> Please resolve these (slightly belated - sorry) comments along with 
> any other Last Call comments you may receive.

Thank you for your comment!

> proposal (REPORTEXPUNGED not allowed with FETCH command)

Yes.

> then this document is almost ready to go as proposed standard, modulo 
> the discussions in the imapext wg. If the decision goes the other way 
> additional usage.  There are a few editorial nits to fix (especially 
> the apparent espousal of magic in the abstract and s2).
>
> Issues
> ======
> s3.1: There is an open issue here: Whether the modifier is allowed 
> with the FETCH command as well as the UID FETCH command.  This needs 
> to be resolved before the doc goes to the IESG.  [Meta-issue: having 
> different semantics for the same extension on UID FETCH and FETCH 
> might be confusing.

It is, but in this particular case it make sense: UIDs are persistent, 
while message numbers not. A request to return messages expunged from a 
message set is meaningless, because message numbers are sequential, so 
they don't have "holes" for expunged messages.

> ]
> I always said the Internet worked by magic :-)

Absolutely :-)

> ... maybe 'gives a client that has been disconnected for a period the 
> ability, on reconnection, ...'

I am not sure this is more readable.

> s2/s4-para 2: Same point as for the abstract.

As above.

> Might also help to modify 'allows a client' to 'allows a reconnecting 
> client' in s2.

Ok.

> relating to previously seen messages'.

See my comment below regarding "flag values". I think the current text:

   The [CONDSTORE] extension gives a disconnected client ability to
   quickly synchronize flag changes for previously seen messages.

Is sufficiently clear in IMAP land. I can stick "IMAP" before "flag"?

> s3.1, para 2: s/The REPORTEXPUNGES FETCH modifier/The REPORTEXPUNGES 
> UID FETCH modifier/ - or some other way to make it clear that 
> immediately that this is the semantics for UID FETCH only.

Done.

> s3.1, para 4: s/flag changes/flag value changes/

IMAP flags are binary values: they are either set or not. So "flag" == 
"flag value", but the former is most commonly used in IMAP.

> s3.2, first example display: s/\Deleted messaged/\Deleted messages/?

Fixed, thanks.

> s3.2, para before last example display: s/can look like/might look like/

Ok.

> s4, para 3: s/NOMODSEQ/a NOMODSEQ/, s/more general instructions/the 
> more general instructions/

Done.

---

From: Elwyn Davies <[email-masked]>
Date: Fri, 22 Sep 2006 14:03:18 +0100

Alexey Melnikov wrote:
>> If the open issue noted in s3.1 is resolved by maintaining the 
>> current proposal (REPORTEXPUNGED not allowed with FETCH command)
>
> Yes.
>
> while message numbers not. A request to return messages expunged from 
> a message set is meaningless, because message numbers are sequential, 
> so they don't have "holes" for expunged messages.
I think I may not have been clear.. I was thinking about the *naming* 
being confusing.  I understand that it would not be applicable as is to 
FETCH.
> I am not sure this is more readable.
I suggest you think of something that is.. how about 'gives a client 
reconnecting after a period of disconnection the ability to...'
The language is disconcerting as it stands.
> Is sufficiently clear in IMAP land. I can stick "IMAP" before "flag"?
That would work. 
<<snipped - agreed bits>>

Regards
/Elwyn