As per Relevance of the word registration, we have this rfc below:











Network Working Group The North American Directory
Request for Comments: 1255 September 1991
Obsoletes: RFC 1218


A Naming Scheme for c=

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited



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
offer, public Directory services in North America, based on the
X.500 Recommendations. As a part of its charter, the NADF must
agreement as to how entries are named in the public portions of
North American Directory. NADF-175 represents the NADF's
in this area

Table of

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=
The North American Directory
Supercedes: NADF-166, 143, 123, 103, 71
July 12, 1991

1.

Computer networks form the infrastructure between the users
interconnect, and networks are built on an underlying naming
numbering infrastructure, usually in the form of names and addresses
For example, some authority must exist to assign network addresses
ensure that numbering collisions do not occur. This is of
importance for an environment which consists of multiple
providers

2.

It should be observed that there are several different
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
largely determines the difficulty in mapping a user's query into
series of Directory operations to find useful information.
it is possible to simultaneously support multiple naming
with the DIT, this is likely to be unnatural. As such, this
focuses on a single naming universe

The naming universe in this scheme is based on civil authority.
is, it uses the existing civil naming infrastructure and suggests
(nearly) straight-forward mapping on the DIT. An
characteristic is that entries can be listed wherever searches
them are likely to occur. This implies that a single object may
listed as several separate entries






NADF [Page 2]

RFC 1255 A Naming Scheme for c=US September 1991


2.1. Names and User-

It must be emphasized that there are two distinct concepts which
often confused when discussing a naming scheme

(1) user-friendly naming
a property of a Directory which allows users to
identity objects of interest; and


(2) Distinguished Name
the administratively assigned name for an entry in
OSI Directory

It must be emphasized that Distinguished Names are not
user-friendly names, and further, that user-friendly naming in
Directory is a property of the Directory Service, not
Distinguished Names

2.2. Choice of RDN

The key aspect to appreciate for choice of RDNs is that they
provide a large name space to avoid collisions: the naming
must provide enough "real estate" to accommodate a large demand
Distinguished Names. This is the primary requirement for RDNs.
secondary requirement is that RDNs should be meaningful (friendly
people) and should not impede searching

However, it is important to understand that this second
can be achieved by using additional (non- distinguished)
values. For example, if the RDN of an entry

organizationName is Performance Systems

then it is perfectly acceptable (and indeed desirable) to have
values for the "organizationName" attribute, e.g.,

organizationName is

The use of these abbreviated names greatly aids searching
avoiding unnecessary Distinguished Name conflicts

In order to appreciate the naming scheme which follows, it
important to understand that wherever possible it leverages
naming infrastructure. That is, it relies heavily on non-OSI
authorities which already exist. Note that inasmuch as it relies
existing naming authorities, there is little chance that any "final
national decision could obsolete this scheme. (Any naming scheme



NADF [Page 3]

RFC 1255 A Naming Scheme for c=US September 1991


be subject to the jurisdiction of certain national agencies.
example, the US State Department is concerned with any impact on
telecommunications treaty obligations.) To do so would require
national decision that disregards existing national and
infrastructure, and establishes some entirely new and
national naming infrastructure

2.3. Outline of the

The naming scheme is divided into four parts

(1) a discussion of the right-to-use, registration,
publication concepts

(2) a discussion of objects with national, regional, local
and foreign standing

(3) a discussion of objects which may be listed
national, regional, and local levels; and

(4) a discussion of how RDNs are formed for listing
at each different level

3. The Naming

There are three stages to the naming process

3.1. Right-To-

First, a naming authority must establish the right-to-use for
name to be used, within the jurisdiction of the given
authority. Names that are used in public are generally
by public laws. Names that are only used in private are a
matter. We are primarily concerned here with public names
these are the names that are most interesting to enter into
directories where we can search for them

There is a global governmental/civil/organizational
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
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
authorities that we will call naming authorities. Naming
tend toward hierarchical organization. Parents have
(granted by government) to choose the names of new-born children,
courts have authority to change a person's name, car makers
authority to name the models of cars they build (within the limits
trademarking law), and they are obligated to assign unique
numbers to each car. Cities assign names to their streets
districts, states assign city, county, and township names, and so on
State governments also assign names to "registered"
that operate under state charters, which in turn name their
suborganizations. Cities and Counties license businesses to
their chosen (unambiguous) names "in association with" the city
county names. Companies name and number the computers
communications devices they make and sell. There are many many
spaces, some of which are subordinate to others, and some of
are independent

Public names must be "registered" in some "public record" to
the fact of the assignment of the right-to-use to specific "owners."
In general, this is to prevent collisions of the right-to-
assignments in public shared name spaces. For example, unique
given to corporations are registered by the state of incorporation
A request to use a new name for any corporation must not
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
Service. The right-to-use for a name is always derived from
other (non-directory) source of authority because of the
aspects of intellectual property rights which are entirely
the scope of directory service specifications. People
organizations attach great value to the names they are allowed
associate with their lives and businesses, and intellectual
law protects their interests with respect to these values

This is not to say that directory service designers and
have no interest in the processes and procedures for establishment
the right-to-use for the names that will be entered into
directory. Indeed, without a supply of rightfully-usable names
there cannot be any directory. But, given an adequate supply
registered names, the directory service is not otherwise concerned

We should note here that some naming authorities must deal with
spaces that are shared among large communities (such as
networks) in which collisions will occur among applicants for
name assignments, while other name spaces (such as for given names
children in a family) are not shared outside the family. Sharing



NADF [Page 5]

RFC 1255 A Naming Scheme for c=US September 1991


always a problem, which has led to trademarking laws,
license laws, and so on. Naming within organizations should
easier, because it is "in the family," so to speak.
naming schemes facilitate distribution of naming authority

3.2.

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
which has an inherited surname and, more or less, has the right
use any names it pleases for its children's given names, must
selected names to selected object attributes (e.g., firstname=Einar).
Note that this same name might also be used as the first name
middle name of other children, as long as each sequence of
names of each family member is distinguished (i.e., none
duplicates) within the family. Wise families do not bind the
sequence of given names to more than one child. Some avoid
multiple use of a single name. Some use generational qualifiers
prevent parent-child conflicts

The Internet Domain Name System (DNS) names top level domains
are then free (within some technical limits) to chose and bind
to entries which are subordinate to a given named domain, and
forth down the DNS name tree. The ISO/CCITT naming system serves
same purposes in other separate name spaces

3.3.

Third, after binding, a name must be advertised or published in
community if it is to be referenced by others. If it is
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)
are bound to the attributes of the entries in the directory DIT
Historically speaking, the directory business is a subclass of
publishing business, serving to dereference names into
about what they stand for

It is important to keep in mind that a directory "listing entry"
not a "registration" unless a particular segment of the
also just happens to be the authoritative master register of
naming authority. Registration and listing are very
service functions, though it is conceivable that they might
combined in a single DIT

For example, in the United States of America, each state name



NADF [Page 6]

RFC 1255 A Naming Scheme for c=US September 1991


registered by the Congress by inclusion of the name in
legislation that "admits each State into the Union." Note
that the name is also then published in many places (such as on
and in directories), while the master "register" is kept with
other original records of laws enacted by the Congress and signed
the President. Also, the name is then entered (listed) in
directories, in association with the name "The United States
America." And so on down the civil naming tree, with entities
in each state, etc. It is certainly not the case that the
National Standards Institute (ANSI) registers the names of the
in the United States of America! That right and duty is
reserved to the Government of the United States of America

On the other hand, in the Internet DNS, the act of inserting a
rightfully-usable name and address entry into a
constitutes simultaneous registration and directory publication

4. Structuring

The first step in providing a civil naming infrastructure is to
the geographical/governmental entities which provide a basis for
assignment of public names

4.1. The National

The nation is modeled with an object of class "country",
to the root of the DIT, and has an RDN consisting of a
attribute value assertion

countryName=

The entry (minimally) contains these attributes

objectClass=
description= United States of

4.2. The Regional

Within the nation, there are regions. Each region corresponds to
state or state-equivalent as recognized by the US Congress. The
of these is maintained in US FIPS 5. A sample entry from this
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
"usStateOrEquivalent", which is defined thusly

usStateOrEquivalent OBJECT-
SUBCLASS OF locality,
MUST CONTAIN { localityName
fipsStateNumericCode
fipsStateAlphaCode
stateOrProvinceName }



Each entry is subordinate to "c=US", and has an RDN
of a single attribute value assertion

stateOrProvinceName=
e.g.,

stateOrProvinceName=


Each entry (minimally) contains these attributes

objectClass=
description= <official name of region
localityName= localityName= fipsStateAlphaCode= fipsStateNumericCode=
e.g.,

objectClass=
description= State of
localityName=
localityName=
fipsStateAlphaCode=



NADF [Page 8]

RFC 1255 A Naming Scheme for c=US September 1991


fipsStateNumericCode= 06

4.3. The Local

Within each region, there are places. Each place corresponds to
county or county-equivalent as recognized by the regional government
The list of these is maintained in US FIPS 55 as a populated
with a five-digit numeric place code starting with "99." A
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
"remark" about the place.)


Each county is modeled with an object of
"usCountyOrEquivalent", which is defined thusly

usPlace OBJECT-
SUBCLASS OF locality,
MUST CONTAIN { localityName
fipsPlaceNumericCode }

usCountyOrEquivalent OBJECT-
SUBCLASS OF
MUST CONTAIN { fipsCountyNumericCode }

Each entry is subordinate to the entry naming the region
contains the county, and has an RDN consisting of a
attribute value assertion

localityName=
e.g.,

localityName= Santa


Each entry (minimally) contains these attributes



NADF [Page 9]

RFC 1255 A Naming Scheme for c=US September 1991


objectClass=
fipsPlaceNumericCode= fipsCountyNumericCode= place code
stateOrProvinceName= stateOrProvinceName= corresponding name
description=
e.g.,

objectClass=
fipsPlaceNumericCode= 99085
fipsCountyNumericCode= 085
stateOrProvinceName=
stateOrProvinceName=
description= County of Santa

In addition, for each populated place named within the county
a non-distinguished "localityName" attribute value may
present to aid searching, e.g.,

localityName= Mountain
localityName= San

and so on

4.4. ADDMD

Also within the nation, there are public Directory service providers
Each service-provider corresponds to an ADDMD operator as
by the NADF. Each ADDMD operator is modeled with an object of
"nadfADDMD", which is defined thusly

nadfADDMD OBJECT-
SUBCLASS OF
MUST CONTAIN { addmdName }
MAY CONTAIN { organizationName
organizationalAttributeSet }

Each entry is subordinate to "c=US", and has an RDN consisting of
single attribute value assertion

addmdName= registered name

e.g.,

addmdName=




NADF [Page 10]

RFC 1255 A Naming Scheme for c=US September 1991


Each entry (minimally) contains this attribute

objectClass=

The structure of the subtree below each "nadfADDMD" entry is a
for that service-provider to establish. It must be emphasized
such entries are used to provide a "private" namespace for
service provider, as envisioned in NADF-128. This "nadfADDMD"
is distinct from a service provider's "organization" entry
would be used to contain organizational information about the
provider

4.5. Summary of Structuring

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



/
/
/
(----)
(c=US
(----)
/ | \
/ | \
/------------/ | \------\
/ | \
for each state or (------) / \ (---------)
state-equivalent (st=...) / \ (addmd=...)
(------) / \ (---------)
/ \ / \
/ \ /national \
/------------/ \ / listings \
/ \ -------------
/ \
(-----) for each /\
(l=...) county or / \
(-----) county-equivalent / \
| / \
| /regional
| / listings \
| ------------
/ \
/ \
/ \
/ local \
/listings \
-----------


5. Entity

The next step in using the civil naming infrastructure is to
the entities which reside within the geographical/
structure

5.1.

Organizations exist at several levels

5.1.1. Kinds of

An organization is said to have national-standing if it is
(created and named) by the US Congress. An example of such



NADF [Page 12]

RFC 1255 A Naming Scheme for c=US September 1991


organization might be a national laboratory. There is no
entity which is empowered by government to confer national-
on organizations. However, ANSI maintains an alphanumeric
registration for organizations, and this will be used as the
directory service basis for conferring national-standing on
organizations

An organization is said to have regional-standing if it is
by the government of that region. An example of such an
might be a public university. In addition, private organizations
achieve regional-standing by registering with the "Secretary
State" (or similar entity) within that region -- this is termed
"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
organization registers itself is largely dependent on where
might choose to incorporate, and where it might choose
locate (and license) its business operations

For example, a large organization might have a DBA
in most of the 50 states, and be incorporated in Delaware.
the purposes of this naming scheme, such an organization
said to have regional-standing in each state where it has a
registration. This DBA registration confers the sole right
use the DBA name in association with the named jurisdiction
the registration authority

An organization is said to have local-standing if it is chartered
a local government within that place. In addition,
organizations may achieve local-standing by registering with
"County Clerk" (or similar entity) within that place -- this
termed a "doing business as" (DBA) registration. Note that local
standing is somewhat ambiguous in that there may be multiple
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
same name with other entities contained within that place. In
to avoid ambiguity, other distinguishing attributes, such
"streetAddress", may be needed to provide uniqueness

5.1.2. Modeling

In the DIT, an organization is modeled with an object
class "organization". In addition, some combination of
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
ANSI registration, then this is modeled by including
the entry an object class attribute value
"ansiOrgObject", which is defined thusly

ansiOrgObject OBJECT-
SUBCLASS OF
MUST CONTAIN { ansiOrgNumericCode }


(2) if an organization has national-standing (either in
US or some other nation), then it may be necessary
identify the country which corresponds to the
which names the organization. This is modeled
including in the entry an object class attribute
of "nationalObject", which is defined thusly

nationalObject OBJECT-
SUBCLASS OF
MUST CONTAIN { countryName }


(3) if an organization has local-standing, then it may
necessary to identify the place in US FIPS 55
corresponds to the registry which names
organization. This is modeled by including in
entry an object class attribute value
"fips55Object", which is defined thusly

fips55Object OBJECT-
SUBCLASS OF
MUST CONTAIN { fipsPlaceNumericCode }
MAY CONTAIN { stateOrProvinceName }

5.2.

There are two kinds of entries for a person: organizational
and residential person

Definitions for an organizational person are a local matter to
decided by each organization. It is suggested that an
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,
should always be possible to identify the place in US FIPS 55
corresponds to the "smallest" populated place where any
resides, and then use the code associated with that place to aid



NADF [Page 14]

RFC 1255 A Naming Scheme for c=US September 1991


distinguishing the person. A residential person is modeled with
object of class "residentialPerson". In addition, since it may
necessary to identify the place in US FIPS 55 which
to where the person resides, an object class attribute
of "fips55Object" may be present in entries corresponding
residential persons

6. Listing

The final step is to define how entities are listed within
context of the civil naming infrastructure. Note than an entity
have several listings (DNs) in different parts of the Directory

6.1.

The RDN used when listing an organization depends on both
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
an organization. However, the following naming
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.

Listing organizational persons is a local matter to be decided
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"
"streetAddress", it should be noted that this information may
considered private. Hence, some other, distinguishing
value may be used -- possibly even a "serial number" attribute
which has no other purpose other than to give uniqueness. (It
be noted that an attribute of this kind is not helpful in regards
searching -- other attribute values containing meaningful
should be added to the entry and made available for public access,
an aid to selection.)

The RDN used when listing residential persons depends on where
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

In the examples which follow, the "*"-character is used to denote
arbitrary value for an attribute type

7.1. Organizations with National-

Suppose that the

Lawrence Livermore National

has national-standing by virtue of having been chartered by the
Congress. According to the table in Section 6.1, this
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

Performance Systems International, Inc

has national-standing by virtue of having an alphanumeric nameform
the ANSI registry. According to the table in Section 6.1,
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-

Suppose that the

Network Management Associates, Inc

has regional-standing by virtue of having a DBA registration with
Secretary of State for the State of California. According to
table in Section 6.1, this organization has the right to list as



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,
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-

Suppose that the tavern and

St. James

has local-standing by virtue of having a DBA registration with
City Clerk for the City of Mountain View in the State of California
According to the table in Section 6.1, this organization has
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,
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-

Suppose that the five-star

Erik's

has foreign-standing by virtue of having a DBA
throughout Sweden. According to the table in Section 6.1,
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.

Suppose that the

Marshall T.

residing in the City of Mountain View in the State of California
wishes to be listed in the Directory. According to the table
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
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.

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
Columbia and Outlying Areas of the United States,
Associated Areas, US Department of Commerce FIPS 5-2,
28, 1987.

US FIPS 55:
Guideline: Codes for Named Populated Places, Primary
Divisions, and other Locational Entities of the
States and Outlying Areas, US Department of Commerce
55-2, February 3, 1987.

Appendix A: Revision History of this

The first version of this scheme (NADF-71) was contributed to
North American Directory Forum at its November 27-30, 1990 meeting
The (mis)features were

(1) Because of the lack of confidence in ANSI
procedures, it was proposed that the US trademarks
used as the basis for RDNs of organizations
national-standing
This proved unworkable since the same trademark may
issued to different organizations in
industries

(2) There was no pre-existing registry used for
places
This proved unworkable since the effort to define a
registry is problematic

The second version of this scheme was contributed to the
Registration Authority Committee at its January 30, 1991 meeting,
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
basis for RDNs of organizations with
standings

(2) The FIPS 5 state numeric code was used as the basis
RDNs of states and state-equivalents

(3) The FIPS 55 place numeric code was used as the
for RDNs of populated places

The choice of numeric rather than alphanumeric name forms
unpopular, but was motivated by the desire to avoid using the
alphanumeric name form registry, which was perceived as unstable

The third version of this scheme was contributed to US
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
will prove stable. If the ANSI alphanumeric name form
proves unstable, then two alternatives are possible

(1) disallow organizations with national-standing in the
portion of the DIT; or

(2) use the ANSI numeric name form registry instead

Hopefully neither of these two undesirable alternatives will
necessary

The fourth version of this scheme (NADF-103) was contributed to
NADF at its March 18-22, 1991 meeting. This version introduced
notion of organizations with regional standing being listed at
national level through the use of alias names and multi-valued RDNs

The fifth version of this scheme (NADF-123) was produced at the
meeting (and also published in the Internet community as RFC1212).
This version generalized the listing concept by introducing
notion of optimized civil naming. Further, the document was
to clearly note the different naming sub-structures and the
between them

The sixth version of this scheme (NADF-143) was contributed to
NADF before its July 9-12, 1991 meeting, and was edited to
comments received from the Internet and other communities.
changes were

(1) The schema definitions were removed from Appendix A
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
assignment was in error); and, the definition of
"nadfADDMD" object was considerably expanded

(2) States and state-equivalents are now named
attribute values of "stateOrProvinceName".

(3) Populated places now correspond to counties,
FIPS 55 is still used extensively

(4) The text of this document was reworked to more
distinguish between registration and listing

(5) The "foreignOrganization" and "fips55Object"
classes were added

The seventh version of this scheme (NADF-166) was produced
the NADF meeting. It made a few changes

(1) It was noted that organizations with local standing
need additional distinguishing attributes when listing

(2) The "usOrganization" object class was removed
replaced with the auxiliary object
"ansiOrgObject".

(3) The "foreignOrganization" object class was removed
replaced with the auxiliary object
"nationalObject". This may be used when listing
organization of national standing (regardless
whether that organization is US-based). For example
an organization with US national-standing would
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
examples

(5) The Acknowledgements section, long out of date,
removed

The eighth (current) version of this scheme was produced
the NADF meeting. It corrects a few typographical errors








NADF [Page 24]

RFC 1255 A Naming Scheme for c=US September 1991


Security

Security issues are not discussed in this memo

Author's

North American Directory
c/o Theodore H.
Rapport Communication, Inc
3055 Q Street
Washington, DC 20007

Tel: +1 202-342-2727






































NADF [Page 25]







if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum