MBOX-Line: From MRC at CAC.Washington.EDU  Tue Sep 12 14:25:59 2006
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:37 2018
Subject: [Imap-protocol] reporting/detecting expunged messages
In-Reply-To: <20060912134901.F80085@orthanc.ca>
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> <20060912134217.X80085@orthanc.ca>
	<45071C8E.4010909@sun.com> <20060912134901.F80085@orthanc.ca>
Message-ID: <Pine.WNT.4.65.0609121413020.2164@Tomobiki-Cho.CAC.Washington.EDU>

On Tue, 12 Sep 2006, Lyndon Nerenberg wrote:
> I'd start with defining "good."  The problem with a protocol as complex (some 
> would say bloated) as IMAP is that -- from the client's perspective -- there 
> is no one "right" way to use it.

I would disagree... ;-)

RFC 1064 and 1176 had some text outlining the right way to go about 
looking at the roles of client and server in IMAP.  But I took so much 
criticism about how I did not "understand" the architecture of IMAP(!) 
that I removed that text in RFC 1730.  [The critics in question are no 
longer active members of the IMAP community.]

Briefly:

There is a mailbox "state", of which the server has full knowledge.  The 
server has the ability, at will, to update and add to the client's state. 
The client can also request the server to send updates/additions, and the 
server sends back a done response when it has finished doing so.

Once the client establishes a session with a mailbox on the server, the 
server immediately starts sending some updates (e.g., EXISTS).  The 
client, on an as-needed basis, references data from its state and when a 
hole is encountered requests a state addition from the server.  The client 
may also request state additions on an anticipatory basis.  Think of how 
page fault handling works in a demand-paged system.

In the online model, a client starts with empty state.  In the 
disconnected model, the client has some remembered state and has to 
synchronize that remembered state with the server's state.


Anyway, most clients don't do all this.  They just download-and-delete 
(pure offline model POP-style).  A few are online, but don't keep a state 
so they are constantly re-FETCHing the same static data.

> Different client implementations have 
> different goals, and thus different demands of the server.  In some cases it 
> makes sense for the client to (say) talk to the server using a restricted 
> feature set that, when examined without context, makes it look like the 
> client is just a glorified POP engine.

True.  However, even such clients can still implement the underlying IMAP 
architecture properly.  I have to wonder when I see clients that 
repeatedly re-fetch the same static data in a single session.

> And if you do ever manage to define "good" you then get to solve the problem 
> of determining what constitutes "compliant" behaviour when faced with the n! 
> permutations of extensions interacting with and without each other.
> This isn't going to happen in my lifetime.

Sadly, all true.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

