Re: Greater-equal/Less-than-equal comparisons

[Peter Marschall <peter@adpm.de>]

Hi Dieter,

On Friday 10 October 2003 20:12, Dieter Kluenter wrote:
> Am Fre, 2003-10-10 um 14.56 schrieb Andreas:
> > On Fri, Oct 10, 2003 at 07:03:52AM -0500, Brent J. Nordquist wrote:
> > > That appears to work!  By adding an ordering rule to a custom type I
> > > now have >= and <= working.  Thanks much for the pointer.
> >
> > So, this ordering rule is working with openldap? Great :)
> >
> > How can one propose a change to this schema so that this ordering
> > rule gets included? A patch to the rfc, something like that?
>
> As draft and for discussion
> http://www.avci.de/download/dieter/kluenterFakedName.schema

I disagree with you in building a private schema with extended matching
rules for standard attribute types.

Although I understand that OpenLDAP cannot create a schema that suits
everybody I sometimes wished that the standard attribute types that OpenLDAP 
ships with would be a bit more flexible or complete when it comes to matching 
rules.
Almost all other vendors of directory servers allow more filters to be used on 
standard attributes that OpenLDAP does. Some even do it without announcing 
these rules in the schema (which makes it impossible for the user to know 
exactly the rules applied).

So my proposal to the OpenLDAP developers is to extend the attribute 
definitions in the schema files shipped with OpenLDAP in the natural way.

What I want to say is: numbers have an ordering, so attributes with a number 
syntax should be given an ordering matching rule. Strings can have 
substrings, so attributes with string syntaxes should be given a substring 
rule. If the strings syntax is so that an ordering is "natural", why not 
giving these strings an appropriate ordering rule (e.g. aphabetical 
ordering).

What is worse: Ending up with different schemas since the standard schema does 
not fit for the purposes people use, doing lit like other servers do and 
allow filter operations on attributes without telling the associated matching 
rule in the schema definition or extrnding the attribute types that OpenLDAP 
ships with [maybe together with a proposal for new RFCs that superseed the 
ones with the affected attributes] ?

IMHO these extension that I propose does not have any influence on the way the 
data is stored in the directory (maybe except for indices) an thus do not 
break compatibility with clients or other directory servers.

This would allow us to keep the best of both worlds: 
compatiblity with clients and other servers and feature completeness.

Comments, ideas, ... welcome !

Peter
-- 
Peter Marschall
eMail: peter@adpm.de