MBOX-Line: From MRC at CAC.Washington.EDU  Mon Oct 29 16:34:29 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: <47266943.2010409@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>
Message-ID: <alpine.WNT.0.9999.0710291616560.3152@Tomobiki-Cho.CAC.Washignton.EDU>

On Mon, 29 Oct 2007, Tim Showalter wrote:
> I withdraw the comment.  (I made it based on something I read on this list 
> some number of years ago, and I've never read the IMAP3 document. Good thing, 
> too. :-) )

It's instructive to read the IMAP3 document (RFC 1203), if only to see a 
dead-end branch in IMAP's evolution.

RFC 1176 was a very minor update from RFC 1064, basically adding the FIND 
command (a nascent form of LIST).  Much of RFC 1203 is a strong reaction 
against the IMAP architecture (complete with a diatribe to the effect that 
IMAP will die unless IMAP3 is adopted), especially the unsolicited data 
model (e.g., it tags FETCH responses).

As far as I know, no IMAP3 implementations were ever written.

> What's the real difference between having strictly-increasing client 
> capabilities, or revising the base spec?  In both cases, we're bundling some 
> arbitrary set of protocol changes and requiring client/server support for all 
> of them.

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!

> Thinking about this a little more, I think there's an argument to be made for 
> limiting capabilities and trying to decrease the number of different 
> available capability sets, but we probably also need some amount of forking 
> near the cutting-edge of protocol.

I agree completely!

> But if UTF8 is the first one, and it's successful and widely adopted, 
> whatever the next wave is, should require UTF8.

I think that upgrading IMAP for UTF-8 is essential, and was foreseen with 
the publication of RFC 2060.

> But I'm very concerned about the complexity here.  It's apparently hard to 
> implement correct IMAP clients and servers now.

I agree completely!

> I'm not at all convinced of the wisdom of any of these approaches, but I am 
> enjoying the discussion.

I think that we are all groping towards something that will address the 
problem without causing the Law of Unintended Consequences to come down 
hard upon us... ;-)

-- Mark --

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

