[Date Prev][Date Next]
Re: Heads up: new schema support
John Kristian wrote:
> Julio Sánchez Fernández wrote:
> > ... I'm intrigued about how you solved matching rules like
> > onjectIdentifierFirstComponentMatch
> Is this rule useful, in LDAP? For what purpose?
Good question. It is at best marginal. But it is the equality matching
rule for object class and attribute type definitions. A client might
want to check if some objectclass is known to the server by using a
And servers that permit modification of the schema over LDAP need this
to properly support the delete operation in a Modify Request. Otherwise,
per the spec, only the replace operation is available.
I was just curious.
> > and what do you do when a match is required and no matching rule is known.
> The search fails, with the error code unavailableCriticalExtension (12) in the
> LDAP response.
Is this conforming behaviour? X.501 seems to indicate that such an AVA is
"undefined" (in case anyone is wondering, "undefined" is not undefined at all
and has a very well defined meaning). In the extensibleMatch case, it is
explicitly said so in RFC 2251.
> If approximate matching rules were added, I expect Netscape would enable clients
> to access them using the extensibleMatch feature (in LDAP v3). Changing the
> semantics of the =~ operator is a bad idea, I think.
Yeah, I think extensibleMatch is the one true way. BTW, approximate matching is
said to be DSA-specific in X.501. So there is no right or wrong way to do it.
> Another case is localized collation keys (for internationalized sorting, or
> inequality filters). A lot of internationalized collation software uses collation
> keys that have 2 or 3 bytes per source character.
Silly me, it's obvious. I should have known better. Never mind, this was pretty
much already decided, normalization routines will return freshly allocated space.