MBOX-Line: From blong at google.com  Sat May 23 12:30:24 2015
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] COPYUID message order
In-Reply-To: <B992E8DF-EF7F-4C29-9869-41C8B4728D2D@isode.com>
References: <555FBFD2.1030800@ymail.com>
	<CABa8R6tpd-2GPoSTX0_d8wnROvQpm4_zmMxconJDPPud3NNdww@mail.gmail.com>
	<555FD141.1060300@ymail.com>
	<B992E8DF-EF7F-4C29-9869-41C8B4728D2D@isode.com>
Message-ID: <CABa8R6s6FQaj6tJRfkiZp+U1ybUeKsOYNb96BrFyiP4=WGavUA@mail.gmail.com>

I don't think you can guarantee that all of the messages you asked to be
copied were, for example one of them may have been expunged by a different
client.

Not sure what the need to match the requested UIDs vs the source UIDs
returned, but they may not match.

Brandon
On May 23, 2015 3:52 AM, "Alexey Melnikov" <alexey.melnikov@isode.com>
wrote:

> Hi Bill,
>
> On 23 May 2015, at 02:00, Bill Shannon <bill.shannon@ymail.com> wrote:
>
> I *so* wish there were compatibility tests for servers, rather than "it
> didn't break any clients so it must be good enough".  :-)
>
> Ok, how about this.  If I sort the original message numbers, and sort the
> returned source and destination UIDs, the result will be one-to-one,
> right?  The first message number will correspond to the first source UID,
> which will correspond to the first destination UID, right?  And all three
> sets will have exactly the same cardinality?
>
>
> Yes. I don't think it really matters in which order messages are copied,
> as long as the matching UIDs are returned correctly.
>
>
> Brandon Long wrote on 05/22/2015 05:17 PM:
>
> At least for Gmail, we always re-order the given set into sequence order
> (which is the same as uid order) before doing any operation.  So, the
> source UIDs in COPYUID are in the order in which they were copied.
>
> Since a COPY in Gmail is the equivalent of adding a label to a message,
> the message may already have that label, so it may already be in the
> recipient mailbox.  We always return the destination UIDs in the order
> which matches the source UID order, so in your example, source UID 1 is
> destination UID 2, and source UID 2 is destination UID 1.
>
>  When APPEND'ing a duplicate message, we update the UID assigned to the
> original to be the newest UID in the mailbox (and that's returned with
> APPENDUID), since we found clients typically assumed that was the case and
> could get confused.
>
>  We could have done this with COPY, I guess, but we didn't see any client
> issues in testing, so we left it this way since the performance is better.
>
>  Brandon
>
> On Fri, May 22, 2015 at 4:46 PM, Bill Shannon <bill.shannon@ymail.com>
> wrote:
>
>> I'm unclear on the requirements around the COPY command and the COPYUID
>> response code.
>>
>> Is there any guarantee that the order of messages in the COPY command is
>> the order they'll appear in the destination mailbox?  Or are they
>> allowed to appear in any arbitrary order in the destination mailbox?
>> (After any existing messages, of course.)
>>
>> RFC 4315 says of the COPYUID response:
>>
>>       The source UID set is in the order the message(s) were copied; the
>>       destination UID set corresponds to the source UID set and is in
>>       the same order.
>>
>> Exactly what order is that?  Is it the order in which the messages were
>> mentioned in the COPY command?  Is it the order they actually appear in
>> the destination mailbox (assuming it can be different)?  Or is it in
>> some other undefined order?
>>
>> With Gmail I'm getting
>>
>> A1 COPY 1:2 dest
>> A1 OK [COPYUID 123456 1:2 2,1]
>>
>> and
>>
>> A1 COPY 2,1 dest
>> A1 OK [COPYUID 123456 1:2 2,1]
>>
>> The order of the source UIDs is unrelated to the order the messages
>> are mentioned in the COPY command and unrelated to the order they
>> appear in the destination mailbox.
>>
>> If I don't know the UIDs of the source messages, is there any way to
>> determine which message was copied to which UID in the destination
>> mailbox?
>> _______________________________________________
>> Imap-protocol mailing list
>> Imap-protocol@u.washington.edu
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20150523/5cded60d/attachment.html>
