62 lines
3.0 KiB
Plaintext
62 lines
3.0 KiB
Plaintext
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.
|
|
|