Origin of Directory Naming Attributes
This page gives a brief introduction to the history and origin of naming attributes that are used in LDAP.
The attributes which form the basis of naming entries in LDAP, as described in RFC 2256, are derived from those of its predecessor, X.500. In principle they are the same attributes as X.500, merely in a UTF-8 string encoding. But why do these attributes exist?
One can find out more about X.500 by reading David Chadwick's excellent book Understanding X.500 - The Directory located online at http://www.isi.salford.ac.uk/staff/dwc/X500.htm, but to understand where X.500 got its attributes, it's necessary to look at its reason for existence, the X.400 international electronic mail standard.
X.400 Addressing
The X.400 specifications were first published by ITU-T (then CCITT) in 1984, and were substantially revised in 1988. The X.400 architecture originated from IFIP WG 6.5, on International Computer Messaging, and was intended to be able to handle store-and-forward electronic mail, with interfaces into telex, fax, teletex and postal mail.
In X.400 terminology, a User Agent (UA) is the email client which someone uses to generate a message and submit it to a Message Transfer Agent (MTA), which passes the message to other MTAs until the message reaches the destination user, or until it is converted to a service outside of X.400, such as being reformatted into a telex, fax, or is printed out and delivered via a postal service.
Compared to Internet mail, the X.400 design enforces more of a logical separation between the envelope, which contains the fields manipulated by the MTAs, and the content of the message. The original content forms were named P2 and P22, and represent a business memo. These forms of content consist of a header, resembling a cover sheet on a memo, and one or more body parts. Each body part could be text or an image, such as a fax.
The header within the P2/P22 content is not used in routing the messages, thus the forms of identifiers used within the header for the originator of the memo and its recipients (ORDescriptor) is a choice between an ORName (described below, it is identifier that is routable by the MTA), a free form name, or a telephone number. It was suggested that the free form name would be the most common one to use within the header.
ORDescriptor ::= SET { -- at least one of the first two members
must be present
formal-name ORName OPTIONAL,
free-form-name [0] TeletexString OPTIONAL,
telephone-number [1] PrintableString OPTIONAL
}
When the user agent submits a message to an MTA, it identifies the originator and the recipients using ORNames, which the MTA turns into the envelope of the message.
An ORName consists of either an ORAddress, or the name of an entry in a directory service, or both.
ORName ::= [APPLICATION 0] SEQUENCE {
-- address --COMPONENTS OF ORAddress,
directory-name [0] Name OPTIONAL --
added in 1988
}
The address part consists of several 'standardized' (built into the specification) attributes, as well as two extensibility mechanisms, domain-defined and extension attributes:
ORAddress ::= SEQUENCE {
built-in-standard-attributes BuiltInStandardAttributes,
built-in-domain-defined-attributes BuiltInDomainDefinedAttributes
OPTIONAL,
-- see also teletex-domain-defined-attributes
extension-attributes
ExtensionAttributes OPTIONAL -- added in 1988
}
A typical ORAddress would contain a country, various routing fields specifying what organizations manage mail routing within that country (e.g. a PTT or data networking provider), and an indication of the end user, either at a network address, a terminal address, a personal name, or some other form of identifier (as a memo might for example be sent to, for example, the address of a 'purchasing department' in an organization).
BuiltInStandardAttributes ::= SEQUENCE {
country-name
CountryName OPTIONAL,
administration-domain-name AdministrationDomainName
OPTIONAL,
network-address
[0] NetworkAddress OPTIONAL,
-- see also extended-network-address
terminal-identifier [1] TerminalIdentifier
OPTIONAL,
private-domain-name [2] PrivateDomainName
OPTIONAL,
organization-name [3] OrganizationName
OPTIONAL,
-- see also teletex-organization-name
numeric-user-identifier [4] NumericUserIdentifier
OPTIONAL,
personal-name [5] PersonalName
OPTIONAL,
-- see also teletex-personal-name
organizational-unit-names [6] OrganizationalUnitNames
OPTIONAL
-- see also teletex-organizational-unit-names
}
The PersonalName field is where we first see the structure and format of the name mandated. The PrintableString has a restricted character set, the letters A-Z in upper and lower case, numbers 0-9, space and a few symbols.
PersonalName ::= SET {
surname [0] PrintableString(SIZE (1..)),
given-name [1] PrintableString(SIZE (1..)) OPTIONAL,
initials [2] PrintableString(SIZE (1..))
OPTIONAL,
generation-qualifier [3] PrintableString(SIZE (1..)) OPTIONAL
}
Note that the surname field is required to be present if there is a PersonalName in the address.
Use of Directory in X.400
Originally, X.400 did not have a directory service, and the ORName was merely the ORAddress. However, ORAddress values would be difficult for the user to type in consistently - the slightest error in spelling might cause the message to be returned. The ORAddress is much more complicated than a typical Internet email address (see Addresses are ugly), an example given in RFC 1685 is g=per;s=hansen;o=teledir;ou1=forskning;p=tele;a=telemax;c=no
Furthermore, if a user of the system had changed their provider domains, they would have needed to inform every other user of this, as the old provider would probably no longer be able to route messages to them.
For this reason, the ORName allows the user agent to provide an directory name (distinguished name) to the MTA in addition to the ORAddress. The directory distinguished name was intended to be more 'user friendly' than the ORAddress, as it would not contain routing and domain information, only those attributes which usefully identify the subject recipient, and are attributes commonly used to identify individuals relative to organizations or residences.
If presented with an ORName, the MTA will look up in the directory the directory name of the recipient, and find the preferredDeliveryMethod attribute from that entry (indicating mhs, physical, telex, teletex, g3fax, g4fax, ia5, videotex, telephone or any) as well as the attributes which indicate how to route a message to that recipient in that method (e.g. telexNumber, postalAddress or mhsORAddresses).
If the sender doesn't know what the recipient's directory name is, the User Agent might have a Directory User Agent that will allow the sender to browse the directory and find the recipient's entry before submitting the message.
How the sender would find the recipient would depend on whether the sender is locating a recipient relative to a particular organization (e.g. finding an employee of a firm).
First, the sender would select a country, and then might select a locality, such as a state or province, within that country. Localities could be nested, allowing the user to select a smaller region, such as a city or county, depending on how the directory is structured.
If the sender is looking for a user in an organizational context, they would first browse or search for that organization within the country or locality, and then once the organization is found, browse or search within that organization for the name of the recipient. Recipients within an organization would be represented by the organizationalPerson or organizationalRole object class, and would use the commonName attribute for naming the entry. An organizationalPerson entry must have a commonName and a surname attribute. An organizationalRole entry must have a commonName attribute.
Otherwise, the sender would search for a residentialPerson. A residentialPerson entry must have commonName, surname and localityName attributes.
PrintableString and TeletexString
The PrintableString character set, however, would not be capable of encoding all the characters which are used in actual names for localities, organizations and individuals.
CCITT were defining a new enhanced Telex service, Teletex, they also defined a new character set, T.61, which contained letters and diacriticals needed for Western European languages. T.61 is an eight bit encoding, but also allows for a complicated system of shifting and escape codes to switch to other character sets, in order to accomodate Greek and Asian languages.
Thus, in X.400 ORAddress there are extensions for addressing recipients in the Teletex service with their names expressed in T.61 character set, in addition to the PrintableString:
common-name
EXTENSION-ATTRIBUTE ::= { PrintableString
IDENTIFIED
BY 1
}
teletex-common-name
EXTENSION-ATTRIBUTE ::= { TeletexString
IDENTIFIED
BY 2
}
The same philosophy appears in the definition of X.500 attributes, allowing either PrintableString or TeletexString to be used in string-valued attributes such as commonName.
The Teletex service never materialized, and character sets proliferated. To address this, ISO 10646 defines a character set with a much larger space. ISO 10646 has several possible encodings, including a 32 bits per character encoding (UniversalString), a more space efficent 16 bits per character (BMPString), and a variable length encoding (UTF8String).
The 1992 updates to X.400 and X.500 added support for these character sets, with more X.400 ORAddress extensions :
universal-common-name EXTENSION-ATTRIBUTE ::= {
UniversalCommonName
IDENTIFIED BY 24
}
UniversalCommonName ::= UniversalOrBMPString
and in X.500 as the basic string data type used in attributes:
DirectoryString ::= CHOICE {
teletexString TeletexString,
printableString PrintableString,
universalString UniversalString,
bmpString BMPString,
uTF8String UTF8String
}
X.500 Directory Attributes
The following attribute types are summarized from ITU-T X.520(2001), and include only those which are likely to be encountered during normal browsing operations.
The base of many attributes used in naming entries related to finding individuals and organizations is name.
name ATTRIBUTE ::= {
WITH SYNTAX DirectoryString
}
The following attributes all inherit from the name attribute:
| commonName | |
|---|---|
| surname | |
| givenName | |
| initials | |
| generationQualifier | |
| pseudonym | |
| localityName | |
| stateOrProvinceName | |
| countryName | single value limited to 2 PrintableString characters, ISO 3166 codes only |
| organizationName | |
| organizationalUnitName | |
| title | |
| dmdName |
Other attributes which have a string syntax include:
1/spec/| dnQualifier | PrintableString |
| serialNumber | PrintableString |
| streetAddress | DirectoryString |
| houseIdentifier | DirectoryString |
| description | DirectoryString |
| businessCategory | DirectoryString |
| postalCode | DirectoryString |
| postOfficeBox | DirectoryString |
| physicalDeliveryOfficeName | DirectoryString |
| telephoneNumber | PrintableString, ITU-T E.123 |
| x121Address | NumericString |
| internationalISDNNumber | NumericString |
| destinationIndicator | PrintableString |
Finally, there are attributes whose syntax in X.500 are not strings, but have string encodings in LDAP:
postalAddress ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE SIZE (1..6) OF DirectoryString
}
registeredAddress ATTRIBUTE ::= {
SUBTYPE OF postalAddress
}
telexNumber ATTRIBUTE ::= {
WITH SYNTAX
SEQUENCE {
telexNumber PrintableString(SIZE (1..)),
countryCode PrintableString(SIZE (1..)),
answerback PrintableString(SIZE (1..))
}
}
facsimileTelephoneNumber ATTRIBUTE ::= {
WITH SYNTAX SEQUENCE {
telephoneNumber TelephoneNumber,
parameters G3FacsimileNonBasicParameters OPTIONAL
}
}