Alexey Melnikov wrote:
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.
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.
]
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.
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.
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"?
That would work.
<<snipped - agreed bits>>
Regards
/Elwyn
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
