RFC 1218
Naming scheme for c=US
RFC 1218: A Naming Scheme for c=US 🎀
Okay bestie, so this is RFC 1218 from the Network Working Group, dated April 1991 📅. It's written by The North American Directory Forum, and no individual authors are listed in the header 💅. It's Informational, which means it provides information for the Internet community and doesn't specify an Internet standard 🌸. The header doesn't list anything it obsoletes or updates ✨.
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 called NADF-123, produced by the North American Directory Forum (NADF) 📄. The NADF is a group of organizations that offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations 🌐. As part of its charter, the NADF must reach agreement on how entries are named in the public portions of the North American Directory. NADF-123 is a scheme proposed for exactly that 🎯.
The NADF is circulating NADF-123 widely, specifically to gather comments 👀. The next NADF meeting is in mid-July, and comments need to arrive before it so the scheme can get proper review 🗓️. It's giving urgent, no cap 😭.
A Naming Scheme for c=US 🌸
The North American Directory Forum
NADF-123
Supercedes NADF-103 and NADF-71, dated March 21, 1991 ✨
ABSTRACT 🧚
This is one of a series of documents produced for discussion within the North American Directory Forum. Distribution, with attribution, is unlimited. This document is being circulated for comment. The deadline for comments is July 1, 1991. Comments should be directed to the contact given on page 16 💌.
1. Introduction 🌈
Okay so computer networks are the infrastructure that connects users to each other 🫶. Email is the classic example: it gives people a way to work toward some common goal. Sometimes that's just sharing info, and other times two people are running a joint research project over email as their main way to talk 📧.
But networks are built on an underlying naming and numbering infrastructure, usually in the form of names and addresses 🧩. For example, some authority has to exist to hand out network addresses so numbering collisions don't happen. And honestly, this is paramount when there are multiple service providers in the mix 😭🔥.
2. Approach 🦋
It should be observed (bestie, pay attention 👀) that there are several different naming universes you can build in the Directory Information Tree (DIT). Think geographical naming, community naming, political naming, organizational naming, and so on 🗺️. The universe you choose mostly decides how hard it is to turn a user's query into a series of Directory operations. You can support multiple naming universes in the DIT at once, but that's likely to be unnatural 🙈. So this proposal focuses on one single naming universe 💅.
The naming universe here is based on civil authority. It uses the existing civil naming infrastructure and suggests a (nearly) straightforward mapping onto the DIT 🎀. There are four components to the naming architecture:
- civil naming and optimized civil naming, which reflects names assigned by civil authority;
- organizational naming, which reflects names assigned within organizations;
- ADDMD naming, which reflects names assigned to public providers within the Directory service; and,
- application naming, which reflects names assigned to OSI entities.
Important bit: entries should be listed wherever searches for them are likely to occur 🔍. That means a single object may be listed under several entries. Main character energy for objects, honestly ✨.
2.1. Names and User-Friendliness 💜
It must be emphasized that there are three distinct concepts people constantly mix up when they talk about a naming scheme 🙄:
- user-friendly naming: a property of a Directory which allows users to easily identify objects;
- user-friendly name: a technique for naming an object which exhibits "friendliness" according to an arbitrary set of user-criteria; and,
- 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 🫠. Further, user-friendly naming in the Directory is a property of the Directory Service, not of Distinguished Names. Not me having to repeat this, but it's giving important 💅.
2.2. Choice of RDN Names 🎀
The key thing to get about RDNs is that they should provide a large name space to avoid collisions. The naming strategy must provide enough "real estate" to accommodate a large demand for entries 🏡. That's the primary requirement for RDNs. A secondary requirement is that RDNs should be meaningful (friendly to people) and should not impede searching 🔎.
However, this second requirement can be achieved by using additional (non-distinguished) attribute values, and that's the lowkey genius part 🧠. For example, if the RDN of an entry is:
organizationName is Performance Systems Internationalthen it is perfectly acceptable (and indeed desirable) to have other values for the organizationName attribute, e.g.,
organizationName is PSIThese abbreviated names greatly aid searching while avoiding unnecessary Distinguished Name conflicts 💖.
To appreciate the naming scheme that follows, it helps to know that it leverages existing naming infrastructure wherever possible 🧚. It relies heavily on non-OSI naming authorities that already exist. Note that since it relies on existing naming authorities, there is little chance that any "final" national decision could obsolete it 🛡️.
Footnote: Any naming scheme may be subject to the jurisdiction of certain national agencies. For example, the US State Department is concerned with any impact on US telecommunications treaty obligations.
(To do so would require a national decision that disregards existing national and regional infrastructure, and establishes some entirely new and different national naming infrastructure 🙃.)
3. Civil Naming 🇺🇸
Civil naming happens at three levels 🗺️:
- the national level, which contains objects that are recognized throughout a country;
- the regional level, which contains objects that are recognized throughout a state or state-equivalent; and,
- the local level, which contains objects that are recognized within a populated place.
3.1. Naming at the National Level 🌟
At the national level (at least), three kinds of names may be listed:
- The States and State-Equivalents
- Organizations with National Standing
- ADDMD Operators
3.1.1. The States and State-Equivalents 🌻
For each state or state-equivalent (the District of Columbia and the eight outlying areas 🏝️), an instance of a usStateOrEquivalent object is used. The RDN is formed as:
localityName is <FIPS 5 name>e.g.,
localityName is Californiaprovides the RDN for the State of California. In addition, this entry would contain attributes identifying both the FIPS 5 alpha and numeric code for the State, e.g.,
fipsStateNumericCode is 06
fipsStateAlphaCode is CAOf course, this entry could contain many other attributes, such as:
stateOrProvinceName is State of CaliforniaFootnote: i.e., American Samoa, Federated States of Micronesia, Guam, Marshall Islands, Northern Mariana Islands, Palau, Puerto Rico, and Virgin Islands of the US.
3.1.2. Organizations with National Standing 🏢
There is no authority in the United States that unambiguously registers the alphanumeric names of organizations with national standing 😤. It is proposed that ANSI provide this registry, and that the ANSI alphanumeric name form be used as the basis for RDNs 🙌.
For each organization with national standing, an instance of a usOrganization object is used. The RDN is formed as:
organizationName is <ANSI alphanumeric name form>e.g.,
organizationName is Performance Systems InternationalIn addition, this entry would contain attributes identifying the ANSI alphanumeric name form, e.g.,
ansiOrgNumericCode is 177777Of course, this entry would contain many other attributes, such as:
organizationName is PSIFor the National Government, an instance of an organization object is also used, and the RDN is taken from the ANSI alphanumeric name form registry 🦅.
3.1.3. ADDMD Operators 📡
There is no authority in the United States that unambiguously registers the names of ADDMD operators 🙃. It is expected that the North American Directory Forum will coordinate with the US CCITT National Committee Study Group D to provide this registry. (At worst, the ADDMDs can use ANSI alphanumeric name forms for their RDN attribute values 🫶.)
For each ADDMD operator, an instance of a nadfADDMD object is used. The RDN is formed as:
addmdName is <NADF registered name>e.g.,
addmdName is PSINet3.2. Naming within a State or State-Equivalent 🗽
At the regional level (at least), two kinds of names may be listed:
- Populated Places
- Organizations with Regional Standing
3.2.1. Populated Places 🏘️
For each populated place within a state or state-equivalent, an instance of a usPlace object is used. The RDN is formed as:
localityName is <FIPS 55 name>e.g.,
localityName is Hartfordprovides the RDN for the Hartford entry immediately subordinate to the usStateOrEquivalent entry for the State of Connecticut 🍂. In addition, this entry would contain attributes identifying the FIPS 55 place code, e.g.,
usPlaceCode is 370003.2.2. Organizations with Regional Standing 💼
An organization has regional standing if it is registered with the "Secretary of State" or a similar entity within that region, as an entity doing business in the region 📝.
For each organization with regional standing, an instance of an organization object is used. The RDN is formed as:
organizationName is <registered name of organization>e.g.,
organizationName is Network Management Associatesmight provide the RDN for a business entity registered with the State of California 🌴. In this case, the entry thus named would be immediately subordinate to the usStateOrEquivalent entry for the State of California.
Note that other non-distinguished attributes, such as an ANSI numeric name form value, may be included in such an entry --- the organization object might actually be a usOrganization object 🧁.
For the Regional Government, an instance of an organization object is also used. The RDN is formed as:
organizationName is Government3.3. Naming within a Populated Place 🏙️
At the local level (at least), three kinds of names may be listed:
- Persons
- Organizations with Local Standing
- MHS Distribution Lists
3.3.1. Naming of Persons
Okay so, inside a populated place there's no centralized naming entity that registers residential persons 🏡 (no cap, it's kinda iconic that nobody's in charge of it 💅). So the proposal is that person entries sit directly under the usPlace object that most accurately matches where they live 🧚
For each person who wants an entry in the Directory, we use an instance of a residentialPerson object 🎀. The RDN is usually multi-valued and starts like this:
commonName is <person's full name>Then you add some other attribute, like postalCode, streetAddress, etc. 🫶 But here's the tea: streetAddress is often considered private info 🙈, so based on an agreement between the entity managing the DMD and the listed person, some other distinguishing attribute may be used. That can include a "serial number" (which has no other purpose) 🔢. It should be noted however that this is not super helpful for searching, unless other attribute values with meaningful information get added to the entry and made available for public access 💀
3.3.2. Organizations with Local Standing
An organization has local standing if it's registered with the County or City Clerk (or a similar entity in that locality) as an entity "doing business" in that place 🏢✨
For each organization with local standing, we use an instance of an organization object. The RDN is formed like this:
organizationName is <registered name of organization>e.g.,
organizationName is The Tied HouseSo organizationName is The Tied House might give the RDN for a business entity registered with the City of Mountain View 🍺. In that case, the entry would be immediately subordinate to the usPlace entry for the City of Mountain View 🌸
Note that other non-distinguished attributes, such as an ANSI numeric name form value, may be included in an entry. (Basically, the organization object might actually be a usOrganization object 🧐.)
For the Local Government, if there is one, we also use an instance of an organization object 🏛️. The RDN is formed as:
organizationName is Government3.4. Naming of MHS Distribution Lists
Naming of MHS distribution lists remains with the scoping DMD 📬.
4. Optimized Civil Naming ⚡
The structure of the civil component of the architecture can be described concisely as:
----------------------------------------------------------------------
Level Element objectClass Superior RDN
----------------------------------------------------------------------
root 0
----------------------------------------------------------------------
intl. 1 country 0 countryName
----------------------------------------------------------------------
natl. 2 usStateOrEquivalent 1 localityName
3 usOganization 1 organizationName
4 nadfADDMD 1 addmdName
----------------------------------------------------------------------
reg. 5 usPlace 2 localityName
6 organization 2 organizationName
----------------------------------------------------------------------
local 7 residentialPerson 5 commonName,
other
8 organization 5 organizationName
9 mhsDistributionList 5 commonName
----------------------------------------------------------------------Let's think about how an interrogation algorithm might find a residential person, given:
- a string denoting the person's real-world name;
- a string denoting the real-world name of the populated place where the person lives; and,
- the Distinguished Name of the state or state-equivalent.
A straightforward approach is to start a single-level search to find the populated place you want 🔍. The search returns zero or more Distinguished Names that match the string the user gave. Then, for each populated place, a subtree search might be started to find the residential person. But if the first search returns a lot of populated places, this strategy is inefficient 😩
A better approach would be to run one search, with a filter that combines the strings for both the person's real-world name and the place's real-world name. Unfortunately, that search would have to cover the whole-subtree anchored at the Distinguished Name for the state or state-equivalent, which would be inefficient 🐢
So it may be desirable to optimize the civil naming component by listing some entries at a higher level 🚀. This is done by using a multi-valued RDN formed by combining the RDNs of the entry and its superior.
There are three cases in civil naming:
- listing an organization with regional standing at the national level;
- listing an organization with local standing at the regional level; and,
- listing a person with local standing at the regional level.
So under the optimized civil naming component, a single-level search, anchored at the Distinguished Name for the state or state-equivalent, could be used 🎯. On top of that, a DSA supporting this optimization would highly-index the attributes used for searching, in order to achieve high performance 🏎️
To clearly show that optimized civil naming is in effect, we introduce a new attribute type, nadfSearchGuide ✨. A value of this type goes in an entry to say which optimizations are in effect. Using the residential example above, the entry for the state or state-equivalent would contain an nadfSearchGuide value saying that when you're searching for entries of type residentialPerson, a single-level search should be performed with a filter containing the logical-and of two terms: one involving the commonName attribute, and the other involving the localityName attribute 🧩. The nadfSearchGuide is a refinement of the X.500 searchGuide, because it indicates the depth of the search that should be performed, and it always includes the object class the optimization applies to 📐
Finally, note that this technique might also be used for naming within organizations 🏢💜
4.1. Naming at the National Level
4.1.1. Organizations with Regional Standing
An organization with standing within a state or state-equivalent may be listed directly under c=US 🇺🇸.
For an organization with regional standing, we use an instance of an organization object. The RDN is multi-valued and formed as:
organizationName is <registered name of organization>
localityName is <FIPS 5 name>e.g.,
organizationName is Network Management Associates
localityName is CaliforniaIt must be emphasized that uniqueness within the RDN comes from pairing a regional localityName (state or state-Equivalent) with the matching organizationName in that region 💖
4.2. Naming within a State or State-Equivalent
4.2.1. Organizations with Local Standing
An organization with standing within a populated place may be listed directly under its state or state-equivalent 🌈
For an organization with local standing, we use an instance of an organization object. The RDN is multi-valued and formed as:
organizationName is <registered name of organization>
localityName is <FIPS 55 name>e.g.,
organizationName is The Tied House
localityName is City of Mountain ViewIt must be emphasized that uniqueness within the RDN comes from pairing a local localityName (populated place) with the matching organizationName in that place 🌟
4.2.2. Persons
A person may be listed directly under its state or state-equivalent 🧚♀️
For a person like this, we use an instance of a residentialPerson object. The RDN is multi-valued and formed by taking the RDN of the person and adding the RDN of the populated place where the person lives:
commonName is the Marshall T. Rose
postalCode is 94043-2112
localityName is City of Mountain ViewNote that for optimization to occur, the RDN of the person must not contain a localityName attribute value 🚫
5. Organizational Naming
The internal structure of each usOrganization or organization object is up to that organization to decide 🗂️
It is strongly recommended that organizationalUnit objects be used for structuring 💼. (If an organization uses a locality-based organizational hierarchy, that information can still be represented using the organizationalUnit object 📍.)
6. ADDMD Naming
The internal structure of each nadfADDMD object is up to that service-provider to decide 📡
7. Application Naming
There are (at least) four kinds of OSI entities that may be listed 📋:
- Application Processes and Entities
- MHS Distribution Lists
- EDI Users
- Devices
7.1. Naming of Application Processes and Entities
Naming of OSI application processes and entities remains with the scoping DMD 🔐. But to foster interoperability, two requirements are made. First, application entity objects must be immediately subordinate to application process objects. Second, application entities are represented by the nadfApplicationEntity object, which is identical to the applicationEntity object except that the presence of an attribute value of supportedApplicationContext is mandatory 🤝
7.2. Naming of MHS Distribution Lists
Naming of MHS distribution lists remains with the scoping DMD 📬
7.3. Naming of EDI Users
Naming of EDI users remains with the scoping DMD 🧾
7.4. Naming of Devices
Naming of OSI devices remains with the scoping DMD 🖥️
8. Usage Examples ✨
Okay bestie, examples time 🎀 These are written in a concise format you read left to right, so { c=US, o=Government } basically means "country US, organization Government" 💖
Federal Government:
{ c=US, o=Government }The State of California:
{ c=US, l=California }The District of Columbia:
{ c=US, l=District of Columbia }An organization with national standing:
{ c=US, o=Performance Systems International }An ADDMD:
{ c=US, addmdName=PSINet }The Government of the State of California:
{ c=US, l=California, o=Government }The Government of the District of Columbia:
{ c=US, l=District of Columbia, o=Government }A city within the State of California:
{ c=US, l=California, l=City of Mountain View }An organization licensed to operate within the State of California:
{ c=US,
l=California,
o=Network Management Associates, Inc. }An optimized listing for an organization with regional standing:
{ c=US,
{ l=California,
o=Network Management Associates }}A city government:
{ c=US,
l=California,
l=City of Mountain View,
o=Government }A residential person:
{ c=US,
l=California,
l=City of Mountain View,
{ cn=Marshall T. Rose, postalCode=94043-2112 }}An organization licensed to operate within a city:
{ c=US,
l=California,
l=City of Mountain View,
o=The Tied House }An entity within the Federal Government:
{ c=US, o=Government, ou=Department of the Air Force }An entity within an organization with national standing:
{ c=US,
o=Performance Systems International,
ou=Marketing }9. Acknowledgements 🫶
This doc is built on a bunch of sources, not just vibes 😭 The list includes, but is not limited to:
- Listing Services Database Generic Requirements, Bellcore TA-TSY-000985;
- Common Directory Use ED 013 (Q/511) (EWOS/EGDIR/90/156); and
- The THORN X.500 Naming Architecture (UCL-45 revision 6.1).
10. Bibliography 📚
- X.500: The Directory --- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988.
- US FIPS 5: Codes for the Identification of the States, The District of Columbia and Outlying Areas of the United States, and Associated Areas, US Department of Commerce FIPS 5--2, May 28, 1987.
- US FIPS 6: Counties and Equivalent Entities of the United States, its Possessions, and Associated Areas, US Department of Commerce FIPS 6--4, August 31, 1990.
- US FIPS 55: Guideline: Codes for Named Populated Places, Primary County Divisions, and other Locational Entities of the United States and Outlying Areas, US Department of Commerce FIPS 55--2, February 3, 1987.
The NADF is soliciting comments on this naming scheme 💌 Comments should be directed to:
Postal: Dr. Marshall T. Rose
Performance Systems International
5201 Great American Parkway
Suite 3106
Santa Clara, CA 95054
US
Telephone: +1 408 562 6222
Fax: +1 408 562 6223
Internet: mrose@psi.com
X.500: rose, psi, usComments should be received prior to July 1, 1991. ⏰
Appendix A: Naming Architecture 🧚
There are two aspects to the naming architecture: a DIT structure and a set of related Schema definitions. These are shown on pages 17 and 18, respectively.
DIT Structure 🌸
----------------------------------------------------------------------
Level Element objectClass Superior RDN
----------------------------------------------------------------------
root 0
----------------------------------------------------------------------
intl. 1 country 0 countryName
----------------------------------------------------------------------
natl. 2 usStateOrEquivalent 1 localityName
3 usOganization 1 organizationName
4 nadfADDMD 1 addmdName
----------------------------------------------------------------------
reg. 5 usPlace 2 localityName
6 organization 2 organizationName
----------------------------------------------------------------------
local 7 residentialPerson 5 commonName,
other
8 organization 5 organizationName
9 mhsDistributionList 5 commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
opt. 6* organization 1 organizationName,
localityName
7* residentialPerson 2 commonName,
other,
localityName
8* organization 2 organizationName,
localityName
----------------------------------------------------------------------
----------------------------------------------------------------------
org. 10** organizationalUnit 3,6,8,10,11 orgUnitName
11** locality 3,6,8,10,11 localityName
12** organizationalRole 3,6,8,10,11 commonName
13** organizationalPerson 3,6,8,10,11 commonName
----------------------------------------------------------------------
----------------------------------------------------------------------
appl. 14 applicationProcess 3,6,8,10,11 commonName
15 nadfApplicationEntity 14 commonName
16 mhsDistributionList 3,6,8,10,11 commonName
17 ediUser 3,6,8,10,11 ediName
18 device 3,6,8,10,11 commonName
----------------------------------------------------------------------Now the little footnotes, word for word 👀
* = These are the optimized form of the corresponding element in the
civil component.
** = This scheme makes no requirements on the DIT structure within an
organization. The organizational structure shown here is only for
exposition. For example, MHS objects are not listed beneath the
organizational level, though they are likely to occur within an
organization.Schema Definitions ✨
okay bestie, here's the whole NADF schema in ASN.1 🎀 copy it exactly, every single character matters, because implementers are literally relying on it 💅
NADF-SCHEMA { joint-iso-ccitt mhs(6) group(6) al-grimstad(5)
nadf(1) schema(1) }
DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-CLASS, ATTRIBUTE
FROM InformationFramework
{ joint-iso-ccitt ds(5) module(1)
informationFramework(1) }
caseIgnoreStringSyntax, Criteria
FROM SelectedAttributeTypes
{ joint-iso-ccitt ds(5) module(1)
selectedAttributeTypes(5) }
locality, organization, applicationEntity, top
FROM SelectedObjectClasses
{ joint-iso-ccitt ds(5) module(1)
selectedObjectClasses(6) }
;
nadf OBJECT IDENTIFIER ::= { joint-iso-ccitt mhs(6) group (6)
al-grimstad(5) 1 }
nadfModule OBJECT IDENTIFIER ::= { nadf 1 }
nadfAttributeType OBJECT IDENTIFIER ::= { nadf 4 }
nadfObjectClass OBJECT IDENTIFIER ::= { nadf 6 }
-- object classes
usStateOrEquivalent OBJECT-CLASS
-- localityName is used for RDN
-- values come from US FIPS PUB 5
SUBCLASS OF locality
MUST CONTAIN { fipsStateNumericCode,
fipsStateAlphaCode,
stateOrProvinceName }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 1 }
usPlace OBJECT-CLASS
-- localityName is used for RDN
-- values come from US FIPS PUB 55
SUBCLASS OF locality
MUST CONTAIN { fipsPlaceNumericCode,
localityName }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 2 }
usCounty OBJECT-CLASS
SUBCLASS OF usPlace
MUST CONTAIN { fipsCountyNumericCode }
::= { nadfObjectClass 3 }
usOrganization OBJECT-CLASS
-- organizationName is used for RDN
-- values come from ANSI Alphanumeric Registry
SUBCLASS OF organization
MUST CONTAIN { ansiOrgNumericCode }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 4 }
nadfApplicationEntity OBJECT-CLASS
SUBCLASS OF applicationEntity
MUST CONTAIN { supportedApplicationContext }
::= { nadfObjectClass 5 }
nadfADDMD OBJECT-CLASS
-- addmdName is used for RDN
-- values come from NADF Registry (tbd)
SUBCLASS OF top
MUST CONTAIN { addmdName }
MAY CONTAIN { nadfSearchGuide }
::= { nadfObjectClass 6 }
-- auxiliary classes
nadfObject OBJECT-CLASS
SUBCLASS OF top
MAY CONTAIN { supplementaryInformation }
::= { nadfObjectClass 7 }
-- attribute types
fipsStateNumericCode ATTRIBUTE
-- semantics and values defined in US FIPS PUB 5
WITH ATTRIBUTE-SYNTAX
-- leading zero is significant
NumericString (SIZE (2))
MATCHES FOR EQUALITY
::= { nadfAttributeType 1 }
fipsStateAlphaCode ATTRIBUTE
-- semantics and values defined in US FIPS PUB 5
WITH ATTRIBUTE-SYNTAX
PrintableString (SIZE (2))
MATCHES FOR EQUALITY -- case-insensitive
::= { nadfAttributeType 2 }
fipsCountyNumericCode ATTRIBUTE
-- semantics and values defined in US FIPS PUB 6
WITH ATTRIBUTE-SYNTAX
-- leading zeros are significant
NumericString (SIZE (3))
MATCHES FOR EQUALITY
::= { nadfAttributeType 3 }
fipsPlaceNumericCode ATTRIBUTE
-- semantics and values defined in US FIPS PUB 55
WITH ATTRIBUTE-SYNTAX
-- leading zeros are significant
NumericString (SIZE (5))
MATCHES FOR EQUALITY
::= { nadfAttributeType 4 }
ansiOrgNumericCode ATTRIBUTE
-- semantics and values defined in ANSI registry
WITH ATTRIBUTE-SYNTAX
INTEGER
MATCHES FOR EQUALITY
::= { nadfAttributeType 5 }
addmdName ATTRIBUTE
-- semantics and values defined in NADF registry
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax
::= { nadfAttributeType 6 }
nadfSearchGuide ATTRIBUTE
WITH ATTRIBUTE-SYNTAX NadfGuide
::= { nadfAttributeType 7 }
NadfGuide ::=
SET {
objectClass[0]
OBJECT-CLASS,
criteria[1]
Criteria,
subset[2]
INTEGER {
baseObject(0), oneLevel(1), wholeSubtree(2)
} DEFAULT oneLevel
}
supplementaryInformation ATTRIBUTE
WITH ATTRIBUTE-SYNTAX caseIgnoreStringSyntax (SIZE (1..76))
::= { nadfAttributeType 8 }
ENDAppendix B: Revision History of this Scheme 📜
okay so this is the story of how the scheme grew up 🌱 Version one, NADF-71, was brought to the North American Directory Forum at its November 27--30, 1990 meeting, and it had some (mis)features that were... a lot 😭 Here's what they were:
- Nobody was super confident in the ANSI registration procedures, so people suggested using US trademarks as the basis for RDNs of organizations with national-standing. Spoiler: that flopped, because the same trademark can be issued to different organizations in different industries 💀
- There was no existing registry for populated places. That was also unworkable, because defining a brand new registry is a whole problem 🙈
Version two was brought to the ANSI Registration Authority Committee at its January 30, 1991 meeting, and to the IETF OSI Directory Services Working Group at its February 12--13, 1991 meeting. Its (mis)features were:
- The ANSI numeric name form registry was used as the basis for RDNs of organizations with national standings.
- The FIPS 5 state numeric code was used as the basis for RDNs of states and state-equivalents.
- The FIPS 55 place numeric code was used as the basis for RDNs of populated places.
The numeric name forms were unpopular, not gonna lie 😬 but the reason was to dodge the ANSI alphanumeric name form registry, which people thought was unstable. Fair enough, honestly.
Version three went to US State Department Study Group D's MHS-MD subcommittee at its March 7--8 1991 meeting. This one used alphanumeric name forms for all objects, because the team figured the ANSI alphanumeric name form registry would prove stable 🤞 If that registry turned out to be unstable, there were two possible fallbacks:
- disallow organizations with national-standing in the US portion of the DIT; or,
- use the ANSI numeric name form registry instead.
Hopefully neither of those two not-so-cute options ends up being necessary 🥺
Version four, NADF-103, was contributed to the North American Directory Forum at its March 18--22, 1990 meeting. This one introduced the idea of organizations with regional standing getting listed at the national level, using alias names and multi-valued RDNs ✨
The current (fifth) version, NADF-123, generalized the listing concept by introducing optimized civil naming 👑 It was also edited so the different naming components and the relationships between them are clearly noted. Glow-up complete! 🌈
Security Considerations 🔒
okay, the security section is short and sweet: this memo doesn't discuss security issues at all 🙈 so you won't find any security guidance in here, bestie 😭
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📦 where this page comes from
- ietf: rfc1218 1991-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms