* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Imapmove Status Pages

IMAP MOVE extension (Concluded WG)
App Area: Barry Leiba | 2012-Jul-17 — 2013-Jan-31 
Chairs
 
 


2013-01-17 charter

IMAP MOVE extension (imapmove)
------------------------------

 Charter

 Current Status: Active

 Chairs:
     Alexey Melnikov <alexey.melnikov@isode.com>
     Ned Freed <ned.freed@mrochek.com>

 Applications Area Directors:
     Barry Leiba <barryleiba@computer.org>
     Pete Resnick <presnick@qti.qualcomm.com>

 Applications Area Advisor:
     Barry Leiba <barryleiba@computer.org>

 Mailing Lists:
     General Discussion: imapext@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/imapext
     Archive:            http://www.ietf.org/mail-archive/web/imapext/

Description of Working Group:

  The Internet Message Access Protocol (IMAP), defined in RFC 3501,
  specifies a protocol for transferring email messages between a server
  that implements a message store, and a client. It also includes
  commands for manipulating the message store -- creating, deleting, and
  renaming mailboxes, adding a message to a mailbox, and copying
  messages from one mailbox to another.

  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.

  The IMAP MOVE extension (imapmove) working group has the single task
  of developing an IMAP MOVE extension that defines a single command to
  move a set of messages from a source mailbox to a target mailbox in a
  single operation. The group will use draft-gulbrandsen-imap-move as a
  starting point, and will produce a Standards Track document.

  As part of the protocol development, implementation experience on both
  the client and server side is highly desireable, so that the actual
  operational value of this extension can be assessed. The working group
  will document the results of this experience on the working group
  wiki.

  No other IMAP extension work is in scope for this working group.


Goals and Milestones:
  Done     - Initial adoption of IMAP MOVE protocol document
  Done     - Establishment of implementation tracking on the working group wiki
  Done     - IMAP MOVE protocol document to IESG as Proposed Standard
  Done     - Initial assessment of implementation results
  Done     - Final report on implementation results: http://tools.ietf.org/wg/imapmove/trac/wiki


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/imapmove/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -