Hi Barry,
Comments on charter below.
--On May 30, 2012 9:39:18 AM -0400 Barry Leiba <[email protected]>
wrote:
Mailing Lists:
General Discussion: [email protected]
To Subscribe: https://www.ietf.org/mailman/listinfo/imap5
Archive: http://www.ietf.org/mail-archive/web/imap5/
Which mailing list? imapext or imap5?
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 has the side effect of expunging
^^^
Really it is "can have the side effect" since clients might have the option
of using UID EXPUNGE, or could play tricks of undeleting the non-copied
deleted messages, doing the expunge, then re-deleting - of course no one in
their right mind would do that...
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 atomic IMAP MOVE command that will move a set of
^^^^^^ ^^^^^^^
Use "extension" instead of "command" as the actual command is "UID MOVE" as
per Arnt's spec. As per Timo, I am not sure we should state it will be
"atomic" as that may restrict what we do in the spec.
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.
Are there existing client and server implementations of the
draft-gulbrandsen-imap-move right now? Does "implementation" also cover
actual interoperability testing, or does it only speak to the actual
ability to modify existing servers/clients to adopt the extension?
--
Cyrus Daboo
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
