Re: Heads up: new schema support

[Julio Sánchez Fernández <j_sanchez@stl.es>]

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
Compare Request.

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.

Julio