70 lines
3.1 KiB
Plaintext
70 lines
3.1 KiB
Plaintext
MBOX-Line: From tjs at psaux.com Mon Oct 29 16:14:11 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Tim Showalter <tjs@psaux.com>
|
|
Date: Fri Jun 8 12:34:40 2018
|
|
Subject: [Imap-protocol] re: GMail
|
|
In-Reply-To: <alpine.WNT.0.9999.0710291450130.3152@Tomobiki-Cho.CAC.Washignton.EDU>
|
|
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>
|
|
Message-ID: <47266943.2010409@psaux.com>
|
|
|
|
Mark Crispin wrote:
|
|
>> IMAP lore says this is what killed IMAP 3.
|
|
>
|
|
> There was quite a bit that killed IMAP3; a total misunderstanding the
|
|
> unsolicited data model of IMAP, an incorrect understanding of how to
|
|
> handle MIME, and some truly silly facilities like SET.EOL.
|
|
>
|
|
> Then there are such obtuse statements as "this allows the client not to
|
|
> have to block on some complex predicate that involves watching to see an
|
|
> update in a cache cell" which make no sense until you you realize that
|
|
> it refers to one particular client written in Common Lisp.
|
|
|
|
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. :-) )
|
|
|
|
>> I'm not opposed to client-side capabilities, as I think we need a way
|
|
>> to get rid of some of the cruft of the protocol eventually. But I do
|
|
>> think we ought to be able to specify a strict, increasing order for
|
|
>> such extensions.
|
|
|
|
> Perhaps we should just punt doing the right thing to IMAP5, and add
|
|
> UTF8.FLAGS as a FETCH command and UTF8.LIST/UTF8.LSUB as basic commands
|
|
> (with perhaps something for LISTEXT if you like...but I don't want a
|
|
> dependency on LISTEXT).
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
But if UTF8 is the first one, and it's successful and widely adopted,
|
|
whatever the next wave is, should require UTF8.
|
|
|
|
But I'm very concerned about the complexity here. It's apparently hard
|
|
to implement correct IMAP clients and servers now.
|
|
|
|
I'm not at all convinced of the wisdom of any of these approaches, but I
|
|
am enjoying the discussion.
|
|
|
|
Tim
|
|
|