On Wed, May 30, 2012 at 12:22 PM, Cyrus Daboo <[email protected]> wrote:
> Which mailing list? imapext or imap5? Typo (or braino). There is no "imapext" list. >> 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 But UID EXPUNGE is part of the UIDPLUS extension, not in base IMAP (and I'm not sure how widely deployed UIDPLUS is. And, as you say, one would have to be mentally unstable to try to work around this the other way. Still, "can have" is fine, and I've changed the text. >> 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. It's meant to be "atomic" from the client's view, whether or not it's atomic in the server. But I prefer your later suggestion of "single command", so I've changed it accordingly. > Are there existing client and server implementations of the > draft-gulbrandsen-imap-move right now? So Arnt tells me. > 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? If there's interop testing, it would be very fine to document that here. But that's not what this is about; this is to show that there's a real need for this, and active work on implementations (as opposed to our developing another IMAP extension that gets essentially no use). Attached is the latest charter version, with these changes. Barry
IMAP MOVE extension (imapmove) Chair(s): TBD Applications Area Director(s): Pete Resnick <[email protected]> Barry Leiba <[email protected]> Mailing Lists: General Discussion: [email protected] To Subscribe: https://www.ietf.org/mailman/listinfo/imap5 Archive: http://www.ietf.org/mail-archive/web/imap5/ 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. Milestones 07/2012 Initial adoption of IMAP MOVE protocol document 07/2012 Establishment of implementation tracking on the working group wiki 08/2012 Initial assessment of implementation results 09/2012 Final report on implementation results 10/2012 IMAP MOVE protocol document to IESG as Proposed Standard
_______________________________________________ imap5 mailing list [email protected] https://www.ietf.org/mailman/listinfo/imap5
