mailing list archives

I'm hoping someone can clarify the following section of the new MOVE 
extension:

    Because a MOVE applies to a set of messages, it might fail partway
    through the set.  Regardless of whether the command is successful in
    moving the entire set, each individual message SHOULD either be moved
    or unaffected.  The server MUST leave each message in a state where
    it is in at least one of the source or target mailboxes (no message
    can be lost or orphaned).  The server SHOULD NOT leave any message in
    both mailboxes (it would be bad for a partial failure to result in a
    bunch of duplicate messages).  This is true even if the server
    returns a tagged NO response to the command.


In the case where a MOVE fails partway through the set and leaves some 
messages moved and others unaffected, does this imply that servers 
SHOULD return a NO in the tagged response, or is OK the more appropriate 
tagged response?

Thanks...
- Stuart

On Wed, 2013-02-06 at 12:38 -0500, Stuart Brandt wrote:
> I'm hoping someone can clarify the following section of the new MOVE 
> extension:
> 
>     Because a MOVE applies to a set of messages, it might fail partway
>     through the set.  Regardless of whether the command is successful in
>     moving the entire set, each individual message SHOULD either be moved
>     or unaffected.  The server MUST leave each message in a state where
>     it is in at least one of the source or target mailboxes (no message
>     can be lost or orphaned).  The server SHOULD NOT leave any message in
>     both mailboxes (it would be bad for a partial failure to result in a
>     bunch of duplicate messages).  This is true even if the server
>     returns a tagged NO response to the command.
> 
> 
> In the case where a MOVE fails partway through the set and leaves some 
> messages moved and others unaffected, does this imply that servers 
> SHOULD return a NO in the tagged response, or is OK the more appropriate 
> tagged response?

I was waiting for someone else to give a more exact answer, maybe
referring to the RFC text, but here's my take on it. I think the only
two reasonable server implementations are:

a) Return OK if you moved all of the messages, NO if you didn't move
anything. (This is similar to how COPY works.)

b) Return OK if you moved all messages that currently exist, i.e. you
skipped over messages recently expunged by another session. Return NO if
you didn't move anything. (I'm not a fan of this implementation.)

I don't think a server should leave the mailbox in a state where some of
the messages were copied and some of them weren't, except if something
exceptionally bad happens (e.g. server crash). If server happens to do
that anyway in normal code, it should return NO.

On Sat, Feb 9, 2013, at 03:55 AM, Timo Sirainen wrote:
> On Wed, 2013-02-06 at 12:38 -0500, Stuart Brandt wrote:
> > I'm hoping someone can clarify the following section of the new MOVE 
> > extension:
> > 
> >     Because a MOVE applies to a set of messages, it might fail partway
> >     through the set.  Regardless of whether the command is successful in
> >     moving the entire set, each individual message SHOULD either be moved
> >     or unaffected.  The server MUST leave each message in a state where
> >     it is in at least one of the source or target mailboxes (no message
> >     can be lost or orphaned).  The server SHOULD NOT leave any message in
> >     both mailboxes (it would be bad for a partial failure to result in a
> >     bunch of duplicate messages).  This is true even if the server
> >     returns a tagged NO response to the command.
> > 
> > 
> > In the case where a MOVE fails partway through the set and leaves some 
> > messages moved and others unaffected, does this imply that servers 
> > SHOULD return a NO in the tagged response, or is OK the more appropriate 
> > tagged response?
> 
> I was waiting for someone else to give a more exact answer, maybe
> referring to the RFC text, but here's my take on it. I think the only
> two reasonable server implementations are:
> 
> a) Return OK if you moved all of the messages, NO if you didn't move
> anything. (This is similar to how COPY works.)
> 
> b) Return OK if you moved all messages that currently exist, i.e. you
> skipped over messages recently expunged by another session. Return NO if
> you didn't move anything. (I'm not a fan of this implementation.)

Woah. WTF?

UID MOVE 1:* Dest

I think B is the only way that makes sense here. OK for "I moved every existing message matching the selector" and NO for any partial move where a matching message is left in the source mailbox.

If every matching message is not in the source mailbox, then IMHO you're done. If some got expunged before then user intent is that they don't exist any more, so it's "OK" for them to not be in Dest.

> I don't think a server should leave the mailbox in a state where some of
> the messages were copied and some of them weren't, except if something
> exceptionally bad happens (e.g. server crash). If server happens to do
> that anyway in normal code, it should return NO.
> 
> 
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol
-- 
  Bron Gondwana
  brong@fastmail.fm

On 8.2.2013, at 22.46, Bron Gondwana <brong@fastmail.fm> wrote:

>> I was waiting for someone else to give a more exact answer, maybe
>> referring to the RFC text, but here's my take on it. I think the only
>> two reasonable server implementations are:
>> 
>> a) Return OK if you moved all of the messages, NO if you didn't move
>> anything. (This is similar to how COPY works.)
>> 
>> b) Return OK if you moved all messages that currently exist, i.e. you
>> skipped over messages recently expunged by another session. Return NO if
>> you didn't move anything. (I'm not a fan of this implementation.)
> 
> Woah. WTF?
> 
> UID MOVE 1:* Dest
> 
> I think B is the only way that makes sense here. OK for "I moved every existing message matching the selector" and NO for any partial move where a matching message is left in the source mailbox.
> 
> If every matching message is not in the source mailbox, then IMHO you're done. If some got expunged before then user intent is that they don't exist any more, so it's "OK" for them to not be in Dest.

Well, that's not the same as how COPY works, so that would require yet another check for it. I'd have preferred the MOVE spec to require COPY-like behavior..

Also somewhat interesting case is what happens if you try to MOVE messages and none of them exist? OK reply without COPYUID tag? NO reply as a special case for this?..

My take:

Say NO if no messages were moved. (For whatever reason).

Say OK if some were. (Typically all extant messages in the range).

Rationale: You need to put in response codes in various places; it's not
clear to me you can put a HIGHESTMODSEQ in a NO response.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130208/535d10c3/attachment.html>

On 8 Feb 2013, at 21:16, Dave Cridland <dave@cridland.net> wrote:

> My take:
> 
> Say NO if no messages were moved. (For whatever reason).
> 
> Say OK if some were. (Typically all extant messages in the range).
> 
> Rationale: You need to put in response codes in various places; it's not clear to me you can put a HIGHESTMODSEQ in a NO response.
> 
I don't think HIGHESTMODSEQ makes sense in a NO response, but if no messages were moved, the server can return OK with no HIGHESTMODSEQ. Having said that, I don't have a strong preference one way or another, although I implemented returning OK when no messages were moved.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130209/6810f322/attachment.html>

Thanks for the good discussion. The scenario we're looking to cover is 
indeed the case Timo hit on - non-recoverable failure of some system 
component while processing an excessively large set of ids.

I'll keep monitoring to see if more clarify comes, but for now we're 
going to proceed with the approach Dave outlined below.

- Stuart

On 2/8/13 4:16 PM, Dave Cridland wrote:
> My take:
>
> Say NO if no messages were moved. (For whatever reason).
>
> Say OK if some were. (Typically all extant messages in the range).
>
> Rationale: You need to put in response codes in various places; it's not
> clear to me you can put a HIGHESTMODSEQ in a NO response.
>