diff options
Diffstat (limited to 'doc/rfc/rfc1218.txt')
| -rw-r--r-- | doc/rfc/rfc1218.txt | 1291 |
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc1218.txt b/doc/rfc/rfc1218.txt new file mode 100644 index 0000000..b9030d6 --- /dev/null +++ b/doc/rfc/rfc1218.txt @@ -0,0 +1,1291 @@ + + + + + + +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 + + + +NADF [Page 1] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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: + + + + +NADF [Page 2] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + (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 + + + +NADF [Page 3] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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., + + + + +NADF [Page 4] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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 + + + +NADF [Page 5] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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 + + + + + + + +NADF [Page 6] + +RFC 1218 A Naming Scheme for c=US April 1991 + + +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 + + + + + + + +NADF [Page 7] + +RFC 1218 A Naming Scheme for c=US April 1991 + + +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. + + + + +NADF [Page 8] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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, + + + +NADF [Page 9] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + (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 + + + +NADF [Page 10] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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> + + + + +NADF [Page 11] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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. + + + + + +NADF [Page 12] + +RFC 1218 A Naming Scheme for c=US April 1991 + + +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 } + + + +NADF [Page 13] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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 }} + + + + + + + +NADF [Page 14] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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). + + + + +NADF [Page 15] + +RFC 1218 A Naming Scheme for c=US April 1991 + + +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, us + + Comments 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. + + + + + + + + + + + +NADF [Page 16] + +RFC 1218 A Naming Scheme for c=US April 1991 + + +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 + + + +NADF [Page 17] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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 } + + + + +NADF [Page 18] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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 } + + + + + + + + + +NADF [Page 19] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + -- 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 } + + + + + + +NADF [Page 20] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + 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: + + + + +NADF [Page 21] + +RFC 1218 A Naming Scheme for c=US April 1991 + + + (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. + + + + + + + + + + + + + +NADF [Page 22] + +RFC 1218 A Naming Scheme for c=US April 1991 + + +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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +NADF [Page 23] +
\ No newline at end of file |