FW: National characters isn't case insensitive searchable (ITS#1584)

["Howard Chu" <hyc@highlandsun.com>]

I suppose it's a moot point now, but if our DN normalizer always stripped
accents and such, then the new DN would never be longer than the original.

Besides the obvious simplifications we could do for Latin-based alphabets,
is there anything else we should be thinking about?

It was quite educational reading through all the Unicode documents about the
various normalization forms, but I don't think any of those 4 forms are of
any interest to us for Latin alphabets, where all we want is a useful
ordering mechanism. Things like the distinction between German 'ß' and "SS"
could be
simply ignored for sorting and indexing purposes.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

-----Original Message-----
From: owner-openldap-bugs@OpenLDAP.org
[mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
claude.lecommandeur@epfl.ch
Sent: Monday, February 11, 2002 12:44 AM
To: openldap-its@OpenLDAP.org
Subject: Re: National characters isn't case insensitive searchable
(ITS#1584)



   Hello,

   On the same subject, when searching openldap, it doesn't match
accentuated
characters with the same character without accent. i.e. 'stephane' doesn't
match 'stéphane'. This is really a problem for us french, I had to duplicate
all accentuated attributes values with the no-accent version.

   Is there a more elegant solution for this ?


     Claude.

Kurt@OpenLDAP.org wrote:
>
> OpenLDAP 2.0 doesn't know how to case fold codepoints above U+0007F.
> 2.1 will.
>
> Kurt
>

--
Claude Lecommandeur           Claude.Lecommandeur@Epfl.Ch
EPFL - SIC                    +41 21 693 22 97
1015 Lausanne (Switzerland)   http://slwww.epfl.ch/SIC/SL/info/Claude.html

sh: fortune:  not found.