51 lines
2.3 KiB
Plaintext
51 lines
2.3 KiB
Plaintext
MBOX-Line: From tss at iki.fi Fri May 20 02:23:05 2011
|
|
To: imap-protocol@u.washington.edu
|
|
From: Timo Sirainen <tss@iki.fi>
|
|
Date: Fri Jun 8 12:34:46 2018
|
|
Subject: [Imap-protocol] Thoughts on keyword improvements/enhancements
|
|
In-Reply-To: <20110520002607.Horde.lf1bSoF5lbhN1gl-aoNHDLA@bigworm.curecanti.org>
|
|
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>
|
|
Message-ID: <1305883385.10421.294.camel@hurina>
|
|
|
|
On Fri, 2011-05-20 at 00:26 -0600, Michael M Slusarz wrote:
|
|
|
|
> The downside of this approach is that legacy clients would have
|
|
> unfettered access to these new keywords. Although many clients ignore
|
|
> keywords they are unfamiliar with, other clients don't. We can
|
|
> probably all agree that these clients presenting keywords such as
|
|
> '#666F' (base16 encoding of 'foo') to clients may not be the best of
|
|
> ideas. We would be preserving backward compatibility at the expense
|
|
> of providing a label that means absolutely nothing to a user.
|
|
>
|
|
> However, this limitation could be worked around with use of ENABLE.
|
|
> Thus, these newer keywords/labels would not be visible to legacy
|
|
> servers.
|
|
|
|
You mean legacy clients I guess.
|
|
|
|
> * 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.
|
|
|
|
|
|
|