Subject: [imapext] imap move -01

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 26 Jul 2012 11:59:11 +0200

Hi,

the datatracker doesn't want to let me submit. I'll do that once the 
cutoff is past.

I append it the -01 for your consideration.

Changes since -00

-  Added MSN-based move. The consensus seems mildly in favour. I think.
    We'll see once this is posted.

-  Advise sending COPYUID earlier, to help clients. Requiring out of
    order processing is unnecessarily nasty.

It is possible that I'll add text to section 3 about it being desirable 
for the entire command to be atomic.

Arnt

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 26 Jul 2012 13:40:51 +0300

> I append it the -01 for your consideration.

One typo: "move each messag included". Otherwise looks perfect to me.

> It is possible that I'll add text to section 3 about it being desirable for the entire command to be atomic.

That would be ok, but I don't think it should be a SHOULD.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 26 Jul 2012 12:46:58 +0200

> That would be ok, but I don't think it should be a SHOULD.

I agree, "desirable", not "SHOULD".

Arnt

---

From: Dan Karp <[email-masked]>
Date: Thu, 26 Jul 2012 08:10:14 -0700 (PDT)

> Changes since -00
> 
> -  Added MSN-based move. The consensus seems mildly in favour. I
>     think.  We'll see once this is posted.
> 

   The MOVE command performs the same actions UID MOVE. Notably, the
   server may send EXPUNGE (or VANISHED) messages before the tagged
   response, so the client cannot safely send more commands with MSN
   arguments while the server is processing MOVE.

RFC 3501 uses the term "pipelining" for this.  How about "... so the
client cannot safely pipeline more commands with MSN arguments until
the server completes processing the MOVE"?

- Dan