MBOX-Line: From arnt at gulbrandsen.priv.no  Fri Sep 15 06:53:36 2006
To: imap-protocol@u.washington.edu
From: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] reporting/detecting expunged messages
In-Reply-To: <Pine.WNT.4.65.0609141841560.1540@Tomobiki-Cho.CAC.Washington.EDU>
References: <4505F2FE.8090807@sun.com>
	<Pine.WNT.4.65.0609111648410.5544@Tomobiki-Cho.CAC.Washington.EDU>
	<450713AB.4090601@sun.com>
	<Pine.WNT.4.65.0609121316280.2164@Tomobiki-Cho.CAC.Washington.EDU>
	<45071A57.5080406@sun.com>
	<9SYO8YZNXU3qj9EYGtuGNg.md5@libertango.oryx.com>
	<Pine.WNT.4.65.0609121437140.2164@Tomobiki-Cho.CAC.Washington.EDU>
	<2xKZXsAOqJTXDcZB/xUw7g.md5@libertango.oryx.com>
	<Pine.WNT.4.65.0609141841560.1540@Tomobiki-Cho.CAC.Washington.EDU>
Message-ID: <LWKbk3lpdVhtHUTm38BDeA.md5@libertango.oryx.com>

Mark Crispin writes:
> On Thu, 14 Sep 2006, Arnt Gulbrandsen wrote:
>> Sure. The average case is OK, what I dislike is the lack of a proper 
>> transaction. Or you could say I don't like the fuzzy semantics of 
>> the EXPUNGE command. When a client issues EXPUNGE and the server 
>> issues a tagged OK, what is the server promising the client?
>
> You are looking at it the wrong way.
>
> Instead of looking at it from the protocol viewpoint, you are looking 
> at it from the viewpoint of how some server implementation may 
> implement it.

I'd say: I'm looking at what the promises made by IMAP standard to 
client authors, which standards-conformant servers must fulfill. In 
particular what promises made about the effects of the EXPUNGE command.

> More importantly, you are betraying an unrealistic expectation of what 
> the IMAP protocol can do: to wit, that an IMAP client can force 
> destruction of a message in other clients.  Doesn't happen.  Can't 
> happen.

Of course it can't.

My issue is rather the opposite - can a client force destruction of a 
message on a server, such that other IMAP clients cannot access the 
message?

Seven hundred other clients may have cached the message already, and 
even logged out. That's a given. Time moves forwards, after all. All 
the EXPUNGE command can affect is the ability of other clients to fetch 
the messages after the time of the EXPUNGE command.

Even though EXPUNGE cannot affect the past, I think its effect on the 
future are worth discussing.

(Btw, I changed our code today to use 4.1.2+loopbreaker. The first time 
a client fetches a message which another client has expunged, but whose 
expunge has not yet been reported in this session, the server issues a 
NO as in 4.1.2, and makes a note of the UID(s). If any of those UIDs 
are fetched again before the server can report the expunge, the server 
issues a BYE. When it reports expunges, it clears its UID set. I think 
that's as good as 4.1.1+period.)

>> IMO,  it depends on the precise text. Requiring that all clients 
>> offer the server an opportunity to send EXPUNGE every so often can't 
>> be all that bad, but how often? "EXPUNGE may not take effect 
>> completely until half an hour after the tagged OK" sounds overly 
>> long to me. "Clients must give the server the opportunity to send 
>> EXPUNGE at two-minute intervals or more often" sounds much too 
>> short. Ten minutes sounds both too short and too long. All partly 
>> subjective of course.
>
> In my opinion, the minimum period should be between 5 and 30 minutes.  
> NAT has pretty much made it non-viable to go idle for more than 5 
> minutes.

Then five minutes.

Arnt

