Draft:  draft-melnikov-imap-expunged-01.txt
Reviewer: Elwyn Davies [elwynd@dial.pipex.com]
Review Date: Friday 9/22/2006 3:32 AM
IETF LC Date: 9/20/2006

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/