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

[Ballot comment]
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.

[Ballot comment]
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.)

[Ballot comment]
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.

[Ballot discuss]
The last paragraph of Section 3.3 says this:

  Both MOVE and UID MOVE can be pipelined.  However, pipelined MOVE and
  UID MOVE commands MUST NOT specify overlapping sets of messages.

I'm not sure the "overlapping sets" is a sufficient restriction for (non-UID) MOVE.  Consider a mailbox with messages having UIDs 101, 102, 103, 104, 105, 106, and 107, and this sequence:

C: t1 MOVE 2:3 Apple
C: t2 MOVE 4:5 Banana
S: * EXPUNGE 2
S: t1 NO [SERVERBUG] the move for message 3 failed

The command tagged t1 is meant to move UIDs 102 and 103.  That move will cause the messages to be renumbered (leaving 101, 104, 105, 106, and 107), so that messages 4 and 5 represent UIDs 106 and 107.  But because the move for message 3 (UID 103) failed, messages 4 and 5 will afterward actually be UIDs 105 and 106.

I think that what this actually means is that the last two paragraphs are contradictory:

  The server may send EXPUNGE (or VANISHED) messages before the tagged
  response, so the client cannot safely send more commands with message
  sequence number arguments while the server is processing MOVE.  The
  UID MOVE command does not have this limitation.

  Both MOVE and UID MOVE can be pipelined.  However, pipelined MOVE and
  UID MOVE commands MUST NOT specify overlapping sets of messages.

We can't have "the client cannot safely send more commands with message sequence number arguments while the server is processing MOVE," and at the same time allow the version of MOVE that uses sequence numbers to be pipelined.  We might also consider a citation to RFC 3501, Section 5.5 here.

[Ballot comment]


- 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?

[Ballot discuss]
I have not been following this WG, and I might have the Sieve bit wrong, so I apologize in advance if this issue has been considered and addressed by the WG; if so, I will remove this DISCUSS immediately. But this causes me concern:

Section 4.5:

  Because MOVE does not cause flags
  to be changed, a MOVE command will not result in a script invocation
  with the imap.cause set to "FLAG".
 
I think this is either wrong or needs more explanation. Section section 3.3 is clear that doing a move "has the same effect for each message as...[UID] STORE +FLAGS.SILENT \DELETED", which the above seems to contradict. But even this is intended, I would think this would at the very least cause significant user surprise: In a current client, if I choose the "move" command in the UI, I'm going to get an invocation for the COPY on the destination message *and* an invocation for the STORE \DELETED on the source message. You are saying that an upgraded client that starts using "MOVE" for it's "move" command will suddenly stop invoking for the deletion. If you *don't* want Sieve to invoke for the flag change, I think you're going to have to add a new imap.cause of either MOVE or EXPUNGE, and folks will have to go rewrite their scripts. But I would think the easier route would be to get a second invocation from MOVE with imap.cause set to "FLAG".

[Ballot comment]
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.

IANA has reviewed draft-ietf-imapmove-command-02 and has the following comments:

IANA understands that, upon approval of this document, there is a single
IANA action which must be completed.

In the IMAP 4 Capabilities registry located at:

http://www.iana.org/assignments/imap4-capabilities

A single, new registration will be made as follows:

Capability Name: MOVE
Reference: [ RFC-to-be ]

IANA understands that this is the only action required to be completed
upon approval of this document.

Note: The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The IMAP Move Extension) to Proposed Standard


The IESG has received a request from the IMAP MOVE extension WG
(imapmove) to consider the following document:
- 'The IMAP Move Extension'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-11-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines an IMAP extension consisting of two new
  commands, MOVE and UID MOVE, that are used to move messages from one
  mailbox to another.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd writeup:

1. Summary

Alexey Melnikov is the document shepherd. Barry Leiba is the
responsible AD.

This document defines an IMAP extension to move messages from one
mailbox to another. This function (very common in MUA UIs) is not
provided by stock IMAP, and clients have to use a combination of
UID STORE, UID COPY and EXPUNGE, and cope with partial failures
and side effects. The document is targeted to become as
Standards Track document, which is appropriate for this type of
document.

2. Review and Consensus

There was some discussion in the WG about whether MOVE command
(as opposed to just UID MOVE) should be defined in the document
or not. Consensus was that there was no reason not to define it
(this preserves symmetry with other IMAP commands that operate on
a group of messages.)

There was also a discussion on whether multiple pipelined MOVE
commands should be allowed or not.

None of these discussions were particularly heated or long lived.
The document was extensively reviewed by IMAP experts and that is
the most important type of review for it.

There are multiple implementations of this IMAP extension in both
clients and servers. More than 5 different servers implement it
already.

3. Intellectual Property

The authors confirm compliance with BCPs 78 and 79, and there are
no IPR disclosures related to this document.

4. Other Points

idnits 2.12.13 reports 1 warning about a missing reference, which
is a false positive -- an IMAP protocol element "[UID]".