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.
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.
The rules for matching Telephone Number syntax remove most of the punctuation that people tend to put into printed phone numbers. In most cases this will do the right thing, but if some application stores fax capabilities in the number then the rules are defeated.
Just hyphens and whitespace. Not parens. RFC 4518 section 2.6.3.