Subject: [imapext] I-D ACTION:draft-ietf-imapmove-command-00.txt

From: [email-masked]
Date: Thu, 28 Jun 2012 14:15:01 -0700

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IMAP MOVE extension Working Group of the IETF.

    Title         : The IMAP Move Extension
    Author(s)     : A. Gulbrandsen
    Filename      : draft-ietf-imapmove-command
    Pages         : 7 
    Date          : June 28, 2012 
    
The MOVE extension provides a new command, UID MOVE, which moves one
   or more messages from the selected mailbox to a named mailbox.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-imapmove-command-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Dan Karp <[email-masked]>
Date: Thu, 28 Jun 2012 14:47:01 -0700 (PDT)

> 3. UID MOVE

>  First, each message SHOULD either be moved or unaffected. The server
>  SHOULD NOT leave a message in neither or both mailboxes afterwards
>  (even if the server returns a tagged NO response).

Can there be a situation where some messages in the set are moved and
others are unaffected?

>  Second, the messages MUST NOT have the \Deleted flag set in the
>  target mailbox.

What if the original messages already had the \Deleted flag set?

>  Third, the server is not required to send FETCH FLAGS responses for
>  the messages it expunges.

Why would it have to do this in any case?

- Dan

---

From: Brandon Long <[email-masked]>
Date: Thu, 28 Jun 2012 15:03:01 -0700

A general question: if one wanted to implement the draft, does one then
make it available as XMOVE? (er, UID XMOVE?)  And then, potentially, need
to support XMOVE for some very long time?

Or does one just export it as specified in the draft, and update over time
as drafts come out?

This is probably more of a request for opinions, I assume there isn't a
single correct way to go.

Brandon

On Thu, Jun 28, 2012 at 2:15 PM, <[email-masked]> wrote:

> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext
>
>

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 29 Jun 2012 00:15:39 +0200

On Thu, Jun 28, 2012, at 03:03 PM, Brandon Long wrote:

  A general question: if one wanted to implement the draft, does
  one then make it available as XMOVE? (er, UID XMOVE?)  And
  then, potentially, need to support XMOVE for some very long
  time?

Or does one just export it as specified in the draft, and update
over time as drafts come out?

This is probably more of a request for opinions, I assume there
isn't a single correct way to go.

I thought X was out.

https://datatracker.ietf.org/doc/rfc6648/

That said, I'm offering both in Cyrus now, and planning to leave
them both in, since it doesn't hurt except by making CAPABILITY
even longer than it already is.

Bron.
-- 
  Bron Gondwana
  [email-masked]

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 29 Jun 2012 00:23:28 +0200

> Can there be a situation where some messages in the set are moved and

I suspect it's going to be implementation dependent.  Worst cases are
always things like crashes and filesystem corruption, where all bets
are a bit off...

> What if the original messages already had the \Deleted flag set?

My memory of the recent(ish) discussions would lead me to suggest wording
that goes something like:

  "Messages SHOULD have the same flags set as they did in the source
   mailbox and MUST NOT have \Deleted set if it was not set on the
   source message before the MOVE".

The reasoning for the SHOULD is that different mailboxes might not
support some flags (probably a bogus argument, but hey)

There's an argument for stripping \Deleted during a move, since chances
are that the user indended to delete them and you just caught a race.
Then again, there's an argument for flat-out rejecting the move if you
hit a message with \Deleted set too...

But the simplest and clearest is "it's EXACTLY THE SAME as
COPY + STORE + UID EXPUNGE" - so semantics should match that, and
COPY will transfer the \Deleted flag if it's set, so do that.

> Why would it have to do this in any case?

That looks confused to me.  It should say "is not required to send EXPUNGE
untagged responses for ...".  And I am in favour of stripping this and saying
send them.  Same argument - it should be identical to COPY + STORE + UID
EXPUNGE.

Bron.
-- 
  Bron Gondwana
  [email-masked]

---

From: Dan Karp <[email-masked]>
Date: Thu, 28 Jun 2012 16:27:18 -0700 (PDT)

> > >  Third, the server is not required to send FETCH FLAGS responses
> > >  for the messages it expunges.
> > 

Actually, I see why it'd do this.  We're defining UID MOVE as "the same
effect as a sequence of UID COPY, UID STORE +FLAGS \DELETED and UID EXPUNGE".
If we changed it to "UID STORE +FLAGS.SILENT \DELETED", this issue would
go away (and the MOVE definition would probably be clearer).

- Dan

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 28 Jun 2012 20:20:20 -0400

Hi Dan,

--On June 28, 2012 4:27:18 PM -0700 Dan Karp <[email-masked]> wrote:

> effect as a sequence of UID COPY, UID STORE +FLAGS \DELETED and UID
> EXPUNGE". If we changed it to "UID STORE +FLAGS.SILENT \DELETED", this
> issue would go away (and the MOVE definition would probably be clearer).

Yes! Good suggestion.

-- 
Cyrus Daboo

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 29 Jun 2012 07:55:45 +0200

On 06/29/2012 12:15 AM, Bron Gondwana wrote:
> That said, I'm offering both in Cyrus now, and planning to leave them
> both in, since it doesn't hurt except by making CAPABILITY even longer
> than it already is.

There are four independent XMOVEs. Although they doubtlessly do the same 
general thing, I do wonder what confusion different details might wreap 
upon clients. Personally I'd just as soon stay away from XMOVE.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 29 Jun 2012 07:57:42 +0200

> go away (and the MOVE definition would probably be clearer).

Duh. Done.

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 29 Jun 2012 08:33:09 +0200

> Can there be a situation where some messages in the set are moved and

A couple of people asked for it, at least. Problems might become 
apparent underway, when half the messages have been moved. Moving all 
error checking to the head of the command handler is desirable, but 
AFAICT not always practical.

It's a bit 1990-ish, but consider what happens if you run out of disk 
space wherever the target mailbox is hosted halfway through.

> What if the original messages already had the \Deleted flag set?

I deleted that sentence now. Whoever asked for it can come forward.

Arnt

---

From: Brandon Long <[email-masked]>
Date: Fri, 29 Jun 2012 11:30:38 -0700

On Thu, Jun 28, 2012 at 11:33 PM, Arnt Gulbrandsen <[email-masked]
> wrote:

> A couple of people asked for it, at least. Problems might become apparent
> underway, when half the messages have been moved. Moving all error checking
> to the head of the command handler is desirable, but AFAICT not always
> practical.
>

For us, given that any IMAP command can affect any number of messages
(millions?), its impractical for us to do them all in a single transaction.
 Doing so could take an hour (or more), preventing any other mailbox
transactions for the entire time.  Splitting it into multiple transactions,
however, does mean that one of them may fail, leaving us in a middle state.

Its non-ideal, and of course with the right backend you might be able to
avoid these issues, but there are a lot of competing interests in a backend
such as ours, and executing a change across millions of messages wasn't in
the initial design.

Brandon

> ______________________________**_________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/imapext<https://www.ietf.org/mailman/listinfo/imapext>
>

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 29 Jun 2012 22:38:58 +0200

On 06/29/2012 08:30 PM, Brandon Long wrote:
> avoid these issues

That the backend you have is the backend you have. And because of that, 
I just said "atomic per message, not per move command".

Arnt

---

From: Jan Kundrát <[email-masked]>
Date: Fri, 29 Jun 2012 23:36:24 +0200

I recognize that the UID COPY & UID STORE & UID EXPUNGE has the very 
same problem as I'm presenting here, but I'd like to (re)propose an 
untagged variant of the COPYUID response code working like this one:

C: a UID MOVE 2:5 target
S: * OK [MOVEUID a 432432 1202:1205] Messages moved
S: * VANISHED 2:5
S: a OK Moved

The MOVEUID response code would be defined by reference to COPYUID with 
the following changes:

- If it gets sent at all, it MUST be sent in an untagged response before 
the EXPUNGEs/VANISHED responses are sent
- If the server supports UIDPLUS and would otherwise send COPYUID, teh 
MOVEUID response MUST be sent
- The format of the response is the same as the COPYUID with a single 
exception, the "COPYUID" string is replaced by a sequence of `"MOVEUID" 
SPACE tag` where "tag" refers to the tag of the UID MOVE command which 
caused this action

If the consensus is that doing that is a huge overkill, I'm proposing 
adding a sentence similar to this one to the draft, section 4.3:

"Client implementors shall keep in mind that the EXPUNGE or VANISHED 
responses precede delivery the COPYUID response code.  In case the 
clients want to make use of the returned information, they should 
postpone removing the affected messages from their cache until the 
tagged response is processed."

But maybe even that is so obvious that it has no place in a RFC -- I've 
never written one, so please use your best judgment and feel free to 
reject this proposal. On the other hand, as a client developer, if the 
RFC did not contain such a notice, I'd consider that 
extra-reference-to-cached-copies-for-move to be a hack worth asking the 
ML whether I'm missing something.

With kind regards
Jan

-- 
Trojita, a fast e-mail client -- http://trojita.flaska.net/