MBOX-Line: From slusarz at curecanti.org  Mon May 23 22:30:28 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: <1305918054.10421.369.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>
	<20110520121957.Horde.chpUaIF5lbhN1rDN6FN3DTA@bigworm.curecanti.org>
	<1305918054.10421.369.camel@hurina>
Message-ID: <20110523233028.Horde.kOMWSIF5lbhN20J0y8-UYEA@bigworm.curecanti.org>

Quoting Timo Sirainen <tss@iki.fi>:

> On Fri, 2011-05-20 at 12:19 -0600, Michael M Slusarz wrote:
>
>> 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.
>
> ASTRING means atom or string. So what you're really saying is that atoms
> should be treated as old keywords, while strings should be treated as
> new keywords. I think many IMAP parsers hide that distinction, and such
> distinction isn't all that clear to humans either. If you want to keep
> them separated, '#' or similar rarely used prefix would work basically
> the same.

I am really against the idea of using something like '#' as a prefix,  
simply because, however rare it may be, it is still part of a valid  
keyword that might already be used by somebody, somewhere.  Example:  
'#1todolist'.

What about declaring as a system flag instead?  In other words, define  
'\#' as the prefix for all labels: "\#Foo Bar".  This would be  
guaranteed not to conflict with any existing keyword (or flag).  I  
realize that the original RFC 3501 spec didn't really intend for  
system flags to be used as a pseudo-namespace for a whole series of  
user defined keywords... but then again, the 3501 spec didn't allow  
for non-atoms in keywords either, which is the whole reason we are  
having this discussion in the first place.

I wouldn't think that parsing as a system flag (\#) vs. a keyword (#)  
would be any different  - both require scanning the prefix.  The only  
place where there might be a bit of problems is server-side: namely,  
if the code branches based on whether a flag is system or not.  But  
that doesn't seem like anything that would not be able to be worked  
around.

>> 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 \*)]
>> [...]
>
> This would get solved automatically if there was no keyword/label
> separation:
>
> * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft "#Foo  
> 1" "#Bar 2" {9}
> #? label \*)]
>
> Not having an explicit keyword/label separation would make this easy for
> servers to implement it (and clients too, I'd think!). All I'd have to
> do is remove some restrictions and add a bit of code to show a keyword
> only if it's a valid atom or if utf8-keywords is ENABLEd.

I would agree that if we had a namespace that provides non-conflicting  
label names from keywords, that using just PERMANENTFLAGS would be  
acceptable.

michael


