[Date Prev][Date Next]
Re: commit: ldap/servers/slapd schema_init.c
At 07:53 AM 2001-12-05, Pierangelo Masarati wrote:
>> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd
>> Modified Files:
>> schema_init.c 1.160 -> 1.161
>> Log Message:
>> a gross attempt to implement a schema-aware normalization
>to use this code you need to change the #if 0 at line 264
>in #if 1 and remove the ldap_pvt_str2upper at line 257 of
>I have a few doubts:
>1) what is the normalization function in the Syntax
>structure for? I guess we mean a different type of
>normalization when we talk about "normalizing a dn",
>because all the *Normalize functions in schema_init.c
>do not care about uppercasing case-insensitive strings
>and so; they mostly care about trimming extra space.
Well, traditionally, "normalizing a DN" meant calling
dn_normalize(). This "normalized" the string representation
of the DN so that compared using strcmp().
In the new data model, dnNormalize puts the value in some
normalized form suitable for matching functions it cooperates
with, dnMatch in this case.
In the data model, a syntax normalizer is not actually
needed. It is an optimization. That is, it does portions
matching specific normalization "early" so that the matching
function need not repeated do them.
One could eliminate dnNormalize, this would require dnMatch
to repeated to the necessarily normalization for matching.
>2) shouldn't we change the attribute type into
>its canonical name?
Yes. Otherwise dnMatch would have to this repeatedly.
>3) there's still need to sort the AVAs inside a RDN
Yes. Otherwise dnMatch would have to sort them repeatedly.
>4) we need to decide how to deal with string
>representations of attributes that are not reversible
>into X.501, as per 5.2. of draft-ietf-ldapbis-dn-XX.txt;
>here I really have no clue.
Simple, our implementation only supports CHOICE UniversalString.
We'll be liberal and accept other CHOICEs, transcoding as needed,
but only send out CHOICE UniversalString.