On Wed, Apr 22, 2009 at 10:03 AM, Hallvard B Furuseth < h.b.furuseth@usit.uio.no> wrote:
Andrew Findlay writes:
Only the usual one that it is generally a bad idea to modify anything that is defined in a standard, as someone else may be depending on it in a way that you cannot guess.
Yup. Also it's usually a bad idea to inherit from an attribute which is intended to occur in directory entries. Filter (telephoneNumber=foo) will then also match facsimileTelephoneNumber: foo, and a search requesting telephoneNumber will return facsimileTelephoneNumber too. It would be better to copy SYNTAX, EQUALITY, etc from telephoneNumber's definition.
Yes, this was the practical result. I've updated my schema so that facsimileTelephoneNumber isn't SUP telephoneNumber. Thanks.
This is a pretty powerful argument,
though I would agree that many of the standard schema definitions could have been made more usable with hindsight...
Yes. I miss ORDERING rules in particular.
Regarding fax, maybe the EQUALITY rule is missing because people would normally search for the number without fax parameters, and a matching rule which did not check the params would not be the EQUALITY matching rule. Unless one cannot store the same number twice in an attribute but with different parameters, which I guess could have been an OK solution.
In any case, maybe OpenLDAP could be made to accept this filter: (facsimileTelephoneNumber:telephoneNumberMatch:=foo) OpenLDAP doesn't support indexing for extended filters though.
I don't think extended filters would help with selective attribute deletion (my syntax may be wrong):
dn: uid=username,dc=example,dc=com changetype: modify delete: facsimileTelephoneNumber facsimileTelephoneNumber:telephoneNumberMatch:=+1 (555)555 5555
ldapmodify: wrong attributeType at line 4, entry "uid=username,dc=example,dc=com"