Elwyn Davies wrote:
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.
Thank you for your comment!
Summary
=======
If the open issue noted in s3.1 is resolved by maintaining the current
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
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.
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.
]
Editorial
=========
Abstract: 'gives a disconnected client ability to quickly learn about
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.
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'.
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
