📄 rfc1218.txt
字号:
Network Working Group The North American Directory ForumRequest for Comments: 1218 April 1991 A Naming Scheme for c=USStatus of this Memo This memo provides information for the Internet community. It does not specify an Internet standard. Distribution of this memo is unlimited.Summary This RFC is a near-verbatim copy of a document, known as NADF-123, which has been produced by the North American Directory Forum (NADF). The NADF is a collection of organizations which offer, or plan to offer, public Directory services in North America, based on the CCITT X.500 Recommendations. As a part of its charter, the NADF must reach agreement as to how entries are named in the public portions of the North American Directory. NADF-123 is a scheme proposed for this purpose. The NADF is circulating NADF-123 widely, expressly for the purpose of gathering comments. The next meeting of the NADF is in mid-July, and it is important for comments to be received prior to the meeting, so that the scheme may receive adequate review. A Naming Scheme for c=US The North American Directory Forum NADF-123 Supercedes: NADF-103, NADF-71 March 21, 1991ABSTRACT 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 Computer networks form the infrastructure between the users they interconnect. For example, the electronic mail service offered by computer networks provides a means for users to collaborate towards some common goal. In the simplest cases, this collaboration may be solely for the dissemination of information. In other cases, twoNADF [Page 1]RFC 1218 A Naming Scheme for c=US April 1991 users may work on a joint research project, using electronic mail as their primary means of communication. However, networks themselves are built on an underlying naming and numbering infrastructure, usually in the form of names and addresses. For example, some authority must exist to assign network addresses to ensure that numbering collisions do not occur. This is of paramount importance for an environment which consists of multiple service providers.2. Approach It should be observed that there are several different naming universes that can be realized in the Directory Information Tree (DIT). For example, geographical naming, community naming, political naming, organizational naming, and so on. The choice of naming universe largely determines the difficulty in mapping a user's query into a series of Directory operations. Although it is possible to simultaneously support multiple naming universes with the DIT, this is likely to be unnatural. As such, this proposal focuses on a single naming universe. The naming universe in this proposal is based on civil authority. That is, it uses the existing civil naming infrastructure and suggests a (nearly) straight-forward mapping on the DIT. There are four components to the naming architecture: (1) civil naming and optimized civil naming, which reflects names assigned by civil authority; (2) organizational naming, which reflects names assigned within organizations; (3) ADDMD naming, which reflects names assigned to public providers within the Directory service; and, (4) application naming, which reflects names assigned to OSI entities. An important characteristic is that entries should be listed wherever searches for them are likely to occur. This implies that a single object may be listed under several entries.2.1. Names and User-Friendliness It must be emphasized that there are three distinct concepts which 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 which allows users to easily identity objects; (2) user-friendly name: a technique for naming an object which exhibits "friendliness" according to an arbitrary set of user-criteria; and, (3) Distinguished Name: the administratively assigned name for an entry in the OSI Directory. It must be emphasized that Distinguished Names are not necessarily user-friendly names, and further, that user-friendly naming in the Directory is a property of the Directory Service, not of Distinguished Names.2.2. Choice of RDN Names The key aspect to appreciate for choice of RDNs is that they should provide a large name space to avoid collisions: the naming strategy must provide enough "real estate" to accommodate a large demand for entries. This is the primary requirement for RDNs. A secondary requirement is that RDNs should be meaningful (friendly to people) and should not impede searching. However, it is important to understand that this second requirement can be achieved by using additional (non-distinguished) attribute values. For example, if the RDN of an entry is organizationName is Performance Systems International then it is perfectly acceptable (and indeed desirable) to have other values for the organizationName attribute, e.g., organizationName is PSI The use of these abbreviated names greatly aids searching whilst avoiding unnecessary Distinguished Name conflicts. In order to appreciate the naming scheme which follows, it is important to understand that it leverages, wherever possible, existing naming infrastructure. That is, it relies heavily on non- OSI naming authorities which already exist. Note that inasmuch as it relies on existing naming authorities, there is little chance that any "final" national decision could obsolete 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 andNADF [Page 3]RFC 1218 A Naming Scheme for c=US April 1991 regional infrastructure, and establishes some entirely new and different national naming infrastructure.)3. Civil Naming Civil naming occurs at three levels: (1) the national level, which contains objects that are recognized throughout a country; (2) the regional level, which contains objects that are recognized throughout a state or state-equivalent; and, (3) 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: (1) The States and State-Equivalents (2) Organizations with National Standing (3) ADDMD Operators3.1.1. The States and State-Equivalents For each state or state-equivalent (the District of Columbia and the eight outlying areas [Footnote: i.e., American Samoa, Federated States of Micronesia, Guam, Marshall Islands, Northern Mariana Islands, Palau, Puerto Rico, and Virgin Islands of the US.]), an instance of an usStateOrEquivalent object is used. The RDN is formed as localityName is <FIPS 5 name> e.g., localityName is California provides 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.,NADF [Page 4]RFC 1218 A Naming Scheme for c=US April 1991 fipsStateNumericCode is 06 fipsStateAlphaCode is CA Of course, this entry could contain many other attributes such as stateOrProvinceName is State of California3.1.2. Organizations with National Standing There is no authority in the United States which 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 an usOrganization object is used. The RDN is formed as organizationName is <ANSI alphanumeric name form> e.g., organizationName is Performance Systems International In addition, this entry would contain attributes identifying the ANSI Alphanumeric name form, e.g., ansiOrgNumericCode is 177777 Of course, this entry would contain many other attributes such as organizationName is PSI For 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 which 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. (AtNADF [Page 5]RFC 1218 A Naming Scheme for c=US April 1991 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: (1) Populated Places (2) Organizations with Regional Standing3.2.1. Populated Places For each populated place within a state or state-equivalent, an instance of an usPlace object is used. The RDN is formed as localityName is <FIPS 55 name> e.g., localityName is Hartford provides 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 37000NADF [Page 6]RFC 1218 A Naming Scheme for c=US April 19913.2.2. Organizations with Regional Standing An organization is said to have regional standing if it is registered 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 an organization object is used. The RDN is formed as organizationName is <registered name of organization> e.g., organizationName is Network Management Associates might 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: (1) Persons (2) Organizations with Local Standing (3) MHS Distribution ListsNADF [Page 7]RFC 1218 A Naming Scheme for c=US April 19913.3.1. Naming of Persons Within a populated place, there is no centralized naming entity which registers residential persons. It is proposed that entries for persons be immediately subordinate to the usPlace object which most accurately reflects their place of residence. For each person (wishing to have an entry in the Directory), an instance of a residentialperson residentialPerson object is used. The RDN is usually multi-valued, formed with commonName is <person's full name> and some other attribute, such as postalCode, streetAddress, etc. However, because streetAddress is often considered private information, based on agreement with the entity managing the DMD and the listed person, some other, distinguishing attribute may be used, including a "serial number" (having no other purpose). It should be noted however that this is non-helpful in regards to searching, unless other attribute values containing meaningful information are added to the entry and made available for public access.3.3.2. Organizations with Local Standing An organization is said to have local standing if it is registered with the County or City Clerk or similar entity within that locality as an entity "doing business" in that place. For each organization with local standing, an instance of an
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -