79 lines
3.4 KiB
Plaintext
79 lines
3.4 KiB
Plaintext
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
|
|
|