MBOX-Line: From mrc at CAC.Washington.EDU  Tue Oct 30 08:41: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.1193739761.374080@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>
	<47266943.2010409@psaux.com>
	<alpine.WNT.0.9999.0710291616560.3152@Tomobiki-Cho.CAC.Washignton.EDU>
	<1040.1193739761.374080@peirce.dave.cridland.net>
Message-ID: <alpine.OSX.0.9999.0710300836110.13875@pangtzu.panda.com>

On Tue, 30 Oct 2007, Dave Cridland wrote:
> I think that tagged intermediate responses can be useful, as it happens, but 
> not for FETCH - this does, as you say, break the data model. They'd have been 
> useful for SEARCH, SORT and THREAD, though.

Yes; but only with a server that allows multiple of these in progress at a 
time, and not as a tagged response (ESEARCH has the right idea).

>> I think that upgrading IMAP for UTF-8 is essential, and was foreseen with 
>> the publication of RFC 2060.
> Mostly foreseen - certainly the lack of any encoding for keywords has bitten 
> us. Otherwise, we have a relatively clear upgrade path, and EAI has taken 
> advantage of some of this.

It is true that I never considered encoding for keywords; and of course 
allowing does raise all the ambiguity issues brought about by Unicode. 
However, done properly it shouldn't raise security issues.

> I don't think it's hard to implement a client correctly; although I do think 
> it'd hard to take full advantage of the protocol. But this is largely a 
> result of the lack of design documentation in the later IMAP specifications. 
> Reading the earlier ones, whilst they're not as polished as the later 
> specifications, was very useful to me. (In particular, the unsolicited data 
> model is not adequately explained in RFC3501, but is better explained in 
> RFC1176 and RFC1064 - the fourth paragraph of RFC1064's "The Protocol" 
> section ought to be required reading.).

You can thank RFC 1203 for that.  I took incredible abuse at that time 
for explaining the unsolicited data mode.  Deleting that text was the best 
way to move forward.

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

