Open shikharid opened 3 months ago
COPY: I guess it's not prevented by RFCs, but I've a feeling it's not going to be nice client/user behavior. I wouldn't be surprised if it breaks some clients.
MOVE: Here I think even the RFC disagrees. It says MOVE is the same behavior as:
So the 1. step already tells it to assign a new UID, because two message instances can't have the same UID.
For 2, you are right I guess.
For 1, I can't comprehend why. The simplest implementation for a client is:
COPYUID <src-uids> <dest-uids>
Any other way will be very convoluted, in fact I can't see how a client may do it any other way.
For 1 I'm mainly thinking that if there are no other IMAP servers copying out-of-order, the existing client implementationa may never have tested whether it works. Anyway, I guess I could do some change in that test, but first I'd want to ask from imap-protocol mailing list whether someone else can think of a reason why the order would actually have to be preserved. IMAP RFC is sometimes hiding information in a bit random places.
Makes sense, thanks! And I have an IMAP server copying out of order, hence the ask : )
These following tests have expectations nowhere defined in RFCs:
Test copy command 17/24 (line 32)
A->B
, equivalent UIDs in B will be1->1, 2->2, 4->3
1->2, 2->1. 3->2
is also validTest move command 12/13 (line 44)
Again, happy to raise a PR fixing these. Let me know.