Re: [Extra] IMAP I18NLEVEL

["Chris Newman" <[e-mail]>]

On 28 Jan 2019, at 18:30, John Levine wrote:
> In article <[e-mail]> you 
> write:
>> Some of us at FastMail have been discussing implementing RFC 5255,
>> namely the I18NLEVEL extensions, in the Cyrus IMAP server and we are
>> wondering if any clients support and use them.
>
> Why 5255 rather than RFC 6855?  It is my impression that in practice
> the UTF8 support in 6855 made the older stuff obsolete.
>
> Since Chris Newman was an author of both, he's the obvious person to
> ask for more info.

The two standards are orthogonal.

I have most of an implementation of RFC 5255 on our server, but don't 
advertise it. The issue is we implemented an earlier draft of the 
specification which used a UCA-based comparator. I don't have time to 
implement/test i;unicode-casemap and consider that algorithm inferior to 
UCA. I'd be inclined to fix and advertise our implementation if a 
UCA-based comparator was registered and allowed as an alternative to 
i;unicode-casemap. But use of i;unicode-casemap was easier to get 
published at the time this was done. This could probably be fixed with a 
relatively short specification but I can't justify the time to write it. 
In the meantime; I'd recommend using JMAP for i18n sort since it gets 
that detail right :-)

I have a full implementation of RFC 6855 although I ignored one or two 
of the backwards compatibility MUST/SHOULD rules which were necessary 
from a standards viewpoint and inappropriate from an implementer 
viewpoint :-).

Basically RFC 5255 handles sorting and error text localization -- a nice 
to have feature but default behavior in IMAP is good enough. RFC 6855 
handles UTF-8 email headers and mailbox names -- as EAI deploys, you'll 
start getting customer complaints if you don't implement this. So given 
limited time, I'd recommend doing RFC 6855 first.

		- Chris