Re: UTF8 case insensitive matching

[Stig Venås <venaas@alfa.itea.ntnu.no>]

I've finally finished some of this, this is only 3 months ago...

On Wed, Oct 25, 2000 at 10:41:57AM -0700, Kurt D. Zeilenga wrote:
> At 07:07 PM 10/25/00 +0200, Stig Venås wrote:
> >On Wed, Oct 25, 2000 at 08:32:57AM -0700, Kurt D. Zeilenga wrote:
> >> Long term, we need to use the dnValidate()/dnNormalizer()
> >> semantics instead of the dn_validate()/dn_normalize() semantics.  
> >
> >Right.
> 
> Good.  This means we both agree architecturally.  I'm actually quite
> happy with any incremental solution towards this end.  I'm primarily
> laying out some options.
> 
> >> In the mid term, to avoid the ripple effect of the
> >> dn_validate()/dn_normalize() change, I suggest that temporary
> >> versions of dn_validate()/dn_normalize() be implemented which
> >> use dnValidate()/dnNormalize() to do the work but provide old
> >> semantics otherwise.
> >
> >I don't get this. dnValidate() and dnNormalize() use dn_validate()/
> >dn_normalize() today.
> 
> In the mid term, we'd reverse the dependency.  dn_validate would
> call dnValidate (to validate) and dnNormalize just to compare
> lengths.  If length of normalized DN is too bug, the DN would
> be treated as invalid.

I've written a new dnNormalize() that works like the old, except that
it does Unicode normalization and case folding also. Are there cases
where dnNormalize() should not do this? As discussed the long term
solution is to use dnNormalize() instead of dn_normalize() right?
Then I think it must do this.

I've also written a new dn_normalize() that uses dnNormalize() and if
the normalized string fits inside the old, this is returned from
dn_normalize. If dnNormalize() fails or returns a larger string,
dn_normalize() returns NULL like it did if dn_validate() failed.

Does this sound about right? dnNormalize() is static, I've changed
that so that dn_normalize() can use it.

If this sounds fine, I'll commit the changes so that you can have a
look at it.

Stig