RFC 1255
A Naming Scheme for c=US
A Naming Scheme for c=US 🇺🇸✨
Network Working Group 🌸 Request for Comments: 1255 💅 Author: The North American Directory Forum 👑 Category: Informational 📖 (it just provides information for the Internet community and doesn't specify an Internet standard, so no pressure lol) Date: September 1991 🗓️ Obsoletes: RFC 1218 🫶 Updates: nothing listed 🤷♀️
This one is literally a naming scheme for entries in the North American Directory, and it's giving serious civil-infrastructure energy 🏛️💖.
Status of This Memo 🎀
Okay so this memo gives info to the Internet community. It is NOT a standard, and the memo can be shared as widely as you want 🦋.
Summary 🌈
So this RFC is a nearly word-for-word copy of a doc called NADF-175, made 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 🌐. Part of the NADF's charter is figuring out how entries get named in the public parts of the North American Directory. NADF-175 is literally their agreed answer for that 🙌.
Table of Contents 📚
1 Introduction .......................................... 2
2 Approach .............................................. 2
2.1 Names and User-Friendliness ......................... 3
2.2 Choice of RDN Names ................................. 3
2.3 Outline of the Scheme ............................... 4
3 The Naming Process .................................... 4
3.1 Right-To-Use ........................................ 4
3.2 Registration ........................................ 6
3.3 Publication ......................................... 6
4 Structuring Objects ................................... 7
4.1 The National Level .................................. 7
4.2 The Regional Level .................................. 7
4.3 The Local Level ..................................... 9
4.4 ADDMD Operators ..................................... 10
4.5 Summary of Structuring Objects ...................... 11
5 Entity Objects ........................................ 12
5.1 Organizations ....................................... 12
5.1.1 Kinds of Organizations ............................ 12
5.1.2 Modeling Organizations ............................ 13
5.2 Persons ............................................. 14
6 Listing Entities ...................................... 15
6.1 Organizations ....................................... 15
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 ........................................ 25The scheme itself was also revised, under the name "A Naming Scheme for c=US" from The North American Directory Forum, dated July 12, 1991. It supercedes NADF-166, 143, 123, 103, and 71 🗂️.
1. Introduction 🧚
Okay bestie, computer networks are the infrastructure that connects users, and those networks are built on top of a naming and numbering system, usually in the form of names and addresses 🔢. For example, some authority has to exist to hand out network addresses so that numbering collisions don't happen 🚫. This matters SO much in an environment with multiple service providers 👑.
2. Approach 💭
It's worth noticing that there are several different naming universes that could be used in the Directory Information Tree (DIT) 🌳. Some examples are geographical naming, community naming, political naming, organizational naming, and so on 🗺️. The naming universe you pick mostly decides how hard it is to turn a user's query into a series of Directory operations that actually find useful info 😩. You can support multiple naming universes in the DIT at the same time, but it's likely to feel unnatural, so this scheme focuses on just one 🎯.
The naming universe in this scheme is based on civil authority. So it uses the existing civil naming infrastructure and suggests a (nearly) straightforward mapping onto the DIT 🏛️. A big thing here is that entries can be listed wherever people are likely to search for them 🔍. That means a single object might show up as several separate entries 🦋.
2.1. Names and User-Friendliness ✨
It really has to be emphasized that there are two different concepts that people often mix up when they talk about a naming scheme 🙃:
- user-friendly naming: a property of a Directory which lets users easily identify objects of interest; and,
- Distinguished Name: the administratively assigned name for an entry in the OSI Directory.
Distinguished Names are not necessarily user-friendly names 💅. And user-friendly naming in the Directory is a property of the Directory Service, NOT of Distinguished Names. (Wait, I said NOT in caps, but that's just my hype voice, the original says "not", so it's just an emphasis word and not a requirement keyword 🙈.)
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 has to give enough "real estate" to handle a huge demand for Distinguished Names 🏘️. That's the primary requirement for RDNs. A secondary requirement is that RDNs should be meaningful (friendly to people) and should not get in the way of searching 🔎.
But here's the thing, this second requirement can be met by using additional attribute values that aren't distinguished 🧁. For example, if the RDN of an entry is:
organizationName is Performance Systems Internationalthen it's totally acceptable (and honestly desirable) to have other values for the organizationName attribute, like:
organizationName is PSIUsing these abbreviated names really helps with searching, and it also avoids unnecessary Distinguished Name conflicts 💜.
To get why the naming scheme below looks the way it does, you need to know that it leverages existing naming infrastructure wherever possible 🧩. It relies heavily on non-OSI naming authorities that already exist 🫶. Since it depends on those existing authorities, there's little chance that any "final" national decision could make this scheme obsolete 🛡️. (Any naming scheme might fall under the jurisdiction of certain national agencies. For example, the US State Department cares about any impact on US telecommunications treaty obligations 🌏.) To make this scheme obsolete, a national decision would have to disregard existing national and regional infrastructure and set up some entirely new and different national naming infrastructure 😤.
2.3. Outline of the Scheme 🗒️
The naming scheme is divided into four parts 🍓:
- a discussion of the right-to-use, registration, and publication concepts;
- a discussion of objects with national, regional, local, and foreign standing;
- a discussion of objects which may be listed at national, regional, and local levels; and,
- a discussion of how RDNs are formed for listing entries at each different level.
3. The Naming Process 🚀
There are three stages to the naming process.
3.1. Right-To-Use 🎀
okay so first up, a naming authority has to lock in the right-to-use for any name it wants to use, within its own jurisdiction 💅 Names that show up in public are usually governed by public laws. Names that only live in private are a private matter 🙈 We're mostly caring about public names here, because those are the ones that are super fun to list in public directories where people can search for them ✨
There's already a whole global governmental, civil, and organizational setup for naming and numbering things 🌍 Think people, cars, houses, buildings, and streets. Then localities like towns, cities, counties, states, and countries. Then organizations like businesses, schools, and governments. And other stuff like computers, printers, ports, routers, processes, files, filesystems, networks, management domains, and so on 🧚 There are also naming (and numbering) authorities for different standards and networks, like ISO/IEC, CCITT, and IANA. Their authority only works because their communities accept it 🫶
This whole collective infrastructure is made of tons of authorities, which we'll call naming authorities 👑 They love a hierarchy. Parents get the authority (granted by the government) to pick names for their newborns. Courts can change a person's name. Car makers can name the models they build (within the limits of trademark law), and they're required to give every car a unique serial number 🚗 Cities name their streets and districts, states name cities, counties, and townships, and so on. State governments also name "registered" organizations that operate under state charters, and those organizations name their own sub-organizations 🏢 Cities and counties license businesses to use their chosen (unambiguous) names "in association with" the city or county names. Companies name and number the computers and communication devices they make and sell 💻 There are so, so many name spaces. Some are under others, and some are totally independent 🌈
Public names have to be "registered" in some "public record" so the right-to-use assignment is tied to specific "owners" 📜 This is mainly to stop collisions of right-to-use assignments in public shared name spaces. For example, unique names for corporations are registered by the state of incorporation. A request to use a new corporate name must not clash with any other corporation registered in that same state 🚫 The same goes for businesses licensed within cities and counties.
Figuring out the right-to-use for a name is not a Directory Service 🙅♀️ The right-to-use always comes from some other, non-directory source of authority, because of the legal side of intellectual property rights. Those are totally outside the scope of directory service specs. People and organizations put a LOT of value on the names they get to attach to their lives and businesses, and intellectual property law is what protects those interests 💖
Now, that doesn't mean directory service designers and providers don't care about how right-to-use gets sorted out for names that will end up in a directory 👀 Honestly, without a supply of names people can rightfully use, there can't be any directory at all. But as long as there's an adequate supply of registered names, the directory service isn't otherwise concerned 💅
Also, some naming authorities have to handle name spaces shared by huge communities (like computer networks), where applicants for the same name are going to collide 💥 Other name spaces, like the given names of kids in a family, aren't shared outside the family at all. Sharing is always the tricky part, and that's basically why we got trademark laws, business license laws, and so on 😭 Naming inside an organization should be easier, since it's "in the family," so to speak 🏡 Hierarchical naming schemes make it easier to spread naming authority around 🌸
3.2. Registration 🦋
Second, a name can be bound (as a value) to some object attribute 🔗
Once you have the right to use a name, a Naming Authority (like a family that has an inherited surname and pretty much gets to pick whatever given names it wants for its kids) has to bind selected names to selected object attributes, like firstname=Einar 🧸 The same name can also show up as the first or middle name of other children, as long as every sequence of given names in the family is unique to one family member. Wise families don't bind the same sequence of given names to more than one child 🧠 Some avoid reusing any name at all, and some use generational qualifiers to stop parent-child mix-ups 🙃
The Internet Domain Name System (DNS) names top-level domains. Those domains are then free (within some technical limits) to choose and bind names to entries under a given named domain, and so on all the way down the DNS name tree 🌳 The ISO/CCITT naming system does the same job in its own separate name spaces ✨
3.3. Publication 📣
Third, after binding, a name has to be advertised or published in some community if others are going to reference it 📢 If it isn't advertised or published, nobody can refer to it, full stop 🙈
This publication stage is literally what the Directory Service is all about 💜 The Directory holds entries for "listed" names (or numbers) that are bound to the attributes of entries in the directory DIT. Historically, the directory business is a subclass of the publishing business. Its whole job is to turn names into knowledge about what they stand for 📚
Keep this in mind: a directory "listing entry" is not a "registration," unless some segment of the directory also happens to be the authoritative master register of a naming authority 🛑 Registration and listing are very different service functions, even though it's possible they could be combined in a single DIT 🤷♀️
Take the United States of America as an example. Each state name is registered by Congress, when the name is included in the legislation that "admits each State into the Union" 🇺🇸 But the name also gets published in tons of places (like maps and directories), while the master "register" is kept with the other original records of laws enacted by Congress and signed by the President 📜 The name is then listed in lots of directories too, in association with "The United States of America." And so on down the civil naming tree, with entities named in each state, and so on 🌲 It is absolutely NOT the case that the American National Standards Institute (ANSI) registers the names of the States in the United States of America! That right and duty belongs clearly to the Government of the United States of America 💅
On the flip side, in the Internet DNS, the act of putting a rightfully-usable name and address entry into a nameserver counts as registration and directory publication at the same time 🤯
4. Structuring Objects 🏗️
The first step in building a civil naming infrastructure is to model the geographical and governmental entities that the public names are based on 🗺️
4.1. The National Level 🇺🇸
The nation is modeled as an object of class "country", placed under the root of the DIT. It has an RDN made of a single attribute value assertion:
countryName= USThe entry (at a minimum) contains these attributes:
objectClass= country
description= United States of America4.2. The Regional Level 🌟
Inside the nation, there are regions. Each region corresponds to a state or state-equivalent recognized by the US Congress. The list of these is kept in US FIPS 5. Here's a sample entry from that FIPS document, which looks like this:
+------------+---------+-------+
| | State | State |
| FIPS-5 | Numeric | Alpha |
| Name | Code | Code |
+------------+---------+-------+
| | | |
| California | 06 | CA |
| | | |
+------------+---------+-------+Each region is modeled as an object of class "usStateOrEquivalent", which is defined like this:
usStateOrEquivalent OBJECT-CLASS
SUBCLASS OF locality, nadfObject
MUST CONTAIN { localityName,
fipsStateNumericCode,
fipsStateAlphaCode,
stateOrProvinceName }Each entry sits under "c=US" and has an RDN made of a single attribute value assertion:
stateOrProvinceName= <FIPS-5 name>For example:
stateOrProvinceName= CaliforniaEach entry (at a minimum) contains these attributes:
objectClass= usStateOrEquivalent
description= <official name of region>
localityName= <FIPS-5 name>
localityName= <FIPS-5 state alpha code>
fipsStateAlphaCode= <FIPS-5 state alpha code>
fipsStateNumericCode= <FIPS-5 state numeric code>For example:
objectClass= usStateOrEquivalent
description= State of California
localityName= California
localityName= CA
fipsStateAlphaCode= CA
fipsStateNumericCode= 064.3. The Local Level ✨
okay so within each region there are places 🏘️ Each place lines up with a county (or county-equivalent) as recognized by the regional government. The list lives in US FIPS 55 as a populated place with a five-digit numeric place code that starts with "99." 🧚 Here's what a sample entry from that FIPS doc looks like:
+---------+---------+-------+-----+----------------------+-----+
| 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 counts as a "remark" about the place. 💅
Each county gets modeled as an object of class "usCountyOrEquivalent" 🎀 Here's how that's defined:
usPlace OBJECT-CLASS
SUBCLASS OF locality, nadfObject
MUST CONTAIN { localityName,
fipsPlaceNumericCode }
usCountyOrEquivalent OBJECT-CLASS
SUBCLASS OF usPlace
MUST CONTAIN { fipsCountyNumericCode }Each entry is subordinate to the entry for the region that contains the county, and its RDN is one single attribute value assertion:
localityName= <FIPS-55 name without remarks>For example:
localityName= Santa ClaraEach entry (minimally) contains these attributes:
objectClass= usCountyOrEquivalent
fipsPlaceNumericCode= <FIPS-55 place numeric code>
fipsCountyNumericCode= <last three digits of FIPS-55
place code>
stateOrProvinceName= <FIPS-55 state alpha code>
stateOrProvinceName= <FIPS-5 corresponding name>
description= <FIPS-55 name with remarks>And here's the example version, so you can see it in action 🦋
objectClass= usCountyOrEquivalent
fipsPlaceNumericCode= 99085
fipsCountyNumericCode= 085
stateOrProvinceName= California
stateOrProvinceName= CA
description= County of Santa ClaraAlso, for each populated place inside the county, a non-distinguished "localityName" attribute value may be present to help with searching 🔍 For example:
localityName= Mountain View
localityName= San Jose...and so on, bestie 🌸
4.4. ADDMD Operators 🍓
Still at the national level, there are public Directory service providers 💜 Each service provider corresponds to an ADDMD operator as recognized by the NADF. Every ADDMD operator is modeled as an object of class "nadfADDMD", and it's defined like this:
nadfADDMD OBJECT-CLASS
SUBCLASS OF nadfObject
MUST CONTAIN { addmdName }
MAY CONTAIN { organizationName,
organizationalAttributeSet }Each entry is subordinate to "c=US" and has an RDN made of one single attribute value assertion:
addmdName= <NADF registered name>For example:
addmdName= PSINetEach entry (minimally) contains this attribute:
objectClass= nadfADDMDHow the subtree under each "nadfADDMD" entry is structured is up to that service provider to figure out 🧁 It's super important to emphasize that these entries exist to give each service provider a "private" namespace, as envisioned in NADF-128. ✨ The "nadfADDMD" entry is totally separate from a service provider's "organization" entry, which holds the organizational info about that provider.
4.5. Summary of Structuring Objects 📋
Let's recap the naming architecture so far, bestie 💖
+---------------+-----+---------------------+-----+--------------------+
| 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, if you're a visual person 🎨
root
/
/
/
(----)
(c=US)
(----)
/ | \
/ | \
/------------/ | \------\
/ | \
for each state or (------) / \ (---------) for
state-equivalent (st=...) / \ (addmd=...) each
(------) / \ (---------) ADDMD
/ \ / \
/ \ /national \
/------------/ \ / listings \
/ \ -------------
/ \
(-----) for each /\
(l=...) county or / \
(-----) county-equivalent / \
| / \
| /regional\
| / listings \
| ------------
/ \
/ \
/ \
/ local \
/listings \
-----------5. Entity Objects ✨
The next step in using the civil naming infrastructure is modeling the entities that live inside that geographical/governmental structure 🏛️
5.1. Organizations 🏢
Organizations exist at several levels, and they're giving layers 👑
5.1.1. Kinds of Organizations
An organization has national-standing if it was chartered (created and named) by the US Congress 🇺🇸 A national laboratory would be a good example. No other entity is empowered by the government to confer national-standing on organizations. However, ANSI keeps an alphanumeric nameform registration for organizations, and that registration is going to be the public directory service basis for conferring national-standing on private organizations 💅
An organization has regional-standing if it's chartered by the government of that region, and a public university is a classic example 🎓 Private organizations can also get regional-standing by registering with the "Secretary of State" (or a similar entity) in that region. This is called a "doing business as" (DBA) registration 💼
NOTE: An organization can have a DBA registration in several states even though it's only incorporated in one state 🗺️ Where an organization registers is mostly based on where it might choose to incorporate, and where it might choose to locate (and license) its business operations. For example, a big organization might have a DBA registration in most of the 50 states and be incorporated in Delaware. For the purposes of this naming scheme, that organization has regional-standing in each state where it has a DBA registration. That DBA registration gives it the sole right to use the DBA name in association with the named jurisdiction of the registration authority 🔥
An organization has local-standing if it's chartered by a local government within that place. Private organizations can also get local-standing by registering with a "County Clerk" (or similar entity) within that place, which is also a DBA registration 🌈 Real talk though, local-standing is kinda ambiguous, because there can be multiple local governments inside one county or county-equivalent. Depending on local rules of incorporation and containment, registering with one entity might stop others from registering that same name with other entities in that place 😭 To avoid the ambiguity, other distinguishing attributes, like "streetAddress", may be needed to guarantee uniqueness.
5.1.2. Modeling Organizations
In the DIT, an organization is modeled as an object of class "organization" 🧚 On top of that, some combination of the following auxiliary object classes might also be used:
(1) If an organization has national-standing derived from ANSI registration, that gets modeled by including an object class attribute value of "ansiOrgObject" in the entry. It's defined like this:
ansiOrgObject OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN { ansiOrgNumericCode }(2) If an organization has national-standing (either in the US or some other nation), it may be necessary to identify the country that corresponds to the registry naming the organization. That's modeled by including an object class attribute value of "nationalObject" in the entry, defined as:
nationalObject OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN { countryName }(3) If an organization has local-standing, it may be necessary to identify the place in US FIPS 55 that corresponds to the registry naming the organization. That's modeled by including an object class attribute value of "fips55Object" in the entry, defined as:
fips55Object OBJECT-CLASS
SUBCLASS OF top
MUST CONTAIN { fipsPlaceNumericCode }
MAY CONTAIN { stateOrProvinceName }5.2. Persons ✨
Okay so, there are two kinds of person entries: organizational person and residential person 🎀
Organizational persons are a local matter, so each organization gets to decide what they look like. The suggestion is to model one as an object of class organizationalPerson 💼
Outside of organizations, persons only exist in a residential context, which means they always have local standing 🏡 For any given person, it should always be possible to find the place in US FIPS 55 that matches the "smallest" populated place where they live. Then you can use that place's code to help tell them apart from everyone else 🔍 A residential person is modeled with an object of class residentialPerson. Since it may be necessary to identify the US FIPS 55 place where the person lives, an object class attribute value of fips55Object may show up in entries for residential persons 🧚
6. Listing Entities 📋
Now for the final step: how entities actually get listed inside the civil naming infrastructure 🦋 Heads up, an entity can have several listings (DNs) in different parts of the Directory, so don't be surprised if you see more than one!
6.1. Organizations
The RDN you use when listing an organization depends on two things: the organization's standing, and where the listing is going 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 doesn't make any demands on the DIT structure inside an organization 🤷♀️ That said, the following naming architecture is suggested:
+----------------+-----+----------------------+----------+-------------+
| 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, if you're a visual person like me, here's the pictorial version 👀
(------------)
(organization)
(------------)
|
|<------------------------------+
| |
+--->(organizationalUnit)-------+
| |
+--->(locality)-----------------+
|
+--->(organizationalRole)
|
+--->(organizationalPerson)
|
+--->(applicationProcess)--->(nadfApplicationEntity)
|
+--->(groupOfNames)
|
+--->(ediUser)
|
+--->(device)6.2. Persons
Listing organizational persons is a local matter, so each organization handles it however it wants 💅
Residential persons get identified by the place where they live 🏠 This is usually a multi-valued RDN made of a commonName attribute value and some other distinguishing attribute value. The obvious picks would be something like postalCode or streetAddress, but heads up, this info may be considered private 🙈 So, a different distinguishing attribute value can be used instead, maybe even a serial number attribute value whose only job is to make the entry unique. (Just so you know, an attribute like that isn't helpful for searching! Other attribute values with meaningful info should be added to the entry and made available for public access, so people can actually select the right one 🔑)
The RDN you use when listing residential persons depends on where the listing is going 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 foreign persons is for further study 🌍
7. Usage Examples 💖
In the examples coming up, the * character stands for any arbitrary value of an attribute type 🎀
7.1. Organizations with National-Standing
Say the organization
Lawrence Livermore National Laboratory
has national-standing because the US Congress chartered it 🇺🇸 Based on the table in Section 6.1, this organization gets to list itself as any (or all) of these names:
(1) national-listing:
{ c=US,
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 } }Now say the organization
Performance Systems International, Inc.
has national-standing because it has an alphanumeric nameform in the ANSI registry 📇 Based on the table in Section 6.1, this organization gets to list as any (or all) of these names:
(1) national-listing:
{ c=US, o=Performance Systems International }
(2) regional-listing:
{ c=US, st=*,
{ o=Performance Systems International, c=US } }
(3) local-listing:
{ c=US, st=*, l=*,
{ o=Performance Systems International, c=US } }7.2. Organizations with Regional-Standing
Okay, next up is the organization
Network Management Associates, Inc.
which has regional-standing thanks to a DBA registration with the Secretary of State for the State of California 🌴 Based on the table in Section 6.1, this organization gets to list as any (or all) of these names:
(1) national-listing:
{ c=US,
{ o=Network Management Associates,
st=California } }
(2) regional-listing:
{ c=US, st=California,
o=Network Management Associates }
(3) local-listing:
{ c=US, st=California, l=*,
o=Network Management Associates }Further, in some state other than California, this organization might also list as:
(1) regional-listing:
{ c=US, st=*,
{ o=Network Management Associates,
st=California } }
(2) local-listing:
{ c=US, st=*, l=*,
{ o=Network Management Associates,
st=California } }7.3. Organizations with Local-Standing
Next, picture the tavern and eatery
St. James Infirmary
which has local-standing thanks to a DBA registration with the City Clerk for the City of Mountain View in the State of California 🍸 Based on the table in Section 6.1, this organization gets to list as any (or all) of these names:
(1) national-listing:
{ c=US,
{ o=St. James Infirmary, st=California,
fips55=49670 } }
(2) regional-listing:
{ c=US, st=California,
{ o=St. James Infirmary, fips55=49670 } }
(3) local-listing:
{ c=US, st=California, l=*,
{ o=St. James Infirmary, fips55=49670 } }Further, in some state other than California, this organization might also list as:
(1) regional-listing:
{ c=US, st=*,
{ o=St. James Infirmary, st=California,
fips55=49670 } }
(2) local-listing:
{ c=US, st=*, l=*,
{ o=St. James Infirmary, st=California,
fips55=49670 } }7.4. Organizations with Foreign-Standing
Last but not least, the five-star restaurant
Erik's Fisk
has foreign-standing because it has a DBA registration throughout Sweden 🇸🇪⭐ Based on the table in Section 6.1, this organization gets to list as any (or all) of these names:
(1) national-listing:
{ c=US,
{ o=Erik's Fisk, c=SE } }
(2) regional-listing:
{ c=US, st=*,
{ o=Erik's Fisk, c=SE } }
(3) local-listing:
{ c=US, st=*, l=*,
{ o=Erik's Fisk, c=SE } }7.5. Persons ✨
Okay so, let's say the person Marshall T. Rose lives in the City of Mountain View in the State of California and wants to be listed in the Directory 💁♀️. According to the table in Section 6.2, this person might be listed under any of these names:
- national-listing:
{ c=US,
{ cn=Marshall T. Rose, postalCode=94043-2112,
st=California, fips55=49670 } }- regional-listing:
{ c=US, st=California,
{ cn=Marshall T. Rose, postalCode=94043-2112,
fips55=49670 } }- local-listing:
{ c=US, st=California, l=Santa Clara,
{ cn=Marshall T. Rose, postalCode=94043-2112 } }Further, in some state other than California, this person might also list as:
- regional-listing:
{ c=US, st=*,
{ cn=Marshall T. Rose, postalCode=94043-2112,
st=California, fips55=49670 } }- local-listing:
{ c=US, st=*, l=*,
{ cn=Marshall T. Rose, postalCode=94043-2112,
st=California, fips55=49670 } }8. Bibliography 📚
X.500: The Directory -- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988.
US FIPS 5: Codes for the Identification of the States, The District of Columbia and Outlying Areas of the United States, and Associated Areas, US Department of Commerce FIPS 5-2, May 28, 1987.
US FIPS 55: Guideline: Codes for Named Populated Places, Primary County Divisions, and other Locational Entities of the United States and Outlying Areas, US Department of Commerce FIPS 55-2, February 3, 1987.
Appendix A: Revision History of this Scheme 🕰️
Okay, the history of this scheme is honestly iconic, so let's go through it 🎀
The first version of this scheme (NADF-71) was contributed to the North American Directory Forum at its November 27-30, 1990 meeting. The (mis)features were:
- Because of the lack of confidence in ANSI registration procedures, it was proposed that the US trademarks be used as the basis for RDNs of organizations with national-standing. This proved unworkable since the same trademark may be issued to different organizations in different industries.
- There was no pre-existing registry used for populated places. This proved unworkable since the effort to define a new registry is problematic.
The second version of this scheme was contributed to the ANSI Registration Authority Committee at its January 30, 1991 meeting, and the IETF OSI Directory Services Working Group at its February 12-13, 1991 meeting. The (mis)features were:
- 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 choice of numeric rather than alphanumeric name forms was unpopular, but was motivated by the desire to avoid using the ANSI alphanumeric name form registry, which was perceived as unstable.
The third version of this scheme was contributed to US State Department Study Group D's MHS-MD subcommittee at its March 7-8 1991 meeting. That version used alphanumeric name forms for all objects, under the perception that the ANSI alphanumeric name form registry will prove stable. If the ANSI alphanumeric name form registry proves unstable, then two alternatives are possible:
- disallow organizations with national-standing in the US portion of the DIT; or,
- use the ANSI numeric name form registry instead.
Hopefully neither of these two undesirable alternatives will prove necessary 🤞
The fourth version of this scheme (NADF-103) was contributed to the NADF at its March 18-22, 1991 meeting. This version introduced the notion of organizations with regional standing being listed at the national level through the use of alias names and multi-valued RDNs.
The fifth version of this scheme (NADF-123) was produced at the NADF meeting (and also published in the Internet community as RFC1212). This version generalized the listing concept by introducing the notion of optimized civil naming. Further, the document was edited to clearly note the different naming sub-structures and the relation between them.
The sixth version of this scheme (NADF-143) was contributed to the NADF before its July 9-12, 1991 meeting, and was edited to reflect comments received from the Internet and other communities. The changes were:
- The schema definitions were removed from Appendix A and placed in a separate document, NADF-132. In NADF-132: the prefix object-identifier was changed (the original assignment was in error); and, the definition of a "nadfADDMD" object was considerably expanded.
- States and state-equivalents are now named using attribute values of
stateOrProvinceName. - Populated places now correspond to counties, though FIPS 55 is still used extensively.
- The text of this document was reworked to more clearly distinguish between registration and listing.
- The
foreignOrganizationandfips55Objectobject classes were added.
The seventh version of this scheme (NADF-166) was produced at the NADF meeting. It made a few changes:
- It was noted that organizations with local standing may need additional distinguishing attributes when listing.
- The
usOrganizationobject class was removed and replaced with the auxiliary object classansiOrgObject. - The
foreignOrganizationobject class was removed and replaced with the auxiliary object classnationalObject. This may be used when listing any organization of national standing (regardless of whether that organization is US-based). For example, an organization with US national-standing would need this when being listed at the regional or local level. - Figures corresponding to the DIT structures were added, along with some minor additional text in the usage examples.
- The Acknowledgements section, long out of date, was removed.
The eighth (current) version of this scheme was produced after the NADF meeting. It corrects a few typographical errors. 💅
Security Considerations 🔐
Security issues are not discussed in this memo.
Author's Address 💌
North American Directory Forum
c/o Theodore H. Myer
Rapport Communication, Inc.
3055 Q Street NW
Washington, DC 20007
Tel: +1 202-342-2727📦 where this page comes from
- ietf: rfc1255 1991-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms