MBOX-Line: From mrc at CAC.Washington.EDU  Tue Oct 30 08:56:04 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: <1040.1193739773.286509@peirce.dave.cridland.net>
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>
	<D24F4660-40CA-4114-8E3A-A74CFA9CECAB@apple.com>
	<alpine.WNT.0.9999.0710291546390.3152@Tomobiki-Cho.CAC.Washignton.EDU>
	<1040.1193739773.286509@peirce.dave.cridland.net>
Message-ID: <alpine.OSX.0.9999.0710300841340.13875@pangtzu.panda.com>

On Tue, 30 Oct 2007, Dave Cridland wrote:
>> 		IMAP internationalization
>> 		UTF-8 mailbox names
>> 		UTF-8 flag names
> I can agree with this list. However, this is, oddly, the list were we've made 
> least progress. IMHO, two of these are almost completely unaddressed.

Yes; and part of the reason why I feel that IMAPEXT has been wasting its 
time.

> I would add NAMESPACE here,

I believe that namespaces were a mistake.  They are invariably 
misimplemented; most clients treat them as a level of filesystem 
hierarchy.

The role of identifying other-user and/or shared mailboxes should be 
performed by a different mechanism.

> and remove MULTIAPPEND. I'm not convinced of the 
> utility of MULTIAPPEND - my client supports it, but I've found I never use 
> it. It's great if you're wanting to move large numbers of messages between 
> servers on very high latency links, but why would you want to do this?

MULTIAPPEND is crucial when transferring mailboxes from one server to 
another.  Otherwise you have to use a non-IMAP mechanism to do it 
properly.

Multiple appends using LITERAL+ have the same number of RTTs, but do not 
guarantee atomicity or full-success/full-failure.  And, for certain bulk 
applications, MULTIAPPEND plus LITERAL+ work together.

MULTIAPPEND should be part of the base definition of APPEND, especially if 
CATENATE becomes part of the base specification.

> BINARY isn't particularly low-hanging - decoding on FETCH is easy, but 
> handling BINARY APPEND is not.

Agreed.  These should have been two separate mechanisms.

> I've found SORT and THREAD most often implemented in web-based clients (in 
> particular THREAD), rather than desktop clients. The problem is that either 
> the desktop client runs with a complete cache, so it can do it itself (and 
> often in rather more complete ways than the extension provides), or else it's 
> running online, typically in low bandwidth, and neither extension scales 
> terribly well.

Nonsense.  Pine/Alpine is an online client that uses SORT/THREAD with 5 
and even 6 digit mailboxes with HUGE success.  I use Alpine all the time 
over EDGE and wouldn't think of threading without it.

>> rfc4551.txt	CONDSTORE
> I don't think this one is going away. This and QRESYNC are surprisingly well 
> implemented, given their complexity. I already know of one wholly independent 
> client implementation of QRESYNC, and it's seen by the author as critical.

I know that Isode considers this to be important.  I'm less certain about 
the wider market.

> LIST extensions are a mere cleanup for LIST/LSUB, so I'd move them up - in 
> fact, I'd say we should use these as the basis for UTF-8 conversion, and 
> deprecate the unextended LIST/LSUB.

I'm afraid that I disagree here.  I would deprecate LSUB (and the entire 
subscription facility) and stay with the simpler LIST.  LIST extensions 
added too many "nice to have" but not strictly necessary facilities, and 
thus is doomed IMHO.

> You're getting perilously close to the suggestion that we've now invented 
> everything that can possibly be useful. I think there's lots more to be done, 
> and I'm not even sure of the sphere of that work.

No, I think that IMAP is "mature".  The future useful work will be in 
whatever replaces IMAP.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

