what about using the sequences in the final tagged response as an
indication of what was actually successfully moved.. the ones that map
source messages to new UIDs.
We suppress EXPUNGE responses during MOVE already. When you're moving
a large set of messages, this improves things quite a bit in terms of
bw and speed.
----
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
------ Original Message ------
From: "Timo Sirainen" <[email protected]>
To: "Cyrus Daboo" <[email protected]>
Cc: "Discussion on drastically slimming-down IMAP." <[email protected]>
Sent: 31/05/2012 5:27:22 a.m.
Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned
during UID MOVE?
On 30.5.2012, at 20.20, Cyrus Daboo wrote:
So Arnt tells me.
If I can implement it this way without violating the spec:
1. Verify that ACLs allow expunge, fail if not
2. Do atomic UID COPY without enforcing quota limits
3. Expunge the messages
[4. If expunge for some strange reason fails now, there are probably
duplicates now. I'm not sure if I want to bother fixing that situation.
It should "never" happen anyway.]
then I could add it to Dovecot pretty much immediately.
So if the expunge does fail, how are you going to report that to the client?
Arnt's current spec does not show any * N EXPUNGE responses coming back, so I
am assuming that the client is supposed to implicitly assume the expunges took
place, which would cause a problem if they did not take place. But that seems
wrong to me - shouldn't UID MOVE cause * N EXPUNGE to be sent for each message
that was actually moved?
I assumed that this was a bug in the example and was going to report it as some
point. I think the EXPUNGE/VANISHED replies should be sent in any case, even if
MOVE was required to be fully atomic. Otherwise if the UID MOVE command sends
an untagged FETCH/EXPUNGE reply it wouldn't be obvious if the sequence number
referred to the state before or after the MOVE expunges.
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
