Re: Heads up: new schema support

[John Kristian <kristian@netscape.com>]

You're welcome to evaluate Netscape Directory Server, without charge.  See
http://home.netscape.com/testdrive/download/selectplatform_102_281.html

> John Kristian wrote:
>
>> I implemented the matching rules part, in Netscape Directory Server ...
>
Julio Sánchez Fernández wrote:

> ... I'm intrigued about how you solved matching rules like
> onjectIdentifierFirstComponentMatch

I didn't.  But a plugin that supports this rule could easily be developed, and
more easily installed in any Netscape Directory Server version 3.1 or later.  With
a little more development, the plugin could enable indexing for this matching
rule.

Is this rule useful, in LDAP?  For what purpose?

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

> Also your approach to approx matching.

The current server supports Metaphone, only.  I don't know any other useful
approximate matching rules, although I suppose they exist.  Do you know some?
Where could I learn about them?

It might be possible to add other approximate matching rules, as plugins to
Netscape Directory Server.  But I can't say, without knowing something about their
interfaces.

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.

>> ...the keys (for indexing or sorting) of some matching rules need to be larger
>> (more bytes) than the values from which they're computed.
>
> I did not know that it could get larger.  One case I can come up with is when
> uppercasing German es-zet.

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.  So a string with 1 byte per
character (in the ASCII subset of UTF-8) has a corresponding collation key that's
2 or 3 times larger.