Re: [imap5] Comments on draft-gulbrandsen-imap-move-01

[Arnt Gulbrandsen <[e-mail]>]

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