we do need to think whether we're creating a compatibility issue with
deployed systems.
For instance, if we can't tell whether a client will break on MOVE if
we send EXPUNGEs or not, we'd need to basically stop advertising MOVE
which completely defeats the purpose.
Also. Even though we have to send EXPUNGEs to any other connected
client on that mailbox (that didn't do the move), the approach is a bit
wasteful of bandwidth etc.
If you issue a command, you want to know when it's done and how it
turned out. If the MOVE completes in its entirety without issue
(99.99% of the time), then a simple "yeah it worked" response is the
most efficient. We can inform of exceptions, e.g. "something broke",
or "these messages didn't work". In the end, if there's a failure so
what if the client has to resynch indices.
But loading the protocol success scenario with major bloat is just that
- bloat.
the client said "move these messages". If the server says "I did it",
the client can safely act as if the server did it, and remove from
local. EXPUNGE responses are completely redundant.
Adrien
----
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/
------ Original Message ------
From: "Arnt Gulbrandsen" <[email protected]>
To: "[email protected]" <[email protected]>
Sent: 1/06/2012 12:12:21 a.m.
Subject: Re: [imap5] Should unsolicited EXPUNGE responses be returned
during UID MOVE?
On 05/30/2012 07:20 PM, Cyrus Daboo wrote:
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?
My FUBAR. I'll correct and repost.
(My code might actually send EXPUNGE a few instants later. I think
that's okay, so long as both server and client change their MSN maps
in sync.)
Arnt
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
_______________________________________________
imap5 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imap5
