MBOX-Line: From slusarz at curecanti.org  Fri May 20 11:19:57 2011
To: imap-protocol@u.washington.edu
From: Michael M Slusarz <slusarz@curecanti.org>
Date: Fri Jun  8 12:34:46 2018
Subject: [Imap-protocol] Thoughts on keyword improvements/enhancements
In-Reply-To: <1305883385.10421.294.camel@hurina>
References: <20110518011645.Horde.6sTkboF5lbhN03Jd3XNndCA@bigworm.curecanti.org>
	<BANLkTikVbKdXg01nnajJ-=XLNfTpjjjG0Q@mail.gmail.com>
	<alpine.OSX.2.00.1105181108180.24932@hsinghsing.panda.com>
	<20110518210716.GA12636@brong.net>
	<alpine.OSX.2.00.1105181519330.24932@hsinghsing.panda.com>
	<20110519045851.GA23466@brong.net>
	<alpine.OSX.2.00.1105182203320.24932@hsinghsing.panda.com>
	<20110519220352.GA12141@brong.net>
	<alpine.OSX.2.00.1105191513210.24932@hsinghsing.panda.com>
	<20110520002607.Horde.lf1bSoF5lbhN1gl-aoNHDLA@bigworm.curecanti.org>
	<1305883385.10421.294.camel@hurina>
Message-ID: <20110520121957.Horde.chpUaIF5lbhN1rDN6FN3DTA@bigworm.curecanti.org>

Quoting Timo Sirainen <tss@iki.fi>:

> On Fri, 2011-05-20 at 00:26 -0600, Michael M Slusarz wrote:
>
>> * Option B: Creating a new class of keywords called "Labels"
>
> Is it all that useful to have basically just another set of keywords
> with duplicated list of commands/parameters to manage them?
>
> You could do almost the same thing with using "ENABLE utf8-keywords",
> which changes keywords to be UTF-8 ASTRINGs rather than ATOMs. Clients
> that don't understand those can keep ignoring them. Clients that do, can
> manage them using the same old keyword commands/parameters. And if you
> wanted to separate them from the "old keywords" you could prefix them
> with '#' or something. The only difference to "labels" is that it
> wouldn't be possible to fetch only flags+keywords or only labels, but I
> don't really see why any client would want to do that.

After typing up my message last night, and dwelling a bit on the  
contents, I'm beginning to think this is the better option.  I  
personally am fine with legacy clients not being able to show these  
newer keywords because that is already the status quo for many clients  
(i.e. not displaying keywords they don't recognize).  Once we remove  
the legacy compliance component, then we don't have to rely on any  
kind of funky encoding in order to pack non-atoms in the label.

With this solution, I would disagree however with the user of a '#' or  
other prefix to distinguish "new utf-8 keywords" from "old RFC 3501  
keywords".  I think the assumption should rather be that if a keyword  
is provided in a STORE/APPEND command as an ASTRING, the intent is  
that string is a human readable representation.

E.g., with these series of client commands:

TAG1 ENABLE UTF8-KEYWORDS
[...]
TAG2 STORE 1 +FLAGS foo
[...]
TAG3 STORE 2 +FLAGS "bar"

Here, TAG 2 is taken to be a regular 3501 keyword.  It is not  
necessarily intended to be the label for that message.  A client is  
free to do keyword -> label translation on this value, and can choose  
to not display this keyword if it doesn't already know about it.

Conversely, TAG3 is intended to be the full human readable label.  A  
client should not do translation, and SHOULD directly display this  
label to the user.

(Thus, this proposed extension is more than just an ability to provide  
non-atoms in a keyword.  This extension is designed to store full  
human readable labels with a message.  Therefore, this proposed  
extension is more properly identified as something like LABELS instead  
of UTF8-KEYWORDS).

I still believe the list of utf8-keywords/labels in a mailbox should  
be something that is announced by the server.  For example, a LABELS  
untagged response code could be used to provide this information.  E.g.:

TAG1 SELECT INBOX
* OK [LABELS "Foo 1" "Bar 2" {7}
? label
]
* OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)]
[...]

A client can parse these two entries to determine which flags are  
available to ALL clients, and which flags are available only to  
clients that support the new utf8-keyword extension.  This response  
code would allow the client to determine the list of keywords intended  
to act as labels, and therefore ALWAYS be displayed to the user as-is.  
Clients could then continue to hide regular keywords (all non-system  
flags contained in PERMANENTFLAGS) that they have no knowledge of.

In this solution, we would probably need to add a new special flag to  
PERMANENTFLAGS to indicate that all labels can be permanently set  
(\AllLabels) - this would prevent the need of having to repeat all  
labels in PERMANENTFLAGS.  If a certain subset of labels could not be  
set (I could only imagine this to be a rare occurrence), the  
\AllLabels flag would be omitted and the permanent labels would have  
to be enumerated in the PERMANENTFLAGS list.

michael


