[Imap-protocol] SELECT/EXAMINE clarification of UNSEEN

Dave Cridland dave at cridland.net
Wed Nov 16 12:58:40 PST 2011

On Wed Nov 16 18:58:49 2011, Brandon Long wrote:

> On Wed, Nov 16, 2011 at 12:33 AM, Dave Cridland <dave at cridland.net>

> wrote:

> > On Wed Nov 16 02:24:17 2011, Mark Crispin wrote:

> >>

> >> My understanding is that Google perceived keywords as not

> commonly

> >> implemented, and thus needing to do view/mailbox mapping. It's

> been a

> >> major problem; a classic case of kludge tower building because

> it was

> >> perceived that they couldn't do it right to begin with.

> >

> > I thought this at one point, but I recall seeing somewhere that

> the

> > limitation was that keywords are pure ASCII, compared to mailbox

> names (and

> > Google tags or whatever they're called) which are full unicode,

> contain

> > spaces, etc.


> It was never really considered a viable option, because it wasn't

> technically possible with the standard, and because almost no client

> we looked at had any support for keywords (the most we saw was

> Thunderbird which uses like 6 keywords that mean various things, but

> doesn't even store them in IMAP as anything more than

> keyword1...keyword6, others only used it for things like spam).


> I'm sure there are some clients with better support for keywords,

> but

> they weren't common enough to make a difference in our decision.



Right, and I understand where you're coming from, which is why I
explicitly spelt out the mismatch here.

> > Personally I think Google are big enough that fixing this problem

> "properly"

> > (ie, a more free-text naming of FLAGS via the standards process)

> would have

> > been viable, but the desire of many companies (Google included)

> to assume

> > that marketing splash always trumps technical merit means that a

> kludge they

> > can release without consultation trumps revealing some portion of

> the plan,

> > or releasing incrementally, but with a better design.

> >

> > I do understand the pressure, and sympathize with it, but I still

> find it

> > annoying how little the technical argument counts for, especially

> when it's

> > a standardization issue, and these companies are often too happy

> to talk

> > about how much they support open standards.


> There are two separate things here: supporting the current standard

> and working to extend it.



Absolutely, and they're not in conflict.

> Our goal was supporting the current standard. Our primary

> motivation

> was access from mobile devices, where the IMAP clients are probably

> never going to receive an update. Designing our system to require

> extensive client changes to support us, even if those changes were

> "standard", was not a viable option.



No, you're missing my point.

I'm not saying that Google should have mandated a bunch of private
extensions bulldozered through a mockery of a standards process.

What I am saying is that had you offered a (potentially more basic)
IMAP service, but with an additional, well-designed extension to
handle the extended abilities of your message store, that would have
both enabled access, and in addition pushed the boundaries a bit (in,
I might add, a very sensible direction).

The fact is that if GMail supports something, clients are going to
follow - and demonstrably have done, implementing your quasi-LISTEXT
thing quite widely, I understand.

> Our goal was interoperability, which meant making Gmail look like


> as used by current clients. At the end of the day, the point of our

> service is to let people read their mail using the tools available

> to

> them.

Yes, but I don't see that the goal of providing reasonable service to
existing tools is in conflict with pushing to improve those existing
tools. And because Google is big, you can actually provide sufficient
encouragement to do so.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Imap-protocol mailing list