Subject: [imapext] Improved introduction to imapmove-command?

From: Ned Freed <[email-masked]>
Date: Wed, 28 Nov 2012 09:49:06 -0800 (PST)

Benoit Claise entered a comment (attached below) saying that the current
introduction is a little thin (which it is) and suggesting the addition
of some text from the charter.

The current introduction text is very short:

   This document defines an IMAP [RFC3501] extension to facilitate
   moving messages from one mailbox to another.  This is accomplished by
   defining a new MOVE command and extending the UID command to allow
   UID MOVE.

   A move function is not provided in the base IMAP specification, so
   clients have instead had to use a combination of the COPY, STORE, and
   EXPUNGE commands to perform this very common operation.  This has
   meant needing to cope with partial failures and side effects that can
   occur when multiple commands are involved.

   The MOVE extension is present in any IMAP4 implementation which
   returns "MOVE" as one of the supported capabilities to the CAPABILITY
   command.

My view is that the first and last paragraphs are fine, but the middle one
could do with some elaboration. I wish using the charter text had occurred to
me earlier; if it had I would have already done it.

Anyway, how about the following as a replacement?

    A move function is not provided in the base IMAP specification, so
    clients have instead had to use a combination of the COPY, STORE, and
    EXPUNGE commands to perform this very common operation.

    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/STORE/EXPUNGE
    process.

I'm pretty sure this changes nothing about the protocol, so it's a safe
change to make at this point. 

Thoughts?

Subject: Benoit Claise's No Objection on draft-ietf-imapmove-command-04: (with COMMENT)
From: Benoit Claise <[email-masked]>
To: The IESG <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Tue, 27 Nov 2012 01:52:14 -0800
List-Id: <[email-masked]>

Benoit Claise has entered the following ballot position for
draft-ietf-imapmove-command-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Nov 2012 18:11:47 +0000

> change to make at this point.
Works for me (speaking as a participant).