[Date Prev][Date Next]
Re: Comparable and replaceable fax numbers
On Wed, Apr 22, 2009 at 10:03 AM, Hallvard B Furuseth <email@example.com>
Andrew Findlay writes:Yup. Also it's usually a bad idea to inherit from an attribute which is
> 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.
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
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 definitionsYes. I miss ORDERING rules in particular.
> could have been made more usable with hindsight...
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
In any case, maybe OpenLDAP could be made to accept this filter:
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):
facsimileTelephoneNumber:telephoneNumberMatch:=+1 (555)555 5555
ldapmodify: wrong attributeType at line 4, entry "uid=username,dc=example,dc=com"