Lovely review, thanks.
On 05/31/2012 04:20 PM, Cyrus Daboo wrote:
- §2: what is the problem with sequence MOVE and EXPUNGE?
I wouldn't mind having MSN-based move. But if you look at the yearly
move proposal disasters, MSNs were often mention just before the whole
thing exploded.
So I thought, since I couldn't find any clients that both expose move in
the UI and use COPY rather than UID COPY, why not skip the MSN variant
in the -00 draft?
If you as client author would prefer MOVE to UID MOVE, and none of the
server authors have a problem with implementing it, then I don't mind
adding it to the draft.
- §2: "atomically" - I would prefer not to use the term "atomic" given
that we are allowing partial failures (i.e., some messages might not be
moved, whilst others are). So in the first paragraph I suggest changing
"atomically" to "using a single command".
The word atomic seems to be a trouble magnet. I've removed the word
completely from the draft, and instead merely describe what's desired
(each single message is either moved or left unchanged).
- §3: This needs a 3501-like "formal" definition with Arguments:,
Responses:, Results: etc. It should use the same text for describing
preservation of flags (see note below) and internal date.
I disgree, but if you want I'll do it. For now I've only added an open
issue to do it (time is short today and I'm still only halfway through
your review).
We need to
decide whether the \Recent flag is set like COPY (probably should be).
I'm strongly in favour. Everything should be like copystoreexpunge,
unless there is a specific and good reason to differ.
Also, the [TRYCREATE] behavior from COPY should be re-used. Should
probably note that this command is only valid in selected state (or
include a comment to that effect in the formal syntax which 3501 does
for the command-select syntax element).
It is reused already; MOVE is defined in terms of, etc. But I'll add a
sentence like "which means that e.g. TRYCREATE blah".
- §3, ¶2: "UID EXPUNGE" - need a reference to the UIDPLUS extension.
Added already. If I didn't misunderstand, Barry asked me to not post any
update until the WG has been chartered.
- §3, ¶4: states that \Deleted must not be set in the target mailbox.
But what if the messages being moved already had \Deleted set prior to
the move? Shouldn't we just state that the flag/keywords prior to the
move must be set on the messages in the target mailbox?
I've had requests that it work both ways. I have no strong opinions myself.
- §3: As already mentioned, EXPUNGE responses need to be present. Might
be worth pointing out that there could be a * EXPUNGE for a message not
being moved, but which got expunged in another session. Actually, more
complicated is the case where a message being moved was expunged in
another session - presumably that message is not moved? Yet it would get
reported in a * EXPUNGE, but not be part of the COPYUID set.
Fixed.
- §3: Might want to make it clear that * FETCH FLAGS is NOT sent if
moved messages have \Deleted added as part of the "internal" server
implementation of move.
I don't think that was at all clear, or even intended ;) But I think
you're right, and I added it.
- §3: Example: change "@S:" to "S:".
Fixed.
- §3: COPYUID response in the argument is wrong - it should have three
values: destination mailbox UIDVALIDITY, set of uids from source
mailbox, set of uids in destination mailbox. Current example only shows
one set of uids.
Fixed.
- §4: whilst no one may implement it, there still ought to be a
reference to the interaction with ANNOTATE. ANNOTATE §4.6 has detailed
text on the interaction with COPY and something similar is needed for MOVE.
A few paragraphs up I added a sentence stating specifically that
extensions that extend COPY, extend MOVE in the same way. Will that do?
- §6: "command" is not the right syntax element to extend. I would
suggest defining a uidmove element and then use that to extend the 3501
uid element:
uidmove = "UID MOVE" SP set SP mailbox
uid =/ uidmove
I've changed since I posted the last update. I'll leave it as it is for
now. Who knows whether we'll have an MSN-based move.
Barry: I understood you as saying that I should hold of on posting
updates until the WG has been formed. Was that right, or can I post an
update? Cyrus: If I post an update soon, it'll likely contain TBD for
some of your issues.
Arnt
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
