I wrote:
Zhang Weiwu writes:
The syntax needs its own comparison rules, so that you can filter a range, and get entries who offer values ranging in that range.
Then you need a syntax and matching rule(s) for it.
On second thought, a single LDAP attribute won't do for you if you want to be able to index the attribute for range match. An attribute can have equality, substring and ordering matching rules. Range match is neither. A filter can use extensible match, (attr:fooRangeMatch:=20~40) could e.g. mean the attr value fully covers range 20~40, but you cannot index for that.
When we needed to index IP subnet ranges, we defined two single-valued attributes with max and min value stored as single decimal integers. Integers support ORDERING indexin, so clients could then filter for (&(min<=IPNUM)(max>=IPNUM)). This would not work if we needed multiple ranges in a single entry.
I had not thought of the constraint overlay which Michael mentions, maybe that'll work too. I suppose it depends on how much work you are willing to do on the client side. You could define a normalized range format which is easy to match and which the the client rather than the server is responsible for maintaining. Indexing would still not work.