Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    imapmove mailing list <imapext@ietf.org>,
    imapmove chair <imapmove-chairs@tools.ietf.org>
Subject: Protocol Action: 'Internet Message Access Protocol (IMAP) - MOVE Extension' to Proposed Standard (draft-ietf-imapmove-command-05.txt)

The IESG has approved the following document:
- 'Internet Message Access Protocol (IMAP) - MOVE Extension'
  (draft-ietf-imapmove-command-05.txt) as Proposed Standard

This document is the product of the IMAP MOVE extension Working Group.

The IESG contact persons are Barry Leiba and Pete Resnick.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-imapmove-command/


Ballot Text

Technical Summary

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. 


Working Group Summary

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.


Document Quality

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. 


Personnel

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

RFC Editor Note