105 lines
4.7 KiB
Plaintext
105 lines
4.7 KiB
Plaintext
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
|
|
|
|
|