[Date Prev][Date Next]
Re: Greater-equal/Less-than-equal comparisons
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
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
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
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 !