summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1255.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1255.txt')
-rw-r--r--doc/rfc/rfc1255.txt1403
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc1255.txt b/doc/rfc/rfc1255.txt
new file mode 100644
index 0000000..a40c30f
--- /dev/null
+++ b/doc/rfc/rfc1255.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Network Working Group The North American Directory Forum
+Request for Comments: 1255 September 1991
+Obsoletes: RFC 1218
+
+
+ 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-175,
+ 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-175 represents the NADF's agreement
+ in this area.
+
+Table of Contents
+
+ 1 Introduction .......................................... 2
+ 2 Approach .............................................. 2
+ 2.1 Names and User-Friendliness ......................... 3
+ 2.2 Choice of RDN Names ................................. 3
+ 2.3 Outline of the Scheme ............................... 4
+ 3 The Naming Process .................................... 4
+ 3.1 Right-To-Use ........................................ 4
+ 3.2 Registration ........................................ 6
+ 3.3 Publication ......................................... 6
+ 4 Structuring Objects ................................... 7
+ 4.1 The National Level .................................. 7
+ 4.2 The Regional Level .................................. 7
+ 4.3 The Local Level ..................................... 9
+ 4.4 ADDMD Operators ..................................... 10
+ 4.5 Summary of Structuring Objects ...................... 11
+ 5 Entity Objects ........................................ 12
+ 5.1 Organizations ....................................... 12
+ 5.1.1 Kinds of Organizations ............................ 12
+ 5.1.2 Modeling Organizations ............................ 13
+ 5.2 Persons ............................................. 14
+ 6 Listing Entities ...................................... 15
+ 6.1 Organizations ....................................... 15
+
+
+
+NADF [Page 1]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ 6.2 Persons ............................................. 16
+ 7 Usage Examples ........................................ 17
+ 7.1 Organizations with National-Standing ................ 17
+ 7.2 Organizations with Regional-Standing ................ 18
+ 7.3 Organizations with Local-Standing ................... 19
+ 7.4 Organizations with Foreign-Standing ................. 20
+ 7.5 Persons ............................................. 21
+ 8 Bibliography .......................................... 22
+ Appendix A: Revision History of this Scheme ............. 22
+ Security Considerations ................................. 25
+ Author's Address ........................................ 25
+
+ A Naming Scheme for c=US
+ The North American Directory Forum
+ Supercedes: NADF-166, 143, 123, 103, 71
+ July 12, 1991
+
+1. Introduction
+
+ Computer networks form the infrastructure between the users they
+ interconnect, and networks 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 could be used 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 to find useful information. Although
+ it is possible to simultaneously support multiple naming universes
+ with the DIT, this is likely to be unnatural. As such, this scheme
+ focuses on a single naming universe.
+
+ The naming universe in this scheme is based on civil authority. That
+ is, it uses the existing civil naming infrastructure and suggests a
+ (nearly) straight-forward mapping on the DIT. An important
+ characteristic is that entries can be listed wherever searches for
+ them are likely to occur. This implies that a single object may be
+ listed as several separate entries.
+
+
+
+
+
+
+NADF [Page 2]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+2.1. Names and User-Friendliness
+
+ It must be emphasized that there are two 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 of interest; and,
+
+
+ (2) 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
+ Distinguished Names. 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 wherever possible it leverages 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 this scheme. (Any naming scheme may
+
+
+
+NADF [Page 3]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ 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.
+
+2.3. Outline of the Scheme
+
+ The naming scheme is divided into four parts:
+
+ (1) a discussion of the right-to-use, registration, and
+ publication concepts;
+
+ (2) a discussion of objects with national, regional, local,
+ and foreign standing;
+
+ (3) a discussion of objects which may be listed at
+ national, regional, and local levels; and,
+
+ (4) a discussion of how RDNs are formed for listing entries
+ at each different level.
+
+3. The Naming Process
+
+ There are three stages to the naming process.
+
+3.1. Right-To-Use
+
+ First, a naming authority must establish the right-to-use for any
+ name to be used, within the jurisdiction of the given naming
+ authority. Names that are used in public are generally constrained
+ by public laws. Names that are only used in private are a private
+ matter. We are primarily concerned here with public names because
+ these are the names that are most interesting to enter into public
+ directories where we can search for them.
+
+ There is a global governmental/civil/organizational infrastructure
+ already in place to name and number things like people, cars, houses,
+ buildings and streets; localities like populated places, cities,
+ counties, states, and countries; organizations like businesses,
+ schools, and governments; and other entities like computers,
+ printers, ports, routers, processes, files, filesystems, networks,
+ management domains, and so on. There are also naming (and numbering)
+ authorities for various standards and for networks (e.g., ISO/IEC,
+ CCITT, IANA) which depend on acceptance by their constituent
+ communities for their authority.
+
+
+
+
+NADF [Page 4]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ This collective infrastructure is comprised of a very large number of
+ authorities that we will call naming authorities. Naming authorities
+ tend toward hierarchical organization. Parents have authority
+ (granted by government) to choose the names of new-born children, the
+ courts have authority to change a person's name, car makers have
+ authority to name the models of cars they build (within the limits of
+ trademarking law), and they are obligated to assign unique serial
+ numbers to each car. Cities assign names to their streets and
+ districts, states assign city, county, and township names, and so on.
+ State governments also assign names to "registered" organizations
+ that operate under state charters, which in turn name their own
+ suborganizations. Cities and Counties license businesses to use
+ their chosen (unambiguous) names "in association with" the city and
+ county names. Companies name and number the computers and
+ communications devices they make and sell. There are many many name
+ spaces, some of which are subordinate to others, and some of which
+ are independent.
+
+ Public names must be "registered" in some "public record" to record
+ the fact of the assignment of the right-to-use to specific "owners."
+ In general, this is to prevent collisions of the right-to-use
+ assignments in public shared name spaces. For example, unique names
+ given to corporations are registered by the state of incorporation.
+ A request to use a new name for any corporation must not conflict
+ with the name of any other corporation registered in the same state.
+ The same applies for businesses licensed within cities and counties.
+
+ Establishment of the right-to-use for a name is not a Directory
+ Service. The right-to-use for a name is always derived from some
+ other (non-directory) source of authority because of the legal
+ aspects of intellectual property rights which are entirely outside
+ the scope of directory service specifications. People and
+ organizations attach great value to the names they are allowed to
+ associate with their lives and businesses, and intellectual property
+ law protects their interests with respect to these values.
+
+ This is not to say that directory service designers and providers
+ have no interest in the processes and procedures for establishment of
+ the right-to-use for the names that will be entered into any
+ directory. Indeed, without a supply of rightfully-usable names,
+ there cannot be any directory. But, given an adequate supply of
+ registered names, the directory service is not otherwise concerned.
+
+ We should note here that some naming authorities must deal with name
+ spaces that are shared among large communities (such as computer
+ networks) in which collisions will occur among applicants for desired
+ name assignments, while other name spaces (such as for given names of
+ children in a family) are not shared outside the family. Sharing is
+
+
+
+NADF [Page 5]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ always a problem, which has led to trademarking laws, business
+ license laws, and so on. Naming within organizations should be
+ easier, because it is "in the family," so to speak. Hierarchical
+ naming schemes facilitate distribution of naming authority.
+
+3.2. Registration
+
+ Second, a name may be bound (as a value) to some object attribute.
+
+ Given the right to use a name, a Naming Authority, such as a family
+ which has an inherited surname and, more or less, has the right to
+ use any names it pleases for its children's given names, must bind
+ selected names to selected object attributes (e.g., firstname=Einar).
+ Note that this same name might also be used as the first name or
+ middle name of other children, as long as each sequence of given
+ names of each family member is distinguished (i.e., none are
+ duplicates) within the family. Wise families do not bind the same
+ sequence of given names to more than one child. Some avoid any
+ multiple use of a single name. Some use generational qualifiers to
+ prevent parent-child conflicts.
+
+ The Internet Domain Name System (DNS) names top level domains which
+ are then free (within some technical limits) to chose and bind names
+ to entries which are subordinate to a given named domain, and so
+ forth down the DNS name tree. The ISO/CCITT naming system serves the
+ same purposes in other separate name spaces.
+
+3.3. Publication
+
+ Third, after binding, a name must be advertised or published in some
+ community if it is to be referenced by others. If it is not
+ advertised or published, then no one can refer to it.
+
+ This publication stage is what the Directory Service is all about.
+ The Directory contains entries for "listed" names (or numbers) that
+ are bound to the attributes of the entries in the directory DIT.
+ Historically speaking, the directory business is a subclass of the
+ publishing business, serving to dereference names into knowledge
+ about what they stand for.
+
+ It is important to keep in mind that a directory "listing entry" is
+ not a "registration" unless a particular segment of the directory
+ also just happens to be the authoritative master register of some
+ naming authority. Registration and listing are very different
+ service functions, though it is conceivable that they might be
+ combined in a single DIT.
+
+ For example, in the United States of America, each state name is
+
+
+
+NADF [Page 6]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ registered by the Congress by inclusion of the name in the
+ legislation that "admits each State into the Union." Note however
+ that the name is also then published in many places (such as on maps
+ and in directories), while the master "register" is kept with the
+ other original records of laws enacted by the Congress and signed by
+ the President. Also, the name is then entered (listed) in many
+ directories, in association with the name "The United States of
+ America." And so on down the civil naming tree, with entities named
+ in each state, etc. It is certainly not the case that the American
+ National Standards Institute (ANSI) registers the names of the States
+ in the United States of America! That right and duty is clearly
+ reserved to the Government of the United States of America.
+
+ On the other hand, in the Internet DNS, the act of inserting a given
+ rightfully-usable name and address entry into a nameserver
+ constitutes simultaneous registration and directory publication.
+
+4. Structuring Objects
+
+ The first step in providing a civil naming infrastructure is to model
+ the geographical/governmental entities which provide a basis for the
+ assignment of public names.
+
+4.1. The National Level
+
+ The nation is modeled with an object of class "country", subordinate
+ to the root of the DIT, and has an RDN consisting of a single
+ attribute value assertion:
+
+ countryName= US
+
+ The entry (minimally) contains these attributes:
+
+ objectClass= country
+ description= United States of America
+
+4.2. The Regional Level
+
+ Within the nation, there are regions. Each region corresponds to a
+ state or state-equivalent as recognized by the US Congress. The list
+ of these is maintained in US FIPS 5. A sample entry from this FIPS
+ document looks like this:
+
+
+
+
+
+
+
+
+
+NADF [Page 7]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ +------------+---------+-------+
+ | | State | State |
+ | FIPS-5 | Numeric | Alpha |
+ | Name | Code | Code |
+ +------------+---------+-------+
+ | | | |
+ | California | 06 | CA |
+ | | | |
+ +------------+---------+-------+
+
+ Each region is modeled with an object of class
+ "usStateOrEquivalent", which is defined thusly:
+
+ usStateOrEquivalent OBJECT-CLASS
+ SUBCLASS OF locality, nadfObject
+ MUST CONTAIN { localityName,
+ fipsStateNumericCode,
+ fipsStateAlphaCode,
+ stateOrProvinceName }
+
+
+
+ Each entry is subordinate to "c=US", and has an RDN consisting
+ of a single attribute value assertion:
+
+ stateOrProvinceName= <FIPS-5 name>
+
+ e.g.,
+
+ stateOrProvinceName= California
+
+
+ Each entry (minimally) contains these attributes:
+
+ objectClass= usStateOrEquivalent
+ description= <official name of region>
+ localityName= <FIPS-5 name>
+ localityName= <FIPS-5 state alpha code>
+ fipsStateAlphaCode= <FIPS-5 state alpha code>
+ fipsStateNumericCode= <FIPS-5 state numeric code>
+
+ e.g.,
+
+ objectClass= usStateOrEquivalent
+ description= State of California
+ localityName= California
+ localityName= CA
+ fipsStateAlphaCode= CA
+
+
+
+NADF [Page 8]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ fipsStateNumericCode= 06
+
+4.3. The Local Level
+
+ Within each region, there are places. Each place corresponds to a
+ county or county-equivalent as recognized by the regional government.
+ The list of these is maintained in US FIPS 55 as a populated place
+ with a five-digit numeric place code starting with "99." A sample
+ entry from this FIPS document looks like this:
+
+ +---------+---------+-------+-----+----------------------+-----+
+ | State | Place | State | | | |
+ | Numeric | Numeric | Alpha | | FIPS-55 | |
+ | Code | Code | Code | | Name | |
+ +---------+---------+-------+-----+----------------------+-----+
+ | | | | | | |
+ | 06 | 99085 | CA | ... | Santa Clara (County) | ... |
+ | | | | | | |
+ +---------+---------+-------+-----+----------------------+-----+
+
+ (Any parenthetical text in the FIPS-55 name is considered a
+ "remark" about the place.)
+
+
+ Each county is modeled with an object of class
+ "usCountyOrEquivalent", which is defined thusly:
+
+ usPlace OBJECT-CLASS
+ SUBCLASS OF locality, nadfObject
+ MUST CONTAIN { localityName,
+ fipsPlaceNumericCode }
+
+ usCountyOrEquivalent OBJECT-CLASS
+ SUBCLASS OF usPlace
+ MUST CONTAIN { fipsCountyNumericCode }
+
+ Each entry is subordinate to the entry naming the region which
+ contains the county, and has an RDN consisting of a single
+ attribute value assertion:
+
+ localityName= <FIPS-55 name without remarks>
+
+ e.g.,
+
+ localityName= Santa Clara
+
+
+ Each entry (minimally) contains these attributes:
+
+
+
+NADF [Page 9]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ objectClass= usCountyOrEquivalent
+ fipsPlaceNumericCode= <FIPS-55 place numeric code>
+ fipsCountyNumericCode= <last three digits of FIPS-55
+ place code>
+ stateOrProvinceName= <FIPS-55 state alpha code>
+ stateOrProvinceName= <FIPS-5 corresponding name>
+ description= <FIPS-55 name with remarks>
+
+ e.g.,
+
+ objectClass= usCountyOrEquivalent
+ fipsPlaceNumericCode= 99085
+ fipsCountyNumericCode= 085
+ stateOrProvinceName= California
+ stateOrProvinceName= CA
+ description= County of Santa Clara
+
+ In addition, for each populated place named within the county,
+ a non-distinguished "localityName" attribute value may be
+ present to aid searching, e.g.,
+
+ localityName= Mountain View
+ localityName= San Jose
+
+ and so on.
+
+4.4. ADDMD Operators
+
+ Also within the nation, there are public Directory service providers.
+ Each service-provider corresponds to an ADDMD operator as recognized
+ by the NADF. Each ADDMD operator is modeled with an object of class
+ "nadfADDMD", which is defined thusly:
+
+ nadfADDMD OBJECT-CLASS
+ SUBCLASS OF nadfObject
+ MUST CONTAIN { addmdName }
+ MAY CONTAIN { organizationName,
+ organizationalAttributeSet }
+
+ Each entry is subordinate to "c=US", and has an RDN consisting of a
+ single attribute value assertion:
+
+ addmdName= <NADF registered name>
+
+ e.g.,
+
+ addmdName= PSINet
+
+
+
+
+NADF [Page 10]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ Each entry (minimally) contains this attribute:
+
+ objectClass= nadfADDMD
+
+ The structure of the subtree below each "nadfADDMD" entry is a matter
+ for that service-provider to establish. It must be emphasized that
+ such entries are used to provide a "private" namespace for each
+ service provider, as envisioned in NADF-128. This "nadfADDMD" entry
+ is distinct from a service provider's "organization" entry which
+ would be used to contain organizational information about the service
+ provider.
+
+4.5. Summary of Structuring Objects
+
+ To summarize the naming architecture thus far:
+
++---------------+-----+---------------------+-----+--------------------+
+| Level |Elem | objectClass |Supr | RDN |
++---------------+-----+---------------------+-----+--------------------+
+| root | 0 | | | |
++---------------+-----+---------------------+-----+--------------------+
+| international | 1 | country | 0 | countryName |
++---------------+-----+---------------------+-----+--------------------+
+| national | 2 | usStateOrEquivalent | 1 | stateOrProvinceName|
+| | 3 | nadfADDMD | 1 | addmdName |
++---------------+-----+---------------------+-----+--------------------+
+| regional | 4 | usCountyOrEquivalent| 2 | localityName |
++---------------+-----+---------------------+-----+--------------------+
+| local | 5 | ... | 4 | ... |
++---------------+-----+---------------------+-----+--------------------+
+
+ Or, in pictorial form:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NADF [Page 11]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ root
+ /
+ /
+ /
+ (----)
+ (c=US)
+ (----)
+ / | \
+ / | \
+ /------------/ | \------\
+ / | \
+ for each state or (------) / \ (---------) for
+ state-equivalent (st=...) / \ (addmd=...) each
+ (------) / \ (---------) ADDMD
+ / \ / \
+ / \ /national \
+ /------------/ \ / listings \
+ / \ -------------
+ / \
+ (-----) for each /\
+ (l=...) county or / \
+ (-----) county-equivalent / \
+ | / \
+ | /regional\
+ | / listings \
+ | ------------
+ / \
+ / \
+ / \
+ / local \
+ /listings \
+ -----------
+
+
+5. Entity Objects
+
+ The next step in using the civil naming infrastructure is to model
+ the entities which reside within the geographical/governmental
+ structure.
+
+5.1. Organizations
+
+ Organizations exist at several levels.
+
+5.1.1. Kinds of Organizations
+
+ An organization is said to have national-standing if it is chartered
+ (created and named) by the US Congress. An example of such an
+
+
+
+NADF [Page 12]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ organization might be a national laboratory. There is no other
+ entity which is empowered by government to confer national-standing
+ on organizations. However, ANSI maintains an alphanumeric nameform
+ registration for organizations, and this will be used as the public
+ directory service basis for conferring national-standing on private
+ organizations.
+
+ An organization is said to have regional-standing if it is chartered
+ by the government of that region. An example of such an organization
+ might be a public university. In addition, private organizations may
+ achieve regional-standing by registering with the "Secretary of
+ State" (or similar entity) within that region -- this is termed a
+ "doing business as" (DBA) registration.
+
+ NOTE:
+
+ An organization may have a DBA registration in several states,
+ even though it is incorporated in only one state. Where an
+ organization registers itself is largely dependent on where it
+ might choose to incorporate, and where it might choose to
+ locate (and license) its business operations.
+
+ For example, a large organization might have a DBA registration
+ in most of the 50 states, and be incorporated in Delaware. For
+ the purposes of this naming scheme, such an organization is
+ said to have regional-standing in each state where it has a DBA
+ registration. This DBA registration confers the sole right to
+ use the DBA name in association with the named jurisdiction of
+ the registration authority.
+
+ An organization is said to have local-standing if it is chartered by
+ a local government within that place. In addition, private
+ organizations may achieve local-standing by registering with a
+ "County Clerk" (or similar entity) within that place -- this is
+ termed a "doing business as" (DBA) registration. Note that local-
+ standing is somewhat ambiguous in that there may be multiple local
+ governments contained within a county or county-equivalent.
+ Depending on local government rules of incorporation and containment,
+ registering with one entity may prevent others from registering that
+ same name with other entities contained within that place. In order
+ to avoid ambiguity, other distinguishing attributes, such as
+ "streetAddress", may be needed to provide uniqueness.
+
+5.1.2. Modeling Organizations
+
+ In the DIT, an organization is modeled with an object of
+ class "organization". In addition, some combination of the
+ following auxiliary object classes might also be used:
+
+
+
+NADF [Page 13]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ (1) if an organization has national-standing derived from
+ ANSI registration, then this is modeled by including in
+ the entry an object class attribute value of
+ "ansiOrgObject", which is defined thusly:
+
+ ansiOrgObject OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN { ansiOrgNumericCode }
+
+
+ (2) if an organization has national-standing (either in the
+ US or some other nation), then it may be necessary to
+ identify the country which corresponds to the registry
+ which names the organization. This is modeled by
+ including in the entry an object class attribute value
+ of "nationalObject", which is defined thusly:
+
+ nationalObject OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN { countryName }
+
+
+ (3) if an organization has local-standing, then it may be
+ necessary to identify the place in US FIPS 55 which
+ corresponds to the registry which names the
+ organization. This is modeled by including in the
+ entry an object class attribute value of
+ "fips55Object", which is defined thusly:
+
+ fips55Object OBJECT-CLASS
+ SUBCLASS OF top
+ MUST CONTAIN { fipsPlaceNumericCode }
+ MAY CONTAIN { stateOrProvinceName }
+
+5.2. Persons
+
+ There are two kinds of entries for a person: organizational person
+ and residential person.
+
+ Definitions for an organizational person are a local matter to be
+ decided by each organization. It is suggested that an organizational
+ person be modeled with an object of class "organizationalPerson".
+
+ Outside of organizations, persons exist only in a residential context.
+ As such they always have local standing. For a given person, it
+ should always be possible to identify the place in US FIPS 55 which
+ corresponds to the "smallest" populated place where any person
+ resides, and then use the code associated with that place to aid in
+
+
+
+NADF [Page 14]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ distinguishing the person. A residential person is modeled with an
+ object of class "residentialPerson". In addition, since it may be
+ necessary to identify the place in US FIPS 55 which corresponds
+ to where the person resides, an object class attribute value
+ of "fips55Object" may be present in entries corresponding to
+ residential persons.
+
+6. Listing Entities
+
+ The final step is to define how entities are listed within the
+ context of the civil naming infrastructure. Note than an entity may
+ have several listings (DNs) in different parts of the Directory.
+
+6.1. Organizations
+
+ The RDN used when listing an organization depends on both the
+ standing of the organization, and where the listing is to be placed:
+
+ +----------------------------------------+
+ +-------------------| Listing (RDN) under |
+ | Entity | c=US | c=US, st=X | c=US, st=X, l=Y |
+ +-------------------+---------+------------+-----------------+
+ | national-standing | o | o, c=US | o, c=US |
+ +-------------------+---------+------------+-----------------+
+ | regional-standing | o, st=X | o | o |
+ +-------------------+---------+------------+-----------------+
+ | .. (other region) | | o, st=Z | o, st=Z |
+ +-------------------+---------+------------+-----------------+
+ | local-standing | o, st=X | o, fips55 | o, fips55 |
+ | | fips55 | | |
+ +-------------------+---------+------------+-----------------+
+ | .. (other region) | | o, st=Z | o, st=Z, fips55 |
+ | | | fips55 | |
+ +-------------------+---------+------------+-----------------+
+ | foreign-standing | o, ... | o, ..., c | o, ..., c |
+ | | c | | |
+ +-------------------+---------+------------+-----------------+
+
+ This scheme makes no requirements on the DIT structure within
+ an organization. However, the following naming architecture
+ is suggested:
+
+
+
+
+
+
+
+
+
+
+NADF [Page 15]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
++----------------+-----+----------------------+----------+-------------+
+| Level |Elem | objectClass | Super | RDN |
++----------------+-----+----------------------+----------+-------------+
+| listing | 11 | organization | 1,2,4 | |
++----------------+-----+----------------------+----------+-------------+
+| organizational | 12 | organizationalUnit | 11,12,13 | orgUnitName |
+| | 13 | locality | 11,12,13 | localityName|
+| | 14 | organizationalRole | 11,12,13 | commonName |
+| | 15 | organizationalPerson | 11,12,13 | commonName |
++----------------+-----+----------------------+----------+-------------+
+| application | 16 | applicationProcess | 11,12,13 | commonName |
+| | 17 | nadfApplicationEntity| 16 | commonName |
+| | 18 | groupOfNames | 11,12,13 | commonName |
+| | 19 | ediUser | 11,12,13 | ediName |
+| | 20 | device | 11,12,13 | commonName |
++----------------+-----+----------------------+----------+-------------+
+
+ Or, in pictorial form:
+
+ (------------)
+ (organization)
+ (------------)
+ |
+ |<------------------------------+
+ | |
+ +--->(organizationalUnit)-------+
+ | |
+ +--->(locality)-----------------+
+ |
+ +--->(organizationalRole)
+ |
+ +--->(organizationalPerson)
+ |
+ +--->(applicationProcess)--->(nadfApplicationEntity)
+ |
+ +--->(groupOfNames)
+ |
+ +--->(ediUser)
+ |
+ +--->(device)
+
+
+6.2. Persons
+
+ Listing organizational persons is a local matter to be decided by
+ each organization.
+
+ Residential persons are identified by the place where they reside,
+
+
+
+NADF [Page 16]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ usually with a multi-valued RDN consisting of a "commonName"
+ attribute value, and some other distinguished attribute value.
+ Although an obvious choice is to use something like "postalCode" or
+ "streetAddress", it should be noted that this information may be
+ considered private. Hence, some other, distinguishing attribute
+ value may be used -- possibly even a "serial number" attribute value
+ which has no other purpose other than to give uniqueness. (It should
+ be noted that an attribute of this kind is not helpful in regards to
+ searching -- other attribute values containing meaningful information
+ should be added to the entry and made available for public access, as
+ an aid to selection.)
+
+ The RDN used when listing residential persons depends on where the
+ listing is to be placed:
+
+ +----------------------------------------+
+ +-------------------| Listing (RDN) under |
+ | Entity | c=US | c=US, st=X | c=US, st=X, l=Y |
+ +-------------------+---------+------------+-----------------+
+ | residential | cn, ... | cn, ... | cn, ..., fips55 |
+ | person | st=X | fips55 | |
+ | | fips55 | | |
+ +-------------------+---------+------------+-----------------+
+ | .. (other region) | | cn, ... | cn, ..., st=Z |
+ | | | st=Z | fips55 |
+ | | | fips55 | |
+ +-------------------+---------+------------+-----------------+
+
+ Note that listing of foreign persons is for further study.
+
+7. Usage Examples
+
+ In the examples which follow, the "*"-character is used to denote any
+ arbitrary value for an attribute type.
+
+7.1. Organizations with National-Standing
+
+ Suppose that the organization
+
+ Lawrence Livermore National Laboratory
+
+ has national-standing by virtue of having been chartered by the US
+ Congress. According to the table in Section 6.1, this organization
+ has the right to list as any (or all) of these names:
+
+ (1) national-listing:
+
+ { c=US,
+
+
+
+NADF [Page 17]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ o=Lawrence Livermore National Laboratory }
+
+
+ (2) regional-listing:
+
+ { c=US, st=*,
+ { o=Lawrence Livermore National Laboratory,
+ c=US } }
+
+
+ (3) local-listing:
+
+ { c=US, st=*, l=*,
+ { o=Lawrence Livermore National Laboratory,
+ c=US } }
+
+ Suppose that the organization
+
+ Performance Systems International, Inc.
+
+ has national-standing by virtue of having an alphanumeric nameform in
+ the ANSI registry. According to the table in Section 6.1, this
+ organization has the right to list as any (or all) of these names:
+
+ (1) national-listing:
+
+ { c=US, o=Performance Systems International }
+
+
+ (2) regional-listing:
+ { c=US, st=*,
+ { o=Performance Systems International, c=US } }
+
+
+ (3) local-listing:
+
+ { c=US, st=*, l=*,
+ { o=Performance Systems International, c=US } }
+
+7.2. Organizations with Regional-Standing
+
+ Suppose that the organization
+
+ Network Management Associates, Inc.
+
+ has regional-standing by virtue of having a DBA registration with the
+ Secretary of State for the State of California. According to the
+ table in Section 6.1, this organization has the right to list as any
+
+
+
+NADF [Page 18]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ (or all) of these names:
+
+ (1) national-listing:
+
+ { c=US,
+ { o=Network Management Associates,
+ st=California } }
+
+
+ (2) regional-listing:
+
+ { c=US, st=California,
+ o=Network Management Associates }
+
+
+ (3) local-listing:
+
+ { c=US, st=California, l=*,
+ o=Network Management Associates }
+
+ Further, in some state other than California, this
+ organization might also list as:
+
+ (1) regional-listing:
+
+ { c=US, st=*,
+ { o=Network Management Associates,
+ st=California } }
+
+
+ (2) local-listing:
+
+ { c=US, st=*, l=*,
+ { o=Network Management Associates,
+ st=California } }
+
+7.3. Organizations with Local-Standing
+
+ Suppose that the tavern and eatery
+
+ St. James Infirmary
+
+ has local-standing by virtue of having a DBA registration with the
+ City Clerk for the City of Mountain View in the State of California.
+ According to the table in Section 6.1, this organization has the
+ right to list as any (or all) of these names:
+
+ (1) national-listing:
+
+
+
+NADF [Page 19]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ { c=US,
+ { o=St. James Infirmary, st=California,
+ fips55=49670 } }
+
+
+ (2) regional-listing:
+
+ { c=US, st=California,
+ { o=St. James Infirmary, fips55=49670 } }
+
+
+ (3) local-listing:
+
+ { c=US, st=California, l=*,
+ { o=St. James Infirmary, fips55=49670 } }
+
+ Further, in some state other than California, this
+ organization might also list as:
+
+ (1) regional-listing:
+
+ { c=US, st=*,
+ { o=St. James Infirmary, st=California,
+ fips55=49670 } }
+
+
+ (2) local-listing:
+
+ { c=US, st=*, l=*,
+ { o=St. James Infirmary, st=California,
+ fips55=49670 } }
+
+7.4. Organizations with Foreign-Standing
+
+ Suppose that the five-star restaurant
+
+ Erik's Fisk
+
+ has foreign-standing by virtue of having a DBA registration
+ throughout Sweden. According to the table in Section 6.1, this
+ organization has the right to list as any (or all) of these names:
+
+ (1) national-listing:
+
+ { c=US,
+ { o=Erik's Fisk, c=SE } }
+
+
+
+
+
+NADF [Page 20]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ (2) regional-listing:
+
+ { c=US, st=*,
+ { o=Erik's Fisk, c=SE } }
+
+
+ (3) local-listing:
+
+ { c=US, st=*, l=*,
+ { o=Erik's Fisk, c=SE } }
+
+7.5. Persons
+
+ Suppose that the person
+
+ Marshall T. Rose
+
+ residing in the City of Mountain View in the State of California,
+ wishes to be listed in the Directory. According to the table in
+ Section 6.2, this person might be listed as any of these names:
+
+ (1) national-listing:
+
+ { c=US,
+ { cn=Marshall T. Rose, postalCode=94043-2112,
+ st=California, fips55=49670 } }
+
+
+ (2) regional-listing:
+
+ { c=US, st=California,
+ { cn=Marshall T. Rose, postalCode=94043-2112,
+ fips55=49670 } }
+
+
+ (3) local-listing:
+
+ { c=US, st=California, l=Santa Clara,
+ { cn=Marshall T. Rose, postalCode=94043-2112 } }
+
+ Further, in some state other than California, this person
+ might also list as:
+
+ (1) regional-listing:
+
+ { c=US, st=*,
+ { cn=Marshall T. Rose, postalCode=94043-2112,
+ st=California, fips55=49670 } }
+
+
+
+NADF [Page 21]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ (2) local-listing:
+
+ { c=US, st=*, l=*,
+ { cn=Marshall T. Rose, postalCode=94043-2112,
+ st=California, fips55=49670 } }
+
+8. 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 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.
+
+Appendix A: 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 22]
+
+RFC 1255 A Naming Scheme for c=US September 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
+ NADF at its March 18-22, 1991 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 fifth version of this scheme (NADF-123) was produced at the NADF
+ meeting (and also published in the Internet community as RFC1212).
+ This version generalized the listing concept by introducing the
+ notion of optimized civil naming. Further, the document was edited
+ to clearly note the different naming sub-structures and the relation
+ between them.
+
+ The sixth version of this scheme (NADF-143) was contributed to the
+ NADF before its July 9-12, 1991 meeting, and was edited to reflect
+ comments received from the Internet and other communities. The
+ changes were:
+
+ (1) The schema definitions were removed from Appendix A and
+ placed in a separate document, NADF-132. In NADF-132:
+
+
+
+NADF [Page 23]
+
+RFC 1255 A Naming Scheme for c=US September 1991
+
+
+ the prefix object-identifier was changed (the original
+ assignment was in error); and, the definition of a
+ "nadfADDMD" object was considerably expanded.
+
+ (2) States and state-equivalents are now named using
+ attribute values of "stateOrProvinceName".
+
+ (3) Populated places now correspond to counties, though
+ FIPS 55 is still used extensively.
+
+ (4) The text of this document was reworked to more clearly
+ distinguish between registration and listing.
+
+ (5) The "foreignOrganization" and "fips55Object" object
+ classes were added.
+
+ The seventh version of this scheme (NADF-166) was produced at
+ the NADF meeting. It made a few changes:
+
+ (1) It was noted that organizations with local standing may
+ need additional distinguishing attributes when listing.
+
+ (2) The "usOrganization" object class was removed and
+ replaced with the auxiliary object class
+ "ansiOrgObject".
+
+ (3) The "foreignOrganization" object class was removed and
+ replaced with the auxiliary object class
+ "nationalObject". This may be used when listing any
+ organization of national standing (regardless of
+ whether that organization is US-based). For example,
+ an organization with US national-standing would need
+ this when being listed at the regional or local level.
+
+ (4) Figures corresponding to the DIT structures were added,
+ along with some minor additional text in the usage
+ examples.
+
+ (5) The Acknowledgements section, long out of date, was
+ removed.
+
+ The eighth (current) version of this scheme was produced after
+ the NADF meeting. It corrects a few typographical errors.
+
+
+
+
+
+
+
+
+NADF [Page 24]
+
+RFC 1255 A Naming Scheme for c=US September 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 25]
+ \ No newline at end of file