MBOX-Line: From brong at fastmail.fm  Tue Nov  1 09:51:59 2011
To: imap-protocol@u.washington.edu
From: Bron Gondwana <brong@fastmail.fm>
Date: Fri Jun  8 12:34:47 2018
Subject: [Imap-protocol] Cyrus and RFC5255
In-Reply-To: <alpine.OSX.2.00.1111010850250.9034@hsinghsing.panda.com>
References: <alpine.OSX.2.00.1110301823210.9034@hsinghsing.panda.com>
	<CABa8R6uyrHJ6AqQoGfMcLztG-zovaVK4FEFep8ibpYc2-6b7ig@mail.gmail.com>
	<alpine.OSX.2.00.1110311352000.9034@hsinghsing.panda.com>
	<CABa8R6ugaAADsrvaS1Nnau5bi7k9728b+x00NcG1Nbxfk9xwsA@mail.gmail.com>
	<75E51A44-91E4-48D1-BA82-789C82583ABC@iki.fi>
	<alpine.OSX.2.00.1110311532190.9034@hsinghsing.panda.com>
	<1320102709.31835.140660992941501@webmail.messagingengine.com>
	<alpine.OSX.2.00.1110311633050.9034@hsinghsing.panda.com>
	<1320148200.20407.140660993144221@webmail.messagingengine.com>
	<alpine.OSX.2.00.1111010850250.9034@hsinghsing.panda.com>
Message-ID: <20111101165159.GA22321@brong.net>

On Tue, Nov 01, 2011 at 09:33:40AM -0700, Mark Crispin wrote:
> On Tue, 1 Nov 2011, Bron Gondwana wrote:
> >>RFC 5255 explicitly requires that you apply i;unicode-casemap in searches
> >>as part of level 1 compliance.
> >The response when I mentioned it to our project manager was "it's often nice
> >not to worry about a vs ? when searching - and have it find both".
> 
> Careful.

yeah, whatever.  Basically, this is a "implement something that behaves
the same as what was there before".  I'll throw a bunch of test cases at
the two sets of code and make sure they work the same.

> It also formalized, and moderately amended, what Cyrus has done from its
> inception in searching Unicode strings.

No - Cyrus had this:

https://github.com/brong/cyrus-imapd/commit/d988fd9f1fc9a3ca4a0f453e188f2821e050af33#diff-1

(still does actually, that's my rfc5051 branch, which isn't integrated
to mainline)

That's what I'm trying to maintain compatibility with, so users don't
see any difference on existing installs.

> If you want to get into the type of matching you are talking about, you
> will wind up needing to do a full-fledged implementation of i18n collation
> and comparison, which more likely that not includes locale sensitivity.
> This is not something to be half-assed or hackish on. There are standards
> and rules; and in some cases these are enforced in national laws.

I would love to do that - but one thing at a time.

> I strongly urge you, BEFORE embarking upon such a project, to get involved
> with the various groups involved with i18n collation and comparison and
> seek their advice.

Definitely.  It might not even be me doing this.  I just want to make
sure that the design leaves the possibility open.

Bron.

