Hi,
On my servers I've redefined facsimileTelephoneNumber as a telephoneNumber:
attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DESC 'RFC2256: Facsimile (Fax) Telephone Number' SUP telephoneNumber )
This requires reimporting the database since the normalisation changes, but it adds comparison rules to fax numbers (allowing comparison and replacement of them):
Before: ldapcompare -x uid=person1234,dc=example,dc=com facsimiletelephonenumber::KzEoNTU1KS01NTUtNTU1NQ== Compare Result: Inappropriate matching (18) Additional info: inappropriate matching request UNDEFINED
After: ldapcompare -x uid=person1234,dc=example,dc=com facsimiletelephonenumber::KzEoNTU1KS01NTUtNTU1NQ== TRUE
Is there any reason to follow the RFC in this case? The RFC itself doesn't make a good argument for or against fax numbers having a separate syntax with no matching rules.
On Wed, Apr 22, 2009 at 08:34:55AM -0700, Sean Burford wrote:
On my servers I've redefined facsimileTelephoneNumber as a telephoneNumber:
attributetype ( 2.5.4.23 NAME ( 'facsimileTelephoneNumber' 'fax' ) DESC 'RFC2256: Facsimile (Fax) Telephone Number' SUP telephoneNumber )
Is there any reason to follow the RFC in this case?
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. 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...
It would be more correct to define a completely new attribute with the behaviour that you want. You would then have to persuade the applications to use it :-)
The RFC itself doesn't make a good argument for or against fax numbers having a separate syntax with no matching rules.
RFC2256 is now obsolete. RFC4517 says this:
----------------------------------------------------------------------- 3.3.11. Facsimile Telephone Number
A value of the Facsimile Telephone Number syntax is a subscriber number of a facsimile device on the public switched telephone network. The LDAP-specific encoding of a value of this syntax is defined by the following ABNF:
fax-number = telephone-number *( DOLLAR fax-parameter ) telephone-number = PrintableString fax-parameter = "twoDimensional" / "fineResolution" / "unlimitedLength" / "b4Length" / "a3Width" / "b4Width" / "uncompressed"
The <telephone-number> is a string of printable characters that complies with the internationally agreed format for representing international telephone numbers [E.123]. The <PrintableString> rule is defined in Section 3.2. The <DOLLAR> rule is defined in [RFC4512].
The LDAP definition for the Facsimile Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number')
The Facsimile Telephone Number syntax corresponds to the FacsimileTelephoneNumber ASN.1 type from [X.520]. -----------------------------------------------------------------------
Note that there is more to a 'Facsimile Telephone Number' than there is to a 'Telephone Number' as it can also describe the capabilities of the receiving equipment. (I have never seen the extra information being provided or used, but some application might...)
The definition of telephoneNumber is:
----------------------------------------------------------------------- 3.3.31. Telephone Number
A value of the Telephone Number syntax is a string of printable characters that complies with the internationally agreed format for representing international telephone numbers [E.123].
The LDAP-specific encoding of a value of this syntax is the unconverted string of characters, which conforms to the <PrintableString> rule in Section 3.2.
Examples: +1 512 315 0280 +1-512-315-0280 +61 3 9896 7830
The LDAP definition for the Telephone Number syntax is:
( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
The Telephone Number syntax corresponds to the following ASN.1 type from [X.520]:
PrintableString (SIZE(1..ub-telephone-number))
The value of ub-telephone-number (an integer) is implementation defined. A non-normative definition appears in [X.520]. -----------------------------------------------------------------------
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.
Andrew
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.
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"
Sean Burford writes:
h.b.furuseth@usit.uio.no> wrote:
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
True, LDAP does not support that for attributes without EQUALITY matching rules. (So there is no LDIF syntax for it:-) For such attributes you need to read the entry and use replace:, listing the values you want to keep.
On Wed, Apr 22, 2009 at 08:10:15PM +0200, Hallvard B Furuseth wrote:
dn: uid=username,dc=example,dc=com changetype: modify delete: facsimileTelephoneNumber facsimileTelephoneNumber:telephoneNumberMatch:=+1 (555)555 5555
True, LDAP does not support that for attributes without EQUALITY matching rules. (So there is no LDIF syntax for it:-) For such attributes you need to read the entry and use replace:, listing the values you want to keep.
If the requirement for the new definition is just to make value deletion easier then I would question its worth. Deleting individual values is important in attributes like 'member' that are likely to have thousands of values, but how many fax numbers could an entry usefully have?
Andrew
On Wed, Apr 22, 2009 at 11:53 AM, Andrew Findlay < andrew.findlay@skills-1st.co.uk> wrote:
On Wed, Apr 22, 2009 at 08:10:15PM +0200, Hallvard B Furuseth wrote:
dn: uid=username,dc=example,dc=com changetype: modify delete: facsimileTelephoneNumber facsimileTelephoneNumber:telephoneNumberMatch:=+1 (555)555 5555
True, LDAP does not support that for attributes without EQUALITY matching rules. (So there is no LDIF syntax for it:-) For such attributes you need to read the entry and use replace:, listing the values you want to keep.
If the requirement for the new definition is just to make value deletion easier then I would question its worth. Deleting individual values is important in attributes like 'member' that are likely to have thousands of values, but how many fax numbers could an entry usefully have
The existing sync script assumes that attributes can be replaced.
I have to reimport the databases anyway for a 2.3 -> 2.4 upgrade so the only cost is maintaining the schema patch (and presumably crashing if we ever forget to include it since this is a normalization change).
openldap-technical@openldap.org
-
Andrew Findlay -
Hallvard B Furuseth -
Michael Ströder -
Sean Burford