MBOX-Line: From bill.shannon at sun.com  Tue Sep 12 14:10:06 2006
To: imap-protocol@u.washington.edu
From: Bill Shannon <bill.shannon@sun.com>
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: <4507222E.7050706@sun.com>

Lyndon Nerenberg wrote:
>> 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.

Exactly, "good" is a value judgement, which makes it harder to define.

The spec should be very clear on what "correct" behavior is.

> 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.

Neither the spec nor the test suite need to be perfect to deliver great
value.  I see a lot of basic functionality that's broken.  A test suite
that tested those cases would make a huge difference.  Specifying, and
testing, the esoteric corner cases can be done later.

