As per Relevance of the word organization, we have this rfc below:
Network Working Group The North American Directory
Request for Comments: 1218 April 1991
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-123,
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-123 is a scheme proposed for
purpose. The NADF is circulating NADF-123 widely, expressly for
purpose of gathering comments. The next meeting of the NADF is
mid-July, and it is important for comments to be received prior
the meeting, so that the scheme may receive adequate review
A Naming Scheme for c=
The North American Directory
NADF-123
Supercedes: NADF-103, NADF-71
March 21, 1991
This is one of a series of documents produced for discussion
the North American Directory Forum. Distribution, with attribution
is unlimited. This document is being circulated for comment.
deadline for comments is July 1, 1991. Comments should be
to the contact given on page 16.
1.
Computer networks form the infrastructure between the users
interconnect. For example, the electronic mail service offered
computer networks provides a means for users to collaborate
some common goal. In the simplest cases, this collaboration may
solely for the dissemination of information. In other cases,
NADF [Page 1]
RFC 1218 A Naming Scheme for c=US April 1991
users may work on a joint research project, using electronic mail
their primary means of communication
However, networks themselves 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 can be realized in the Directory Information
(DIT). For example, geographical naming, community naming,
naming, organizational naming, and so on. The choice of
universe largely determines the difficulty in mapping a user's
into a series of Directory operations. Although it is possible
simultaneously support multiple naming universes with the DIT,
is likely to be unnatural. As such, this proposal focuses on
single naming universe
The naming universe in this proposal is based on civil authority
That is, it uses the existing civil naming infrastructure
suggests a (nearly) straight-forward mapping on the DIT. There
four components to the naming architecture
(1) civil naming and optimized civil naming, which
names assigned by civil authority
(2) organizational naming, which reflects names
within organizations
(3) ADDMD naming, which reflects names assigned to
providers within the Directory service; and
(4) application naming, which reflects names assigned to
entities
An important characteristic is that entries should be listed
searches for them are likely to occur. This implies that a
object may be listed under several entries
2.1. Names and User-
It must be emphasized that there are three distinct concepts
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
allows users to easily identity objects
(2) user-friendly name: a technique for naming an
which exhibits "friendliness" according to an
set of user-criteria; and
(3) Distinguished Name: the administratively assigned
for an entry in the 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
entries. This is the primary requirement for RDNs. A
requirement is that RDNs should be meaningful (friendly to 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 it leverages, wherever possible
existing naming infrastructure. That is, it relies heavily on non
OSI naming authorities which already exist. Note that inasmuch as
relies on existing naming authorities, there is little chance
any "final" national decision could obsolete it. [Footnote:
naming scheme may be subject to the jurisdiction of certain
agencies. For example, the US State Department is concerned with
impact on US telecommunications treaty obligations.] (To do so
require a national decision that disregards existing national
NADF [Page 3]
RFC 1218 A Naming Scheme for c=US April 1991
regional infrastructure, and establishes some entirely new
different national naming infrastructure.)
3. Civil
Civil naming occurs at three levels
(1) the national level, which contains objects that
recognized throughout a country
(2) the regional level, which contains objects that
recognized throughout a state or state-equivalent; and
(3) the local level, which contains objects that
recognized within a populated place
3.1. Naming at the National
At the national-level (at least) three kinds of names may be listed
(1) The States and State-
(2) Organizations with National
(3) ADDMD
3.1.1. The States and State-
For each state or state-equivalent (the District of Columbia and
eight outlying areas [Footnote: i.e., American Samoa,
States of Micronesia, Guam, Marshall Islands, Northern
Islands, Palau, Puerto Rico, and Virgin Islands of the US.]),
instance of
object is used. The RDN is formed
localityName is
e.g.,
localityName is
provides the RDN for the State of California. In addition,
entry would contain attributes identifying both the FIPS 5 alpha
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
Of course, this entry could contain many other attributes such
stateOrProvinceName is State of
3.1.2. Organizations with National
There is no authority in the United States which
registers the alphanumeric names of organizations with
standing. It is proposed that ANSI provide this registry and
the ANSI alphanumeric name form be used as the basis for RDNs
For each organization with national standing, an instance of
object is used. The RDN is formed
organizationName is
e.g.,
organizationName is Performance Systems
In addition, this entry would contain attributes identifying the
Alphanumeric name form, e.g.,
ansiOrgNumericCode is 177777
Of course, this entry would contain many other attributes such
organizationName is
For the National Government, an instance of
object is also used, and the RDN is taken from the ANSI
name form registry
3.1.3. ADDMD
There is no authority in the United States which
registers the names of ADDMD operators. It is expected that
North American Directory Forum will coordinate with the US
National Committee Study Group D to provide this registry. (
NADF [Page 5]
RFC 1218 A Naming Scheme for c=US April 1991
worst, the ADDMDs can use ANSI alphanumeric name forms for their
attribute values.)
For each ADDMD operator, an instance of
object is used. The RDN is formed
addmdName is registered name
e.g.,
addmdName is
3.2. Naming within a State or State-
At the regional level (at least) two kinds of names may be listed
(1) Populated
(2) Organizations with Regional
3.2.1. Populated
For each populated place within a state or state-equivalent
an instance of
object is used. The RDN is formed
localityName is
e.g.,
localityName is
provides the RDN for the Hartford entry immediately subordinate
the usStateOrEquivalent entry for the State of Connecticut.
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
An organization is said to have regional standing if it is
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
object is used. The RDN is formed
organizationName is <registered name of organization
e.g.,
organizationName is Network Management
might provide the RDN for a business entity registered with the
of California. In this case, the entry thus named would
immediately subordinate to the usStateOrEquivalent entry for
State of California
Note that other non-distinguished attributes, such as an ANSI
name form value, may be included in such an entry ---
organization object might actually be a usOrganization object
For the Regional Government, an instance of
object is also used. The RDN is formed as
organizationName is
3.3. Naming within a Populated
At the local level (at least) three kinds of names may be listed
(1)
(2) Organizations with Local
(3) MHS Distribution
NADF [Page 7]
RFC 1218 A Naming Scheme for c=US April 1991
3.3.1. Naming of
Within a populated place, there is no centralized naming entity
registers residential persons. It is proposed that entries
persons be immediately subordinate to the usPlace object which
accurately reflects their place of residence
For each person (wishing to have an entry in the Directory),
instance of a
object is used. The RDN is usually multi-valued, formed
commonName is
and some other attribute, such as postalCode, streetAddress, etc
However, because streetAddress is often considered
information, based on agreement with the entity managing the DMD
the listed person, some other, distinguishing attribute may be used
including a "serial number" (having no other purpose). It should
noted however that this is non-helpful in regards to searching
unless other attribute values containing meaningful information
added to the entry and made available for public access
3.3.2. Organizations with Local
An organization is said to have local standing if it is
with the County or City Clerk or similar entity within that
as an entity "doing business" in that place
For each organization with local standing, an instance of
object is used. The RDN is formed
organizationName is <registered name of organization
e.g.,
organizationName is The Tied
might provide the RDN for a business entity registered with the
of Mountain View. In this case, the entry thus named would
immediately subordinate to the usPlace entry for the City of
View
NADF [Page 8]
RFC 1218 A Naming Scheme for c=US April 1991
Note that other non-distinguished attributes, such as an ANSI
name form value, may be included in an entry. (That is,
organization object might actually be a usOrganization object.)
For the Local Government, if any, an instance of
object is also used. The RDN is formed as
organizationName is
3.4. Naming of MHS Distribution
Naming of MHS distribution lists remains with the scoping DMD
4. Optimized Civil
The structure of the civil component of the architecture can
concisely described as
----------------------------------------------------------------------
Level Element objectClass Superior
----------------------------------------------------------------------
root 0
----------------------------------------------------------------------
intl. 1 country 0
----------------------------------------------------------------------
natl. 2 usStateOrEquivalent 1
3 usOganization 1
4 nadfADDMD 1
----------------------------------------------------------------------
reg. 5 usPlace 2
6 organization 2
----------------------------------------------------------------------
local 7 residentialPerson 5 commonName
8 organization 5
9 mhsDistributionList 5
----------------------------------------------------------------------
Consider how an interrogation algorithm might locate a
person, given
(1) a string denoting the person's real-world name
(2) a string denoting the real-world name of the
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
locate the desired populated place. The search results in zero
more Distinguished Names being returned which correspond to
string provided by the user. Then, for each populated place,
subtree search might be initiated to locate the desired
person. If the number of populated places returned by the
search is large, then this strategy is inefficient
A better approach would be to initiate a single search, with a
combining the strings for both the person's real-world name and
place's real-world name. Unfortunately, such a search would have
involve the whole-subtree anchored at the Distinguished Name for
state or state-equivalent, which would be inefficient
As such, it may be desirable to optimize the civil naming
by listing some entries at a higher level. This is accomplished
using a multi-valued RDN formed by combining the RDNs of the
and its superior
There are three cases in civil naming
(1) listing an organization with regional standing at
national level
(2) listing an organization with local standing at
regional level; and
(3) listing a person with local standing at the
level
Hence, under the optimized civil naming component, a single-
search, anchored at the Distinguished Name for the state or state
equivalent, could be used. Further, the implementation of a
supporting this optimization would highly-index the attributes
for searching, in order to achieve high-performance
In order to clearly indicate that optimized civil naming is
effect, a new attribute type, nadfSearchGuide, is introduced.
attribute value of this type is placed in an entry to indicate
optimizations are in effect. Using the residential example above
the entry for the state or state-equivalent would contain
nadfSearchGuide value indicating that when searching for entries
type residentialPerson, a single-level search should be
with a filter containing the logical-and of two terms, one
the commonName attribute, and the other involving the
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
be performed, and always contains an indication of the object
for which the optimization exists
Finally, note that for naming within organizations, this
might also be used
4.1. Naming at the National
4.1.1. Organizations with Regional
An organization with standing within a state or state-equivalent
be listed directly under c=US
For an organization with regional standing, an instance of
object is used. The RDN is multi-valued, formed
organizationName is <registered name of organization
localityName is
e.g.,
organizationName is Network Management
localityName is
It must be emphasized that uniqueness within the RDN comes from
the a regional localityName (state or state-Equivalent)
association with the correspondent organizationName in that region
4.2. Naming within a State or State-
4.2.1. Organizations with Local
An organization with standing within a populated place may be
directly under its state or state-equivalent
For an organization with local standing, an instance of
object is used. The RDN is multi-valued, formed
organizationName is <registered name of organization
localityName is
NADF [Page 11]
RFC 1218 A Naming Scheme for c=US April 1991
e.g.,
organizationName is The Tied
localityName is City of Mountain
It must be emphasized that uniqueness within the RDN comes from
the a local localityName (populated place) in association with
correspondent organizationName in that place
4.2.2.
An person may be listed directly under its state or state-equivalent
For such a person, an instance of
object is used. The RDN is multi-valued, formed by taking the RDN
the person and adding the RDN of the populated place containing
person
commonName is the Marshall T.
postalCode is 94043-2112
localityName is City of Mountain
Note that for optimization to occur, the RDN of the person must
contain a localityName attribute value
5. Organizational
The internal structure of each usOrganization or organization
is a matter for that organization to establish
It is strongly recommended that organizationalUnit objects be
for structuring. (If an organization uses a locality-
organizational hierarchy, this information can still be
using
object.)
6. ADDMD
The internal structure of each nadfADDMD object is a matter for
service-provider to establish
NADF [Page 12]
RFC 1218 A Naming Scheme for c=US April 1991
7. Application
There are (at least) four kinds of OSI entities which may be listed
(1) Application Processes and
(2) MHS Distribution
(3) EDI
(4)
7.1. Naming of Application Processes and
Naming of OSI application processes and entities remains with
scoping DMD. However, in order to foster interoperability,
requirements are made: first, application entity objects must
immediately subordinate to application process objects; and, second
application entities are represented by the
object, which is identical to the applicationEntity object
that the presence of an attribute value
supportedApplicationContext is mandatory
7.2. Naming of MHS Distribution
Naming of MHS distribution lists remains with the scoping DMD
7.3. Naming of EDI
Naming of EDI users remains with the scoping DMD
7.4. Naming of
Naming of OSI devices remains with the scoping DMD
8. Usage
Consider the following examples, expressed in a concise format (
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
California
{ c=US
l=California
o=Network Management Associates, Inc. }
An optimized listing for a organization with
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.
This document is based on many sources, including, but not
to
- Listing Services Database Generic Requirements,
TA-TSY-000985;
- Common Directory Use ED 013 (Q/511) (EWOS/EGDIR/90/156);
and
- The THORN X.500 Naming Architecture (UCL-45 revision 6.1).
NADF [Page 15]
RFC 1218 A Naming Scheme for c=US April 1991
10.
X.500: The Directory --- Overview of Concepts, Models,
Service, CCITT Recommendation X.500, December, 1988.
US FIPS 5: Codes for the Identification of the States,
District of Columbia and Outlying Areas of the
States, and Associated Areas, US Department of
FIPS 5--2, May 28, 1987.
US FIPS 6: Counties and Equivalent Entities of the
States, its Possessions, and Associated Areas,
Department of Commerce FIPS 6--4, August 31, 1990.
US FIPS 55: Guideline: Codes for Named Populated Places
Primary County Divisions, and other Locational
of the United States and Outlying Areas, US Department
Commerce FIPS 55--2, February 3, 1987.
The NADF is soliticting comments on this naming scheme.
should be directed to
Postal: Dr. Marshall T.
Performance Systems
5201 Great American
Suite 3106
Santa Clara, CA 95054
Telephone: +1 408 562 6222
Fax: +1 408 562 6223
Internet: mrose@psi.
X.500: rose, psi,
Comments should be received prior to July 1, 1991.
Appendix A: Naming
There are two aspects to the naming architecture: a DIT structure
a set of related Schema definitions. These are shown on pages 17
18, respectively
NADF [Page 16]
RFC 1218 A Naming Scheme for c=US April 1991
DIT
----------------------------------------------------------------------
Level Element objectClass Superior
----------------------------------------------------------------------
root 0
----------------------------------------------------------------------
intl. 1 country 0
----------------------------------------------------------------------
natl. 2 usStateOrEquivalent 1
3 usOganization 1
4 nadfADDMD 1
----------------------------------------------------------------------
reg. 5 usPlace 2
6 organization 2
----------------------------------------------------------------------
local 7 residentialPerson 5 commonName
8 organization 5
9 mhsDistributionList 5
----------------------------------------------------------------------
----------------------------------------------------------------------
opt. 6* organization 1 organizationName
7* residentialPerson 2 commonName
other
8* organization 2 organizationName
----------------------------------------------------------------------
----------------------------------------------------------------------
org. 10** organizationalUnit 3,6,8,10,11
11** locality 3,6,8,10,11
12** organizationalRole 3,6,8,10,11
13** organizationalPerson 3,6,8,10,11
----------------------------------------------------------------------
----------------------------------------------------------------------
appl. 14 applicationProcess 3,6,8,10,11
15 nadfApplicationEntity 14
16 mhsDistributionList 3,6,8,10,11
17 ediUser 3,6,8,10,11
18 device 3,6,8,10,11
----------------------------------------------------------------------
* = These are the optimized form of the corresponding element in
civil component
** = This scheme makes no requirements on the DIT structure within
NADF [Page 17]
RFC 1218 A Naming Scheme for c=US April 1991
organization. The organizational structure shown here is only
exposition. For example, MHS objects are not listed beneath
organizational level, though they are likely to occur within
organization
Schema
NADF-SCHEMA { joint-iso-ccitt mhs(6) group(6) al-grimstad(5)
nadf(1) schema(1) }
DEFINITIONS ::=
OBJECT-CLASS,
FROM
{ joint-iso-ccitt ds(5) module(1)
informationFramework(1) }
caseIgnoreStringSyntax,
FROM
{ joint-iso-ccitt ds(5) module(1)
selectedAttributeTypes(5) }
locality, organization, applicationEntity,
FROM
{ joint-iso-ccitt ds(5) module(1)
selectedObjectClasses(6) }
;
nadf OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs(6) group (6)
al-grimstad(5) 1 }
nadfModule OBJECT IDENTIFIER ::= { nadf 1 }
nadfAttributeType OBJECT IDENTIFIER ::= { nadf 4 }
nadfObjectClass OBJECT IDENTIFIER ::= { nadf 6 }
-- object
usStateOrEquivalent OBJECT-
-- localityName is used for
-- values come from US FIPS PUB 5
SUBCLASS OF
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-
-- localityName is used for
-- values come from US FIPS PUB 55
SUBCLASS OF
MUST CONTAIN { fipsPlaceNumericCode
localityName }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 2 }
usCounty OBJECT-
SUBCLASS OF
MUST CONTAIN { fipsCountyNumericCode }
::= { nadfObjectClass 3 }
usOrganization OBJECT-
-- organizationName is used for
-- values come from ANSI Alphanumeric
SUBCLASS OF
MUST CONTAIN { ansiOrgNumericCode }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 4 }
nadfApplicationEntity OBJECT-
SUBCLASS OF
MUST CONTAIN { supportedApplicationContext }
::= { nadfObjectClass 5 }
nadfADDMD OBJECT-
-- addmdName is used for
-- values come from NADF Registry (tbd
SUBCLASS OF
MUST CONTAIN { addmdName }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 6 }
-- auxiliary
nadfObject OBJECT-
SUBCLASS OF
MAY CONTAIN { supplementaryInformation }
::= { nadfObjectClass 7 }
NADF [Page 19]
RFC 1218 A Naming Scheme for c=US April 1991
-- attribute
fipsStateNumericCode
-- semantics and values defined in US FIPS PUB 5
WITH ATTRIBUTE-
-- leading zero is
NumericString (SIZE (2))
MATCHES FOR
::= { nadfAttributeType 1 }
fipsStateAlphaCode
-- semantics and values defined in US FIPS PUB 5
WITH ATTRIBUTE-
PrintableString (SIZE (2))
MATCHES FOR EQUALITY -- case-
::= { nadfAttributeType 2 }
fipsCountyNumericCode
-- semantics and values defined in US FIPS PUB 6
WITH ATTRIBUTE-
-- leading zeros are
NumericString (SIZE (3))
MATCHES FOR
::= { nadfAttributeType 3 }
fipsPlaceNumericCode
-- semantics and values defined in US FIPS PUB 55
WITH ATTRIBUTE-
-- leading zeros are
NumericString (SIZE (5))
MATCHES FOR
::= { nadfAttributeType 4 }
ansiOrgNumericCode
-- semantics and values defined in ANSI
WITH ATTRIBUTE-
MATCHES FOR
::= { nadfAttributeType 5 }
addmdName
-- semantics and values defined in NADF
WITH ATTRIBUTE-SYNTAX
::= { nadfAttributeType 6 }
NADF [Page 20]
RFC 1218 A Naming Scheme for c=US April 1991
nadfSearchGuide
WITH ATTRIBUTE-SYNTAX
::= { nadfAttributeType 7 }
NadfGuide ::=
SET {
objectClass[0]
OBJECT-CLASS
criteria[1]
Criteria
subset[2]
INTEGER {
baseObject(0), oneLevel(1), wholeSubtree(2)
} DEFAULT
}
supplementaryInformation
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..76))
::= { nadfAttributeType 8 }
Appendix B: 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 21]
RFC 1218 A Naming Scheme for c=US April 1991
(1) The ANSI numeric name form registry was used as the
for RDNs of organizations with national 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 basis
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
North American Directory Forum at its March 18--22, 1990 meeting
This version introduced the notion of organizations with
standing being listed at the national level through the use of
names and multi-valued RDNs
The current (fifth) version of this scheme (NADF-123) generalized
listing concept by introducing the notion of optimized civil naming
Further, the document was edited to clearly note the different
components and the relation between them
NADF [Page 22]
RFC 1218 A Naming Scheme for c=US April 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 23]
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
