220 lines
7.9 KiB
Plaintext
220 lines
7.9 KiB
Plaintext
MBOX-Line: From dave at cridland.net Tue Oct 30 03:22:53 2007
|
|
To: imap-protocol@u.washington.edu
|
|
From: Dave Cridland <dave@cridland.net>
|
|
Date: Fri Jun 8 12:34:40 2018
|
|
Subject: [Imap-protocol] re: GMail
|
|
In-Reply-To: <alpine.WNT.0.9999.0710291546390.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>
|
|
<D24F4660-40CA-4114-8E3A-A74CFA9CECAB@apple.com>
|
|
<alpine.WNT.0.9999.0710291546390.3152@Tomobiki-Cho.CAC.Washignton.EDU>
|
|
Message-ID: <1040.1193739773.286509@peirce.dave.cridland.net>
|
|
|
|
On Mon Oct 29 23:16:23 2007, Mark Crispin wrote:
|
|
> On Mon, 29 Oct 2007, Sarah Wilkin wrote:
|
|
>> Is there a single place that summarizes goals of future IMAP
|
|
>> proposals or extensions? I've seen several ideas come up on this
|
|
>> list; are these captured publicly anywhere? I don't see anything
|
|
>> on http://www.imap.org/, and the ietf-imapext list looks a bit too
|
|
>> specific.
|
|
>
|
|
> IMHO, most of the people who've done IMAP over the years would
|
|
> rather curtail further IMAP extensions. IMAP has too many
|
|
> extensions, and although every one has a passionate set of
|
|
> defenders the fact is that most clients and servers implement few
|
|
> (if any) of these. Then there are the servers which misimplement
|
|
> extensions (such as Courier doing so for SORT and THREAD).
|
|
>
|
|
>
|
|
I disagree - but I do think that many people working on and with IMAP
|
|
would rather see more profiles, so that fewer code-paths were
|
|
involved. The problem with so many extensions is not the number of
|
|
extensions per se, but the number of combinations of extensions.
|
|
|
|
> (0) Needed. Now. Should drop everything else to address:
|
|
>
|
|
> 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.
|
|
|
|
|
|
> (1) Should go into any major revision (e.g., IMAP5) of the base
|
|
> specification, either because it is essential or is "low-hanging
|
|
> fruit" that fixes an obvious deficiency:
|
|
>
|
|
> rfc5051.txt i;unicode-casemap comparator
|
|
> rfc2177.txt IDLE
|
|
> rfc3502.txt MULTIAPPEND
|
|
> rfc4959.txt SASL-IR
|
|
> rfc4315.txt UIDPLUS
|
|
>
|
|
>
|
|
I would add NAMESPACE here, 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?
|
|
|
|
|
|
> (2) Nice to have, not strictly necessary, but for the most part
|
|
> low-hanging fruit:
|
|
>
|
|
> rfc3516.txt BINARY
|
|
> rfc3348.txt CHILDREN
|
|
> rfc4731.txt ESEARCH
|
|
> rfc2088.txt LITERAL+
|
|
> rfc3691.txt UNSELECT
|
|
>
|
|
>
|
|
BINARY isn't particularly low-hanging - decoding on FETCH is easy,
|
|
but handling BINARY APPEND is not.
|
|
|
|
|
|
> (3) Nice to have, but sometimes misimplemented, and so may not make
|
|
> the cut:
|
|
>
|
|
> rfc2342.txt NAMESPACE
|
|
> SORT/THREAD (in RFC Editor queue)
|
|
>
|
|
>
|
|
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.
|
|
|
|
|
|
> (4) Ideas that never really got off the ground for various reasons
|
|
> and are likely to fade into obscurity (sorry...):
|
|
>
|
|
> rfc4314.txt ACL
|
|
|
|
We (Isode) implemented a read-only ACL (ie, we never grant the "a"
|
|
right), in order to provide several mainstream clients, including
|
|
Thunderbird, with the "sharing" information which the clients like to
|
|
display to users.
|
|
|
|
FWIW, I know of only two clients which allow read-write access to
|
|
ACLs, and only one that does it properly.
|
|
|
|
|
|
> 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.
|
|
|
|
|
|
> rfc2971.txt ID
|
|
|
|
One of those things that nobody seems likely to implement, on the
|
|
face of it. I'd agree that it'd never make the grade for inclusion
|
|
into a base specification, although Id also note that it's
|
|
implemented quite widely.
|
|
|
|
|
|
> rfc2221.txt LOGIN-REFERRALS
|
|
> rfc2193.txt MAILBOX-REFERRALS
|
|
|
|
Both these are broken in design, and painful to implement. I do the
|
|
latter, and hate it with a passion - most servers which support it
|
|
also support na?ve clients via a proxying mechanism, which is not
|
|
only more efficient, but also far simpler to implement, thus
|
|
penalizing people who've taken the time to do things right, in effect.
|
|
|
|
|
|
> rfc2087.txt QUOTA
|
|
>
|
|
>
|
|
Weird. Alexey and I have repeatedly tried to design something
|
|
equivalent but better, but it is not terribly easy.
|
|
|
|
On of the hardest thigs with QUOTA is the notion of QUOTAROOT - it's
|
|
relatively obvious that it's needed, but it's terribly difficult for
|
|
clients to use. In particular, it's unknown to a client whether -
|
|
when faced with a mailbox that's threatening to be over quota -
|
|
creating a new mailbox elsewhere will still be within the same quota
|
|
or not.
|
|
|
|
Then there's the minor point that none of the quota counters are
|
|
standardized at all.
|
|
|
|
|
|
> (5) May become mandatory if IMAP on mobile devices takes off (as
|
|
> opposed to being killed), otherwise doomed to category (4):
|
|
>
|
|
> rfc4469.txt CATENATE
|
|
> rfc4978.txt COMPRESS
|
|
|
|
Actually, this is a short-term thing. I doubt this will take off, in
|
|
the long term.
|
|
|
|
|
|
> rfc4467.txt URLAUTH
|
|
> convert
|
|
>
|
|
>
|
|
FWIW, none of these have much interest from the client developers I
|
|
talk to. They're much more interested in IDLE/NOTIFY,
|
|
CONDSTORE/QRESYNC, and CONTEXT.
|
|
|
|
|
|
> (6) Much-discussed ideas that I don't see going anywhere (sorry...)
|
|
> but category (4) if they make it to publication:
|
|
>
|
|
> annotations
|
|
> LIST extensions
|
|
>
|
|
>
|
|
Annotations would be great, but I can't see interest from server
|
|
developers, currently. A mechanism for providing highly stable
|
|
addressing of messages would serve almost as well, since then
|
|
annotations could be held within an external server, as well as being
|
|
able to glue things like calendaring in as well.
|
|
|
|
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.
|
|
|
|
|
|
> (7) Everything else bandied about on IMAPEXT, a group that should
|
|
> have dissolved years ago...
|
|
>
|
|
>
|
|
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.
|
|
|
|
I think some of this work may involve message organization (which is
|
|
a big enough sphere in and of itself), some will involve
|
|
reintegration of the plurality of communications methods and support
|
|
we have (BURL/URLAUTH is a step in this direction, as would the
|
|
annotation-like replacement I mention above). There's plenty more to
|
|
be getting on with, I'm sure.
|
|
|
|
Dave.
|
|
--
|
|
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@jabber.org
|
|
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
|
|
- http://dave.cridland.net/
|
|
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
|
|
|