Subject: [imapext] Barry Leiba's Discuss on draft-ietf-imapmove-command-03: (with DISCUSS)

From: "Barry Leiba" <[email-masked]>
Date: Mon, 26 Nov 2012 07:03:07 -0800

Barry Leiba has entered the following ballot position for
draft-ietf-imapmove-command-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The last paragraph of Section 3.3 says this:

   Both MOVE and UID MOVE can be pipelined.  However, pipelined MOVE and
   UID MOVE commands MUST NOT specify overlapping sets of messages.

I'm not sure the "overlapping sets" is a sufficient restriction for
(non-UID) MOVE.  Consider a mailbox with messages having UIDs 101, 102,
103, 104, 105, 106, and 107, and this sequence:

C: t1 MOVE 2:3 Apple
C: t2 MOVE 4:5 Banana
S: * EXPUNGE 2
S: t1 NO [SERVERBUG] the move for message 3 failed

The command tagged t1 is meant to move UIDs 102 and 103.  That move will
cause the messages to be renumbered (leaving 101, 104, 105, 106, and
107), so that messages 4 and 5 represent UIDs 106 and 107.  But because
the move for message 3 (UID 103) failed, messages 4 and 5 will afterward
actually be UIDs 105 and 106.

I think that what this actually means is that the last two paragraphs are
contradictory:

   The server may send EXPUNGE (or VANISHED) messages before the tagged
   response, so the client cannot safely send more commands with message
   sequence number arguments while the server is processing MOVE.  The
   UID MOVE command does not have this limitation.

   Both MOVE and UID MOVE can be pipelined.  However, pipelined MOVE and
   UID MOVE commands MUST NOT specify overlapping sets of messages.

We can't have "the client cannot safely send more commands with message
sequence number arguments while the server is processing MOVE," and at
the same time allow the version of MOVE that uses sequence numbers to be
pipelined.  We might also consider a citation to RFC 3501, Section 5.5
here.

---

From: Ned Freed <[email-masked]>
Date: Mon, 26 Nov 2012 13:40:52 -0800 (PST)

> pipelined.  We might also consider a citation to RFC 3501, Section 5.5

Thinking about this further,  since pipelined commands can be executed in any
order, there is no case for which MOVE or UID MOVE can be pipelined with a
command that uses sequence numbers, including MOVE. I therefore propose
changing this paragraph to read something like:

    Both MOVE and UID MOVE can be pipelined with other commands. However,
    since both commands modify sequence numbers these commands MUST NOT
    be pipelined with additional commands (including another MOVE) that employ
    sequence numbers that would be affected by the MOVE or UID MOVE command.
    Additionally, MOVE MUST NOT be pipelined with commmands that would affect
    its sequence numbers.

I think this covers all the cases.

Thoughts?

				Ned

---

From: Ned Freed <[email-masked]>
Date: Mon, 26 Nov 2012 14:32:16 -0800 (PST)

> ...

> > pipelined.  We might also consider a citation to RFC 3501, Section 5.5

That's a good idea and I left it out, sorry.

>     Additionally, MOVE MUST NOT be pipelined with commmands that would affect

How about I add:

      See section 5.5 of RFC 3501 for additional restrictions on command
      pipelining.

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 26 Nov 2012 17:51:27 -0500

> I think this covers all the cases.

I'm not sure everyone reading it will understand that "MOVE 1 Banana"
affects *every* sequence number in the mailbox.  Also, because
unrelated EXPUNGE responses can come in during a MOVE, it's not safe
to pipeline MOVE after MOVE or UID MOVE, even if the message sets
appear to be safe.

So maybe this?:

   Both MOVE and UID MOVE can be pipelined with other commands, but care
   has to be taken.   Both commands modify sequence numbers and also allow
   unrelated EXPUNGE responses.  The renumbering of other messages in the
   source mailbox following any EXPUNGE response can be surprising , and
   makes it unsafe to pipeline any command that relies on message sequence
   numbers after a MOVE or UID MOVE.  Similarly, MOVE cannot be pipelined
   after a command that might cause message renumbering.  See [RFC3501],
   Section 5.5, for more information about sequence number ambiguities.

Barry

---

From: Ned Freed <[email-masked]>
Date: Mon, 26 Nov 2012 15:13:02 -0800 (PST)

>    Section 5.5, for more information about sequence number ambiguities.

Yes, this is definitely better. The only thing I think needs changing is
"after a command" should be "with a command".

I'm going to go ahead and put this in with that change.

				Ned

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 27 Nov 2012 07:36:54 +0100

> Thoughts?

Fine

Arnt