Re: >= (greater or equal) and <= (lower or equal) operators in

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Pierangelo Masarati writes:
>> On Fri, Jul 16, 2004 at 10:05:27AM +0100, Greg Matthews wrote:
>>> Is there no call for this sort of matching in filters then? Doesnt
>>> anyone need to:
>>>
>>> ldapsearch -x "(uidnumber>=1000)"
>>
>> I need to, but I can't. The RFC2307 schema misses that, (...)
> 
> I think the standard is missing it on purpose, because regular usage
> doesn't need anything but exact match.

Possibly, but more likely they just mimiced how how most other
attributes are defined:  Almost none of them has ORDERING rules, even
common ones like 'name' and thus 'cn' - and noone can possibly know all
the purposes those two will be used for.  I've asked for ORDERING rules
for some attributes once in a while too, but usually too late.

>>> Is it considered breaking standard schema to add ORDERING rules into
>>> them?
>>
>> I would love to and I'm about to throw in the towel and "break" this
>> standard schema by adding this (and other) rules. A broken or
>> difficult standard is of no use.
> 
> Then just design your own, or propose a draft for standard emendation,
> but don't hijack others, or you'll run into interoperability problems,
> sooner or later.

True, but sometimes the attributes are needed for another application
which expects a particular attribute name like uidNumber (e.g. PAM, I
think).  Then you'd have to store that other attribute in _addition_
to uidNumber.

Or you could make your own schema with the same attribute names, object
class names etc. as the Pam schema, but with your own OIDs and with the
matching rules you want.  That's 'formally' OK - unless the RFC2307
attribute names are registered with IANA - and a bit cleaner than
modifying the original schema, but still rather ugly, I guess.

-- 
Hallvard