Network Working Group The North American Directory Forum
Request for Comments: 1218 April 1991
A Naming Scheme for c=US
Status of this Memo
-
This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.
Summary
-
This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). The NADF is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. NADF-123 is a scheme proposed for this purpose. The NADF is circulating NADF-123 widely, expressly for the purpose of gathering comments. The next meeting of the NADF is in mid-July, and it is important for comments to be received prior to the meeting, so that the scheme may receive adequate review.
A Naming Scheme for c=US The North American Directory Forum NADF-123 Supercedes: NADF-103, NADF-71 March 21, 1991
ABSTRACT
-
This is one of a series of documents produced for discussion within the North American Directory Forum. Distribution, with attribution, is unlimited. This document is being circulated for comment. The deadline for comments is July 1, 1991. Comments should be directed to the contact given on page 16.
1. Introduction
-
Computer networks form the infrastructure between the users they interconnect. For example, the electronic mail service offered by computer networks provides a means for users to collaborate towards some common goal. In the simplest cases, this collaboration may be solely for the dissemination of information. In other cases, two users may work on a joint research project, using electronic mail as their primary means of communication.
However, networks themselves are built on an underlying naming and numbering infrastructure, usually in the form of names and addresses. For example, some authority must exist to assign network addresses to ensure that numbering collisions do not occur. This is of paramount importance for an environment which consists of multiple service providers.
2. Approach
-
It should be observed that there are several different naming universes that can be realized in the Directory Information Tree (DIT). For example, geographical naming, community naming, political naming, organizational naming, and so on. The choice of naming universe largely determines the difficulty in mapping a user's query into a series of Directory operations. Although it is possible to simultaneously support multiple naming universes with the DIT, this is likely to be unnatural. As such, this proposal focuses on a single naming universe.
The naming universe in this proposal is based on civil authority. That is, it uses the existing civil naming infrastructure and suggests a (nearly) straight-forward mapping on the DIT. There are four components to the naming architecture:
(1) civil naming and optimized civil naming, which reflects
-
names assigned by civil authority;
(2) organizational naming, which reflects names assigned
within organizations;
(3) ADDMD naming, which reflects names assigned to public
-
providers within the Directory service; and,
(4) application naming, which reflects names assigned to OSI
-
entities.
An important characteristic is that entries should be listed wherever searches for them are likely to occur. This implies that a single object may be listed under several entries.
2.1. Names and User-Friendliness
-
It must be emphasized that there are three distinct concepts which are often confused when discussing a naming scheme:
(1) user-friendly naming: a property of a Directory which
-
allows users to easily identity objects;
(2) user-friendly name: a technique for naming an object
-
which exhibits "friendliness" according to an arbitrary set of user-criteria; and,
(3) Distinguished Name: the administratively assigned name
-
for an entry in the OSI Directory.
It must be emphasized that Distinguished Names are not necessarily user-friendly names, and further, that user-friendly naming in the Directory is a property of the Directory Service, not of Distinguished Names.
2.2. Choice of RDN Names
-
The key aspect to appreciate for choice of RDNs is that they should provide a large name space to avoid collisions: the naming strategy must provide enough "real estate" to accommodate a large demand for entries. This is the primary requirement for RDNs. A secondary requirement is that RDNs should be meaningful (friendly to people) and should not impede searching.
However, it is important to understand that this second requirement can be achieved by using additional (non-distinguished) attribute values. For example, if the RDN of an entry is
-
-
-
organizationName is Performance Systems International
-
-
then it is perfectly acceptable (and indeed desirable) to have other values for the organizationName attribute, e.g.,
organizationName is PSI
The use of these abbreviated names greatly aids searching whilst avoiding unnecessary Distinguished Name conflicts.
In order to appreciate the naming scheme which follows, it is important to understand that it leverages, wherever possible, existing naming infrastructure. That is, it relies heavily on non- OSI naming authorities which already exist. Note that inasmuch as it relies on existing naming authorities, there is little chance that any "final" national decision could obsolete it. [Footnote: Any naming scheme may be subject to the jurisdiction of certain national agencies. For example, the US State Department is concerned with any impact on US telecommunications treaty obligations.] (To do so would require a national decision that disregards existing national and regional infrastructure, and establishes some entirely new and different national naming infrastructure.)
-
3. Civil Naming
-
Civil naming occurs at three levels:
(1) the national level, which contains objects that are
-
recognized throughout a country;
(2) the regional level, which contains objects that are
recognized throughout a state or state-equivalent; and,
-
(3) the local level, which contains objects that are
-
recognized within a populated place.
3.1. Naming at the National Level
-
At the national-level (at least) three kinds of names may be listed:
(1) The States and State-Equivalents
(2) Organizations with National Standing
(3) ADDMD Operators
3.1.1. The States and State-Equivalents
-
For each state or state-equivalent (the District of Columbia and the eight outlying areas [Footnote: i.e., American Samoa, Federated States of Micronesia, Guam, Marshall Islands, Northern Mariana Islands, Palau, Puerto Rico, and Virgin Islands of the US.]), an instance of an
usStateOrEquivalent
-
-
object is used. The RDN is formed as
-
localityName is <FIPS 5 name>
e.g.,
-
-
localityName is California
provides the RDN for the State of California. In addition, this entry would contain attributes identifying both the FIPS 5 alpha and numeric code for the State, e.g.,
-
-
-
fipsStateNumericCode is 06
fipsStateAlphaCode is CA
-
-
Of course, this entry could contain many other attributes such as
-
stateOrProvinceName is State of California
3.1.2. Organizations with National Standing
-
There is no authority in the United States which unambiguously registers the alphanumeric names of organizations with national standing. It is proposed that ANSI provide this registry and that the ANSI alphanumeric name form be used as the basis for RDNs.
For each organization with national standing, an instance of an
usOrganization
-
-
object is used. The RDN is formed as
-
organizationName is <ANSI alphanumeric name form>
e.g.,
-
organizationName is Performance Systems International
-
-
In addition, this entry would contain attributes identifying the ANSI Alphanumeric name form, e.g.,
ansiOrgNumericCode is 177777
Of course, this entry would contain many other attributes such as
organizationName is PSI
For the National Government, an instance of an
organization
object is also used, and the RDN is taken from the ANSI alphanumeric name form registry.
-
3.1.3. ADDMD Operators
-
There is no authority in the United States which unambiguously registers the names of ADDMD operators. It is expected that the North American Directory Forum will coordinate with the US CCITT National Committee Study Group D to provide this registry. (At worst, the ADDMDs can use ANSI alphanumeric name forms for their RDN attribute values.)
-
-
For each ADDMD operator, an instance of a
-
nadfADDMD
-
-
object is used. The RDN is formed as
-
addmdName is <NADF registered name>
e.g.,
-
-
addmdName is PSINet
-
3.2. Naming within a State or State-Equivalent
-
At the regional level (at least) two kinds of names may be listed:
(1) Populated Places
(2) Organizations with Regional Standing
3.2.1. Populated Places
-
For each populated place within a state or state-equivalent, an instance of an
usPlace
-
-
object is used. The RDN is formed as
-
localityName is <FIPS 55 name>
e.g.,
-
-
localityName is Hartford
provides the RDN for the Hartford entry immediately subordinate to the usStateOrEquivalent entry for the State of Connecticut. In addition, this entry would contain attributes identifying the FIPS 55 place code, e.g.,
usPlaceCode is 37000
-
3.2.2. Organizations with Regional Standing
-
An organization is said to have regional standing if it is registered with the "Secretary of State" or similar entity within that region, as an entity doing business in the region.
For each organization with regional standing, an instance of an
organization
-
-
object is used. The RDN is formed as
-
organizationName is <registered name of organization>
e.g.,
-
organizationName is Network Management Associates
-
-
might provide the RDN for a business entity registered with the State of California. In this case, the entry thus named would be immediately subordinate to the usStateOrEquivalent entry for the State of California.
Note that other non-distinguished attributes, such as an ANSI numeric name form value, may be included in such an entry --- the organization object might actually be a usOrganization object.
For the Regional Government, an instance of an
organization
-
-
object is also used. The RDN is formed as:
-
organizationName is Government
-
3.3. Naming within a Populated Place
-
At the local level (at least) three kinds of names may be listed:
(1) Persons
(2) Organizations with Local Standing
(3) MHS Distribution Lists
3.3.1. Naming of Persons
-
Within a populated place, there is no centralized naming entity which registers residential persons. It is proposed that entries for persons be immediately subordinate to the usPlace object which most accurately reflects their place of residence.
For each person (wishing to have an entry in the Directory), an instance of a residentialperson
residentialPerson
-
-
object is used. The RDN is usually multi-valued, formed with
-
commonName is <person's full name>
-
-
and some other attribute, such as postalCode, streetAddress, etc. However, because streetAddress is often considered private information, based on agreement with the entity managing the DMD and the listed person, some other, distinguishing attribute may be used, including a "serial number" (having no other purpose). It should be noted however that this is non-helpful in regards to searching, unless other attribute values containing meaningful information are added to the entry and made available for public access.
-
3.3.2. Organizations with Local Standing
-
An organization is said to have local standing if it is registered with the County or City Clerk or similar entity within that locality as an entity "doing business" in that place.
For each organization with local standing, an instance of an
organization
-
-
object is used. The RDN is formed as
-
organizationName is <registered name of organization>
e.g.,
-
organizationName is The Tied House
-
-
might provide the RDN for a business entity registered with the City of Mountain View. In this case, the entry thus named would be immediately subordinate to the usPlace entry for the City of Mountain View.
Note that other non-distinguished attributes, such as an ANSI numeric name form value, may be included in an entry. (That is, the organization object might actually be a usOrganization object.)
-
For the Local Government, if any, an instance of an
-
organization
-
-
object is also used. The RDN is formed as:
-
organizationName is Government
-
3.4. Naming of MHS Distribution Lists
-
Naming of MHS distribution lists remains with the scoping DMD.
4. Optimized Civil Naming
-
The structure of the civil component of the architecture can be concisely described as:
----------------------------------------------------------------------
Level Element objectClass Superior RDN
----------------------------------------------------------------------
root 0
----------------------------------------------------------------------
intl. 1 country 0 countryName
----------------------------------------------------------------------
natl. 2 usStateOrEquivalent 1 localityName
3 usOganization 1 organizationName
4 nadfADDMD 1 addmdName
----------------------------------------------------------------------
reg. 5 usPlace 2 localityName
6 organization 2 organizationName
----------------------------------------------------------------------
local 7 residentialPerson 5 commonName,
other
8 organization 5 organizationName
9 mhsDistributionList 5 commonName
----------------------------------------------------------------------
-
Consider how an interrogation algorithm might locate a residential person, given:
(1) a string denoting the person's real-world name;
(2) a string denoting the real-world name of the populated
-
place in which the person lives; and,
(3) the Distinguished Name of the state or state-equivalent.
A straight-forward approach is to initiate a single-level search to locate the desired populated place. The search results in zero or more Distinguished Names being returned which correspond to the string provided by the user. Then, for each populated place, a subtree search might be initiated to locate the desired residential person. If the number of populated places returned by the first search is large, then this strategy is inefficient.
A better approach would be to initiate a single search, with a filter combining the strings for both the person's real-world name and the place's real-world name. Unfortunately, such a search would have to involve the whole-subtree anchored at the Distinguished Name for the state or state-equivalent, which would be inefficient.
As such, it may be desirable to optimize the civil naming component by listing some entries at a higher level. This is accomplished by using a multi-valued RDN formed by combining the RDNs of the entry and its superior.
There are three cases in civil naming:
(1) listing an organization with regional standing at the
national level;
(2) listing an organization with local standing at the
-
regional level; and,
(3) listing a person with local standing at the regional
-
level.
Hence, under the optimized civil naming component, a single-level search, anchored at the Distinguished Name for the state or state- equivalent, could be used. Further, the implementation of a DSA supporting this optimization would highly-index the attributes used for searching, in order to achieve high-performance.
In order to clearly indicate that optimized civil naming is in effect, a new attribute type, nadfSearchGuide, is introduced. An attribute value of this type is placed in an entry to indicate which optimizations are in effect. Using the residential example above, the entry for the state or state-equivalent would contain an nadfSearchGuide value indicating that when searching for entries of type residentialPerson, a single-level search should be performed with a filter containing the logical-and of two terms, one involving the commonName attribute, and the other involving the localityName attribute. The nadfSearchGuide is a refinement of the X.500 searchGuide in that it indicates the depth of the search which should be performed, and always contains an indication of the object class for which the optimization exists.
Finally, note that for naming within organizations, this technique might also be used.
4.1. Naming at the National Level
4.1.1. Organizations with Regional Standing
-
An organization with standing within a state or state-equivalent may be listed directly under c=US.
For an organization with regional standing, an instance of an
organization
object is used. The RDN is multi-valued, formed as
-
-
-
-
organizationName is <registered name of organization> localityName is <FIPS 5 name>
e.g.,
-
organizationName is Network Management Associates localityName is California
-
-
It must be emphasized that uniqueness within the RDN comes from using the a regional localityName (state or state-Equivalent) in association with the correspondent organizationName in that region.
-
4.2. Naming within a State or State-Equivalent
4.2.1. Organizations with Local Standing
-
An organization with standing within a populated place may be listed directly under its state or state-equivalent.
For an organization with local standing, an instance of an
organization
object is used. The RDN is multi-valued, formed as
-
-
-
-
organizationName is <registered name of organization> localityName is <FIPS 55 name>
e.g.,
-
organizationName is The Tied House
localityName is City of Mountain View
-
-
It must be emphasized that uniqueness within the RDN comes from using the a local localityName (populated place) in association with the correspondent organizationName in that place.
-
4.2.2. Persons
-
An person may be listed directly under its state or state-equivalent.
For such a person, an instance of a
residentialPerson
object is used. The RDN is multi-valued, formed by taking the RDN of the person and adding the RDN of the populated place containing the person.
commonName is the Marshall T. Rose
postalCode is 94043-2112
localityName is City of Mountain View
-
Note that for optimization to occur, the RDN of the person must not contain a localityName attribute value.
5. Organizational Naming
-
The internal structure of each usOrganization or organization object is a matter for that organization to establish.
It is strongly recommended that organizationalUnit objects be used for structuring. (If an organization uses a locality-based organizational hierarchy, this information can still be represented using the
organizationalUnit object.)
6. ADDMD Naming
-
The internal structure of each nadfADDMD object is a matter for that service-provider to establish.
7. Application Naming
-
There are (at least) four kinds of OSI entities which may be listed:
(1) Application Processes and Entities
(2) MHS Distribution Lists
(3) EDI Users
(4) Devices
7.1. Naming of Application Processes and Entities
-
Naming of OSI application processes and entities remains with the scoping DMD. However, in order to foster interoperability, two requirements are made: first, application entity objects must be immediately subordinate to application process objects; and, second, application entities are represented by the nadfApplicationEntity object, which is identical to the applicationEntity object except that the presence of an attribute value of supportedApplicationContext is mandatory.
7.2. Naming of MHS Distribution Lists
-
Naming of MHS distribution lists remains with the scoping DMD.
7.3. Naming of EDI Users
-
Naming of EDI users remains with the scoping DMD.
7.4. Naming of Devices
-
Naming of OSI devices remains with the scoping DMD.
8. Usage Examples
-
Consider the following examples, expressed in a concise format (read left-to-right):
-
-
Federal Government:
-
{ c=US, o=Government }
The State of California:
-
{ c=US, l=California }
The District of Columbia:
-
-
{ c=US, l=District of Columbia }-
-
An organization with national standing:
-
-
{ c=US, o=Performance Systems International }
-
-
-
An ADDMD:
-
{ c=US, addmdName=PSINet }
The Government of the State of California:
-
-
-
{ c=US, l=California, o=Government }
-
-
-
The Government of the District of Columbia:
-
-
{ c=US, l=District of Columbia, o=Government }
-
-
-
A city within the State of California:
-
{ c=US, l=California, l=City of Mountain View }-
-
An organization licensed to operate within the State of California:
-
{ c=US,
-
-
l=California, o=Network Management Associates, Inc. }-
-
An optimized listing for a organization with regional standing:
-
{ c=US,
-
{ l=California,
-
-
-
o=Network Management Associates }}
-
-
-
A city government:
-
{ c=US,
-
-
l=California, l=City of Mountain View, o=Government }-
-
A residential person:
-
{ c=US,
-
-
l=California, l=City of Mountain View, { cn=Marshall T. Rose, postalCode=94043-2112 }} -
An organization licensed to operate within a city:
-
-
-
-
{ c=US,
-
l=California,
l=City of Mountain View,
o=The Tied House }
An entity within the Federal Government:
-
-
{ c=US, o=Government, ou=Department of the Air Force } -
An entity within an organization with national standing:
-
-
-
-
{ c=US,
-
-
o=Performance Systems International, ou=Marketing } -
9. Acknowledgements
-
This document is based on many sources, including, but not limited to:
- Listing Services Database Generic Requirements, Bellcore TA-TSY-000985;
- Common Directory Use ED 013 (Q/511) (EWOS/EGDIR/90/156); and,- The THORN X.500 Naming Architecture (UCL-45 revision 6.1).
10. Bibliography
-
X.500: The Directory --- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988.US FIPS 5: Codes for the Identification of the States, The
District of Columbia and Outlying Areas of the United
States, and Associated Areas, US Department of Commerce
FIPS 5--2, May 28, 1987.
-
US FIPS 6: Counties and Equivalent Entities of the United
-
States, its Possessions, and Associated Areas, US Department of Commerce FIPS 6--4, August 31, 1990.
US FIPS 55: Guideline: Codes for Named Populated Places,
Primary County Divisions, and other Locational Entities
of the United States and Outlying Areas, US Department of
Commerce FIPS 55--2, February 3, 1987.
-
The NADF is soliticting comments on this naming scheme. Comments should be directed to:
Postal: Dr. Marshall T. Rose Performance Systems International 5201 Great American Parkway Suite 3106 Santa Clara, CA 95054 US Telephone: +1 408 562 6222 Fax: +1 408 562 6223 Internet: mrose@psi.com X.500: rose, psi, usComments should be received prior to July 1, 1991.
Appendix A: Naming Architecture
-
There are two aspects to the naming architecture: a DIT structure and a set of related Schema definitions. These are shown on pages 17 and 18, respectively.
DIT Structure
----------------------------------------------------------------------
Level Element objectClass Superior RDN
----------------------------------------------------------------------
root 0
----------------------------------------------------------------------
intl. 1 country 0 countryName
----------------------------------------------------------------------
natl. 2 usStateOrEquivalent 1 localityName
3 usOganization 1 organizationName
4 nadfADDMD 1 addmdName
----------------------------------------------------------------------
reg. 5 usPlace 2 localityName
6 organization 2 organizationName
----------------------------------------------------------------------
local 7 residentialPerson 5 commonName,
other
8 organization 5 organizationName
9 mhsDistributionList 5 commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
opt. 6* organization 1 organizationName,
localityName
7* residentialPerson 2 commonName,
other,
localityName
8* organization 2 organizationName,
localityName
----------------------------------------------------------------------
----------------------------------------------------------------------
org. 10** organizationalUnit 3,6,8,10,11 orgUnitName
11** locality 3,6,8,10,11 localityName
12** organizationalRole 3,6,8,10,11 commonName
13** organizationalPerson 3,6,8,10,11 commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
appl. 14 applicationProcess 3,6,8,10,11 commonName
15 nadfApplicationEntity 14 commonName
16 mhsDistributionList 3,6,8,10,11 commonName
17 ediUser 3,6,8,10,11 ediName
18 device 3,6,8,10,11 commonName
----------------------------------------------------------------------
-
* = These are the optimized form of the corresponding element in the civil component.
** = This scheme makes no requirements on the DIT structure within an organization. The organizational structure shown here is only for exposition. For example, MHS objects are not listed beneath the organizational level, though they are likely to occur within an organization.
Schema Definitions
-
NADF-SCHEMA { joint-iso-ccitt mhs(6) group(6) al-grimstad(5) nadf(1) schema(1) } DEFINITIONS ::= BEGIN-
-
IMPORTS
-
OBJECT-CLASS, ATTRIBUTE FROM InformationFramework { joint-iso-ccitt ds(5) module(1) informationFramework(1) } caseIgnoreStringSyntax, Criteria FROM SelectedAttributeTypes { joint-iso-ccitt ds(5) module(1) selectedAttributeTypes(5) } locality, organization, applicationEntity, top FROM SelectedObjectClasses { joint-iso-ccitt ds(5) module(1) selectedObjectClasses(6) } ; nadf OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs(6) group (6) al-grimstad(5) 1 } -
nadfModule OBJECT IDENTIFIER ::= { nadf 1 }
nadfAttributeType OBJECT IDENTIFIER ::= { nadf 4 }
nadfObjectClass OBJECT IDENTIFIER ::= { nadf 6 }
-
-- object classes
-
-
usStateOrEquivalent OBJECT-CLASS
-
-- localityName is used for RDN -- values come from US FIPS PUB 5 SUBCLASS OF locality MUST CONTAIN { fipsStateNumericCode, fipsStateAlphaCode, stateOrProvinceName } MAY CONTAIN { nadfSearchGuide } ::= { nadfObjectClass 1 }-
-
usPlace OBJECT-CLASS
-
-- localityName is used for RDN -- values come from US FIPS PUB 55 SUBCLASS OF locality MUST CONTAIN { fipsPlaceNumericCode, localityName } MAY CONTAIN { nadfSearchGuide } ::= { nadfObjectClass 2 }-
-
usCounty OBJECT-CLASS
-
SUBCLASS OF usPlace MUST CONTAIN { fipsCountyNumericCode } ::= { nadfObjectClass 3 }-
-
usOrganization OBJECT-CLASS
-
-- organizationName is used for RDN -- values come from ANSI Alphanumeric Registry SUBCLASS OF organization MUST CONTAIN { ansiOrgNumericCode } MAY CONTAIN { nadfSearchGuide } ::= { nadfObjectClass 4 }-
-
nadfApplicationEntity OBJECT-CLASS
-
SUBCLASS OF applicationEntity MUST CONTAIN { supportedApplicationContext } ::= { nadfObjectClass 5 }-
-
nadfADDMD OBJECT-CLASS
-
-- addmdName is used for RDN -- values come from NADF Registry (tbd) SUBCLASS OF top MUST CONTAIN { addmdName } MAY CONTAIN { nadfSearchGuide } ::= { nadfObjectClass 6 } -- auxiliary classes-
-
nadfObject OBJECT-CLASS
-
SUBCLASS OF top MAY CONTAIN { supplementaryInformation } ::= { nadfObjectClass 7 } -- attribute types fipsStateNumericCode ATTRIBUTE -- semantics and values defined in US FIPS PUB 5 WITH ATTRIBUTE-SYNTAX -- leading zero is significant NumericString (SIZE (2)) MATCHES FOR EQUALITY ::= { nadfAttributeType 1 }-
-
fipsStateAlphaCode ATTRIBUTE
-
-- semantics and values defined in US FIPS PUB 5 WITH ATTRIBUTE-SYNTAX PrintableString (SIZE (2)) MATCHES FOR EQUALITY -- case-insensitive ::= { nadfAttributeType 2 }-
-
fipsCountyNumericCode ATTRIBUTE
-
-- semantics and values defined in US FIPS PUB 6 WITH ATTRIBUTE-SYNTAX -- leading zeros are significant NumericString (SIZE (3)) MATCHES FOR EQUALITY ::= { nadfAttributeType 3 }-
-
fipsPlaceNumericCode ATTRIBUTE
-
-- semantics and values defined in US FIPS PUB 55 WITH ATTRIBUTE-SYNTAX -- leading zeros are significant NumericString (SIZE (5)) MATCHES FOR EQUALITY ::= { nadfAttributeType 4 }-
-
ansiOrgNumericCode ATTRIBUTE
-
-- semantics and values defined in ANSI registry WITH ATTRIBUTE-SYNTAX INTEGER MATCHES FOR EQUALITY ::= { nadfAttributeType 5 }-
-
addmdName ATTRIBUTE
-
-- semantics and values defined in NADF registry WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax ::= { nadfAttributeType 6 }-
-
nadfSearchGuide ATTRIBUTE
-
WITH ATTRIBUTE-SYNTAX NadfGuide ::= { nadfAttributeType 7 }-
-
NadfGuide ::=
-
SET { objectClass[0] OBJECT-CLASS, criteria[1] Criteria, subset[2] INTEGER { baseObject(0), oneLevel(1), wholeSubtree(2) } DEFAULT oneLevel }-
-
supplementaryInformation ATTRIBUTE
-
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..76)) ::= { nadfAttributeType 8 } END -
Appendix B: Revision History of this Scheme
-
The first version of this scheme (NADF-71) was contributed to the North American Directory Forum at its November 27--30, 1990 meeting. The (mis)features were:
(1) Because of the lack of confidence in ANSI registration
-
procedures, it was proposed that the US trademarks be used as the basis for RDNs of organizations with national-standing.
This proved unworkable since the same trademark may be issued to different organizations in different
industries.
(2) There was no pre-existing registry used for populated
-
places.
This proved unworkable since the effort to define a new registry is problematic.
The second version of this scheme was contributed to the ANSI Registration Authority Committee at its January 30, 1991 meeting, and the IETF OSI Directory Services Working Group at its February 12--13, 1991 meeting. The (mis)features were:
(1) The ANSI numeric name form registry was used as the basis
for RDNs of organizations with national standings.
-
(2) The FIPS 5 state numeric code was used as the basis for
-
RDNs of states and state-equivalents.
(3) The FIPS 55 place numeric code was used as the basis for
-
RDNs of populated places.
The choice of numeric rather than alphanumeric name forms was unpopular, but was motivated by the desire to avoid using the ANSI alphanumeric name form registry, which was perceived as unstable.
The third version of this scheme was contributed to US State Department Study Group D's MHS-MD subcommittee at its March 7--8 1991 meeting. That version used alphanumeric name forms for all objects, under the perception that the ANSI alphanumeric name form registry will prove stable. If the ANSI alphanumeric name form registry proves unstable, then two alternatives are possible:
(1) disallow organizations with national-standing in the US
-
portion of the DIT; or,
(2) use the ANSI numeric name form registry instead.
Hopefully neither of these two undesirable alternatives will prove necessary.
The fourth version of this scheme (NADF-103) was contributed to the North American Directory Forum at its March 18--22, 1990 meeting. This version introduced the notion of organizations with regional standing being listed at the national level through the use of alias names and multi-valued RDNs.
The current (fifth) version of this scheme (NADF-123) generalized the listing concept by introducing the notion of optimized civil naming. Further, the document was edited to clearly note the different naming components and the relation between them.
Security Considerations
-
Security issues are not discussed in this memo.
Author's Address
-
North American Directory Forum c/o Theodore H. Myer Rapport Communication, Inc. 3055 Q Street NW Washington, DC 20007 Tel: +1 202-342-2727