MBOX-Line: From MRC at CAC.Washington.EDU  Mon Oct 29 19:00:52 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <MRC@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:40 2018
Subject: [Imap-protocol] re: GMail
In-Reply-To: <4726888C.6010409@psaux.com>
References: <alpine.WNT.0.9999.0710241938220.520@Shimo-Tomobiki.Panda.COM>
	<fc2c80ae0710270911o23f0b366g942b2956ac3fa@mail.gmail.com>
	<alpine.WNT.0.9999.0710270924180.4788@Shimo-Tomobiki.Panda.COM>
	<5202.1193523708.069559@peirce.dave.cridland.net> 
	<alpine.OSX.0.9999.0710271708460.11181@pangtzu.panda.com>
	<1193531029.25921.561.camel@hurina>
	<alpine.WNT.0.9999.0710271748490.204456@Ningyo-no-Mori.Panda.COM>
	<RMRLrFbL0dA92HCVkk6Cgw.md5@libertango.oryx.com>
	<alpine.OSX.0.9999.0710280923190.11181@pangtzu.panda.com>
	<d1klUHoFkFbXOtQmbn1Bww.md5@libertango.oryx.com>
	<47263322.7040702@psaux.com> <1193689139.25921.618.camel@hurina>
	<472653EE.9080102@psaux.com>
	<alpine.WNT.0.9999.0710291450130.3152@Tomobiki-Cho.CAC.Washignton.EDU>
	<47266943.2010409@psaux.com>
	<alpine.WNT.0.9999.0710291616560.3152@Tomobiki-Cho.CAC.Washignton.EDU>
	<4726888C.6010409@psaux.com>
Message-ID: <alpine.WNT.0.9999.0710291854400.3152@Tomobiki-Cho.CAC.Washignton.EDU>

On Mon, 29 Oct 2007, Tim Showalter wrote:
>> I think that there is much more opposition to adding to a base 
>> specification than to a service level.  A new base specification purported 
>> kills the previous one; whereas a service level might get ignored at a 
>> particular point.
>> Sometimes how you call things does matter!
> Well, I think that's true, but it's clear that base specifications get 
> ignored, too.

Sigh, only too true!

> I don't have a feel for which is the easier path, but I am fearful of the 
> work involved in IMAP5, because I think it will bring out the trolls.

That is my fear too; but trolls are possible with service levels too. 
From the very earliest days of IMAP, the "IMAP will die unless IMAP adopts 
my favorite functionality" argument has been made.

> If we were to add a single client-side capability, we could provide a general 
> mechanism.  I think it's desirable if we encourage client capabilities to be 
> bundled, but I think requiring it is a mistake.
> I don't believe IMAP5 would provide this flexibility.

The idea with IMAP5 was NOT to have any client-side capabilities, but 
allow breaking assumptions of the past.

I think that the path of client-side capabilities leads to madness.

-- Mark --

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

