GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1218

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:
  1. Listing Services Database Generic Requirements, Bellcore

TA-TSY-000985;

  1. Common Directory Use ED 013 (Q/511) (EWOS/EGDIR/90/156);

and,

  1. 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 }
  1. - 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 }
  1. - 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

  1. - attribute types
       fipsStateNumericCode ATTRIBUTE
  1. - semantics and values defined in US FIPS PUB 5

WITH ATTRIBUTE-SYNTAX

  1. - 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1218.txt · Last modified: 1991/04/03 22:26 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki