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"