Re: [imap5] Should unsolicited EXPUNGE responses be returned during UID MOVE?

It's doable of course, but I don't think it's worth the extra complexity for 1) the protocol specs and 2) client implementations. The bandwidth savings are pretty minimal.

On 31.5.2012, at 0.11, Adrien W. de Croy wrote:

> 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" <tss@iki.fi>
> To: "Cyrus Daboo" <cyrus@daboo.name>
> Cc: "Discussion on drastically slimming-down IMAP." <imap5@ietf.org>
> 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
>> imap5@ietf.org
>> https://www.ietf.org/mailman/listinfo/imap5
>> 
>> 
> 
> _______________________________________________
> imap5 mailing list
> imap5@ietf.org
> https://www.ietf.org/mailman/listinfo/imap5
> 