MBOX-Line: From blong at google.com  Wed May 18 10:42:56 2011
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Thoughts on keyword improvements/enhancements
In-Reply-To: <20110518011645.Horde.6sTkboF5lbhN03Jd3XNndCA@bigworm.curecanti.org>
References: <20110518011645.Horde.6sTkboF5lbhN03Jd3XNndCA@bigworm.curecanti.org>
Message-ID: <BANLkTikVbKdXg01nnajJ-=XLNfTpjjjG0Q@mail.gmail.com>

On Wed, May 18, 2011 at 12:16 AM, Michael M Slusarz
<slusarz@curecanti.org> wrote:
> Hi all,
>
> First time poster. ?Quick background: I am the primary author of IMP
> (http://www.horde.org/imp/) and the related Horde IMAP client library. ?Had
> a discussion a few weeks back with Timo on the dovecot list about some
> keyword issues, and he suggested I raise the topics on this list.
>
> That topic is handling of keywords. ?More specifically, it can be broken
> down into several parts (apologizes if I make the following discussion too
> basic - just want to make sure I am on the same page):
>
> 1. Allowing non-ASCII characters in keywords

Note this is one of the main reasons we didn't map our labels to
keywords in the Gmail IMAP implementation.  That, and the majority of
clients don't really expose keywords to the user in any real fashion.

We do store keywords as labels which aren't visible in our web
interface, mostly because IMAP clients rarely used keywords to store
anything particularly user visible.

<snip>

> 3. New commands/response codes
> Pros: Works with old RFC 3501 servers. ?Would be able to handle issue of one
> keyword meaning the same thing across all mailboxes.
> Cons: As with all extensions, adds complexity and more commands to implement
> on the client side.

And this was our eventual solution.  We don't expect clients to
implement our extensions for this, but since IMAP has become the
defacto Gmail API, it became necessary to expose some Gmail specific
data over IMAP for non-traditional applications.

http://code.google.com/apis/gmail/imap/#x-gm-labels

So, we added X-GM-LABELS which is analogous to FLAGS and can be used
in SEARCH/FETCH/STORE in a similar way, and uses UTF7 ASTRINGs as
arguments.

Obviously, this isn't backward compatible at all, but I may argue that
if the end-goal is to have real user-visible labels, then the current
keywords namespace is probably too cluttered to be able to actually
share keywords across clients.  That could be solved by yet another
prefix, though.

Brandon
-- 
?Brandon Long <blong@google.com>
?Staff Engineer
?Gmail Delivery TLM

