35 lines
1.5 KiB
Plaintext
35 lines
1.5 KiB
Plaintext
MBOX-Line: From lyndon at orthanc.ca Tue Sep 12 13:55:57 2006
|
|
To: imap-protocol@u.washington.edu
|
|
From: Lyndon Nerenberg <lyndon@orthanc.ca>
|
|
Date: Fri Jun 8 12:34:37 2018
|
|
Subject: [Imap-protocol] reporting/detecting expunged messages
|
|
In-Reply-To: <45071C8E.4010909@sun.com>
|
|
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>
|
|
Message-ID: <20060912134901.F80085@orthanc.ca>
|
|
|
|
> It's the difference between "good" and "correct". I'd start with
|
|
> "correct" and work up to "good".
|
|
|
|
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. 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.
|
|
|
|
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.
|
|
|
|
--lyndon
|
|
|