MBOX-Line: From tss at iki.fi  Wed May 18 01:52:27 2011
To: imap-protocol@u.washington.edu
From: Timo Sirainen <tss@iki.fi>
Date: Fri Jun  8 12:34:45 2018
Subject: [Imap-protocol] Thoughts on keyword improvements/enhancements
In-Reply-To: <20110518100807.29d4b72c@arbre.eng.oslo.osa>
References: <20110518011645.Horde.6sTkboF5lbhN03Jd3XNndCA@bigworm.curecanti.org>
	<20110518100807.29d4b72c@arbre.eng.oslo.osa>
Message-ID: <FEDA906E-72BF-445E-998C-8774B7D15770@iki.fi>

On 18.5.2011, at 11.08, Bron Gondwana wrote:

> On Wed, 18 May 2011 01:16:45 -0600
> Michael M Slusarz <slusarz@curecanti.org> wrote:
> 
> (Terminology: keyword, label, flag - joy)
> 
>> 1. Implement UTF7-IMAP (or similar) storage of keywords.
>> Pros: Would allow keyword & label information to be kept in a single  
>> location; all MUAs should be able to easily adapt since they should  
>> already have code necessary to do UTF7-IMAP conversions
>> Cons: Haven't thought about it fully, but doesn't seem like it could  
>> be made to be backward compatible with RFC 3501 keywords.  Doesn't  
>> solve problem of having one keyword meaning the same thing across all  
>> mailboxes.
> 
> Lack of backwards compatibility kills this one out the gate.  You can't
> break existing clients and servers.

I think this is the only way to make it completely backwards compatible with both clients and servers. mUTF7 wouldn't work because keywords are case-insensitive, but something else would, as long as servers allow long enough keywords. The encoded keywords could begin with some yet another prefix character, such as #. And it could be required that it's used only when non-atom-chars are in the name. So it would be possible to set, for example:

 - $Spam
 - Spam
 - Work
 - #121h5jh125jh12fjs2

Or possibly assume that # (or something else) is so rarely used, that the whole keyword wouldn't have to be encoded:

 - Tax#20Forms#20#282011#29

That would still be readable with old clients that show keywords as-is, and wouldn't require anything special from server side.
