Internet Message Access Protocol (IMAP) - MOVE Extension
draft-ietf-imapmove-command-05

Note: This ballot was opened for revision 02 and is now closed.

Barry Leiba (was Discuss, Yes) Yes

Comment (2012-11-27 for -04)
No email
send info
The -04 version resolves the issue I was holding that derived from one of Stephen's comments.

(Pete Resnick) (was Discuss) Yes

Comment (2012-11-26 for -03)
No email
send info
Section 1:

Purely editorial nonsense:

   clients have instead had to use a combination of the UID STORE, UID
   COPY and EXPUNGE commands to perform this very common operation.
   
Seems to me that you should list the commands without the UID (since they're not required) and in the right order. So instead:

   clients have instead had to use a combination of the COPY, STORE,
   and EXPUNGE commands to perform this very common operation.
   
And if you have any reason for keeping the original, do so. Just one AD's OCD.

Section 3.3:

I suggest inserting a paragraph after the example and before "Because a MOVE applies to a set of messages":

   Although the effect of the MOVE is the same as the preceding steps,
   the semantics are not identical: The intermediate states produced by
   those steps do not occur, and the response codes are different. In
   particular, though the COPY and EXPUNGE response codes will return,
   no response code for a STORE will be generated nor will the \DELETED
   flag be set for any message.

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-11-27 for -04)
No email
send info
No objection to the publication of the document, but one observation: I believe that the intro is a little bit light, while I found some good text from the charter could be cut/pasted:

    It's often the case that an IMAP client needs to move (not copy)
    messages from one mailbox to another. The mechanism that IMAP
    provides to do that is a multi-step process:
    1. Copy the messages from the source mailbox to the target mailbox.
    2. Flag the original messages in the source mailbox as deleted.
    3. Expunge the deleted messages from the source mailbox.

    Implementors have long pointed out some shortcomings with this
    approach. Because the moving of a message is not an atomic process,
    interruptions can leave messages in intermediate states. Because
    multiple clients can be accessing the mailboxes at the same time,
    clients can see messages in intermediate states even without
    interruptions. If the source mailbox contains other messages that are
    flagged for deletion, the third step can have the side effect of
    expunging more than just the set of moved messages. And servers with
    certain types of back-end message stores might have efficient ways of
    moving messages, which don't involve actual copying of data. Such
    efficiencies are often not available to the copy/flag/expunge process.

We sometimes make too hard to read RFCs by only focusing on the protocol specifications, and neglecting the problem statement and use case.

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-11-26 for -03)
No email
send info
I don't object to the publication of this document.

I think that the motivation may be slightly over-cooked...

While I can see good value in facilitating the move operation through a
single command, I don't think that the motivation given in the 
Introduction is particularly helpful. The implication of the text is
that the new command will provide protection against partial completion 
during a failure. But in fact exactly the same operations are needed in
the mailboxes using the MOVE command as were previously needed. So while
the reduction in commands helps to reduce the failure windows, the use
of a single command does not close the windows completely. (Obviously,
it makes the life of the Client massively simpler.)

(Stephen Farrell) No Objection

Comment (2012-11-26 for -03)
No email
send info

- 3.1, I briefly wondered if MOVE has two or four arguments,
maybe s/sequence set/sequence-set/ and 
s/mailbox name/mailbox-name/ would be a tiny bit clearer.

- 3.3, 3rd last para: I didn't get the meaning here, nor am I
sure if the "is allowed when..." means that this is not allowed
in other situations. I assume this is clear to IMAP folks
though.

- 3.3, last para: does this mean that a server has to implement
a check that pipelined MOVEs don't have overlapping sets of
messages, or that servers depend on clients to do the right
thing? Do you need to clarify that?

(Brian Haberman) No Objection

(Russ Housley) No Objection

(Robert Sparks) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection