Network Working Group A. Grimstad
Request for Comments: 2377 R. Huber
Category: Informational AT&T
S. Sataluri
Lucent Technologies
M. Wahl
Critical Angle Inc.
September 1998
Network Working Group A. Grimstad
Request for Comments: 2377 R. Huber
Category: Informational AT&T
S. Sataluri
Lucent Technologies
M. Wahl
Critical Angle Inc.
September 1998
Naming Plan for Internet Directory-Enabled Applications
启用Internet目录的应用程序的命名计划
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. We propose a new directory naming plan that leverages the strengths of the most popular and successful Internet naming schemes for naming objects in a hierarchical directory. This plan can, we believe, by extending the X.500 approach to naming, facilitate the creation of an Internet White Pages Service (IWPS) and other directory-enabled applications by overcoming the problems encountered by those using the conventional X.500 approach.
根据作者的经验，到目前为止，传统的X.500命名方法的应用已被证明是在Internet上广泛部署支持目录的应用程序的一个障碍。我们提出了一个新的目录命名计划，它利用了最流行和最成功的Internet命名方案的优点来命名分层目录中的对象。我们相信，通过扩展X.500命名方法，该计划可以克服使用传统X.500命名方法的用户所遇到的问题，从而促进Internet白页服务（IWPS）和其他支持目录的应用程序的创建。
Application of the conventional X.500 approach to naming has heretofore, in the experience of the authors, proven to be an obstacle to the wide deployment of directory-enabled applications on the Internet. The required registration infrastructure is either non-existent or largely ignored. The infrastructure that does exist is cumbersome to use and tends to produce counterproductive results. The attributes used for naming have been confusing for users and inflexible to managers and operators of directory servers.
根据作者的经验，到目前为止，传统的X.500命名方法的应用已被证明是在Internet上广泛部署支持目录的应用程序的一个障碍。所需的注册基础设施要么不存在，要么基本上被忽略。现有的基础设施使用起来很麻烦，往往会产生适得其反的结果。用于命名的属性让用户感到困惑，并且对目录服务器的管理者和操作员来说缺乏灵活性。
This paper describes a directory naming plan for the construction of an Internet directory infrastructure to support directory-enabled applications that can serve as an alternative (or extension) to the conventional X.500 approach.
本文描述了一个目录命名计划，用于构建Internet目录基础设施，以支持支持支持目录的应用程序，该应用程序可以作为传统X.500方法的替代（或扩展）。
The plan has the following two main features. First, it bases the root and upper portions of the name hierarchy on the existing infrastructure of names from the Domain Name System (DNS). This component of the plan makes use of the ideas described in the companion paper to this plan, "Using Domains in LDAP Distinguished Names" [1]. And second, it provides a number of options for the assignment of names to directory leaf objects such as person objects, including an option that allows the reuse of existing Internet identifiers for people.
该计划有以下两个主要特点。首先，它将名称层次结构的根和上部基于域名系统（DNS）的现有名称基础结构。该计划的这一部分利用了本计划的配套文件“使用LDAP专有名称中的域”[1]中描述的思想。第二，它提供了许多用于将名称分配给目录叶对象（如person对象）的选项，包括一个允许为用户重用现有Internet标识符的选项。
Just as the conventional X.500 style of naming is not a formal standard, use of the naming plan described here is not obligatory for directory-enabled applications on the Internet. Other approaches are permissible. However, we believe widespread use of this plan will largely eliminate naming as a typically thorny issue when administrators set up an LDAP-based directory service. Further, we strongly encourage developers of directory-enabled products, especially LDAP clients and user interfaces, to assume that this naming plan will see widespread use and design their products accordingly.
正如传统的X.500命名风格不是正式的标准一样，这里描述的命名计划对于Internet上支持目录的应用程序不是强制性的。其他方法是允许的。然而，我们相信，当管理员设置基于LDAP的目录服务时，广泛使用该计划将在很大程度上消除命名这一典型的棘手问题。此外，我们强烈鼓励支持目录的产品（尤其是LDAP客户端和用户界面）的开发人员假设此命名计划将得到广泛使用，并相应地设计其产品。
Here, in summary, is our proposal.
总而言之，这是我们的建议。
The upper portions of the hierarchical directory tree should be constructed using the components of registered DNS names using the domain component attribute "dc". The directory name for the organization having the domain name "acme.com" will then be, e.g.,
层次目录树的上部应该使用域组件属性“dc”的已注册DNS名称的组件来构造。域名为“acme.com”的组织的目录名将是，例如。，
dc=acme, dc=com
dc=acme，dc=com
Organizations can add additional directory structure, for example to support implementation of access control lists or partitioning of their directory information, by using registered subdomains of DNS names, e.g., the subdomain "corporate.acme.com" can be used as the basis for the directory name
组织可以添加额外的目录结构，例如通过使用DNS名称的注册子域来支持访问控制列表的实现或其目录信息的分区，例如，子域“corporate.acme.com”可以用作目录名称的基础
dc=corporate, dc=acme, dc=com
dc=corporate, dc=acme, dc=com
For naming directory leaf objects such as persons, groups, server applications and certification authorities in a hierarchical directory, we propose the use of either the "uid" (user identifier) or the "cn" (common name) attribute for the relative distinguished name. This plan does not constrain how these two attributes are used.
对于在分层目录中命名目录叶对象（如人员、组、服务器应用程序和证书颁发机构），我们建议使用“uid”（用户标识符）或“cn”（公共名称）属性作为相对可分辨名称。此计划不限制如何使用这两个属性。
One approach to their use, for example, is to employ the uid attribute as the RDN when reusing an existing store of identifiers and the cn attribute as the RDN when creating new identifiers specifically for the directory. A convenient existing identification scheme for person objects is the RFC822 mailbox identifier. So an RDN for person employing this store of identifiers would be, e.g.,
例如，使用它们的一种方法是在重用现有标识符存储时使用uid属性作为RDN，在专门为目录创建新标识符时使用cn属性作为RDN。RFC822邮箱标识符是一种方便的现有个人对象标识方案。因此，使用此标识符存储的人员的RDN将是，例如。，
uid=John.Smith@acme.com
uid=约翰。Smith@acme.com
For leaf objects not conveniently identified with such a scheme, the "cn" attribute is used, e.g.,
对于不能方便地用这种方案识别的叶子对象，使用“cn”属性，例如。，
cn=Reading Room
cn=阅览室
Directory distinguished names will thus have the following structure, e.g.,
因此，目录可分辨名称将具有以下结构，例如。，
uid=John.Smith@acme.com, dc=acme, dc=com
uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
cn=Reading Room, dc=physics, dc=national-lab, dc=edu
uid=John.Smith@acme.com, dc=acme, dc=com
uid=Mary.Jones@acme.com, dc=corporate, dc=acme, dc=com
uid=J.Smith@worldnet.att.net, dc=legal, dc=acme, dc=com
cn=Reading Room, dc=physics, dc=national-lab, dc=edu
The X.500 Directory model [2] can be used to create a world-wide distributed directory. The Internet X.500 Directory Pilot has been operational for several years and has grown to a size of about 1.5 million entries of varying quality. The rate of growth of the pilot is far lower than the rate of growth of the Internet during the pilot period.
X.500目录模型[2]可用于创建全球分布式目录。Internet X.500目录试点已经运行了几年，已经发展到大约150万个不同质量的条目。试点期间的增长速度远远低于互联网的增长速度。
There are a substantial number of contributing factors that have inhibited the growth of this pilot. The common X.500 approach to naming, while not the preponderant problem, has contributed in several ways to limit the growth of an Internet White Pages Service based on X.500.
抑制该试点发展的因素很多。通用的X.500命名方法虽然不是主要问题，但在多个方面限制了基于X.500的互联网白页服务的增长。
The conventional way to construct names in the X.500 community is documented as an informative (i.e., not officially standardized) Annex B to X.521. The relative distinguished name (RDN) of a user consists of a common name (cn) attribute. This is meant to be what -- in the user's particular society -- is customarily understood to be the name of that user. The distinguished name of a user is the combination of the name of some general object, such as an organization or a geographical unit, with the common name. There are two main problems with this style of name construction.
X.500社区中构造名称的传统方法记录为X.521附录B中的信息性（即，未正式标准化）。用户的相对可分辨名称（RDN）由公共名称（cn）属性组成。这意味着——在用户的特定社会中——习惯上理解为该用户的名字。用户的可分辨名称是某些通用对象（如组织或地理单位）的名称与通用名称的组合。这种名称结构有两个主要问题。
First, the common name attribute, while seeming to be user-friendly, cannot be used generally as an RDN in practice. In any significant set of users to be named under the same Directory Information Tree (DIT) node there will be collisions on common name. There is no way to overcome this other than either by forcing uniqueness on common names, something they do not possess, or by using an additional attribute to prevent collisions. This additional attribute normally needs to be unique in a much larger context to have any practical value. The end result is a RDN that is very long and unpopular with users.
首先，commonname属性虽然看起来是用户友好的，但实际上不能作为RDN使用。在同一目录信息树（DIT）节点下命名的任何重要用户集中，公共名称都会发生冲突。要克服这一点，除了对通用名称强制唯一性（通用名称不具备这一点）或使用附加属性来防止冲突之外，没有其他方法。这个附加属性通常需要在更大的上下文中是唯一的，才能有任何实际价值。最终的结果是RDN非常长，不受用户欢迎。
Second, and more serious, X.500 has not been able to use any significant number of pre-existing names. Since X.500 naming models typically use organization names as part of the hierarchy [2, 3], organization names must be registered. As organization names are frequently tied to trademarks and are used in sales and promotions, registration can be a difficult and acrimonious process.
其次，更严重的是，X.500无法使用任何数量可观的预先存在的名称。由于X.500命名模型通常使用组织名称作为层次结构的一部分[2,3]，因此必须注册组织名称。由于组织名称经常与商标联系在一起，并用于销售和促销，因此注册可能是一个困难而激烈的过程。
The North American Directory Forum (NADF, now the North Atlantic Directory Forum but still the NADF) proposed to avoid the problem of registration by using names that were already registered in the "civil naming infrastructure" [4][5]. Directory distinguished names would be based on an organization's legal name as recognized by some governmental agency (county clerk, state secretary of state, etc.) or other registering entity such as ANSI.
北美目录论坛（NADF，现在的北大西洋目录论坛，但仍然是NADF）建议通过使用已经在“民事命名基础设施”中注册的名称来避免注册问题[4][5]。目录专有名称将基于某个政府机构（县书记员、州务卿等）或其他注册实体（如ANSI）认可的组织法定名称。
This scheme has the significant advantage of keeping directory service providers out of disputes about the right to use a particular name, but it leads to rather obscure names. Among these obscurities, the legal name almost invariably takes a form that is less familiar and longer than what users typically associate with the organization. For example, in the US a large proportion of legal organization names end with the text ", Inc." as in "Acme, Inc." Moreover, in the case of the US, the civil naming infrastructure does not operate nationally, so the organization names it provides must be located under state and regional DIT nodes, making them difficult to find while browsing the directory. NADF proposes a way to algorithmically derive multi-attribute RDNs which would allow placement of entries or aliases in more convenient places in the DIT, but these derived names are cumbersome and unpopular. For example, suppose Nadir is an organization that is registered in New Jersey civil naming infrastructure under the name "Nadir Networks, Inc." Its civil distinguished name (DN) would then be
该方案的显著优点是使目录服务提供商免于就使用特定名称的权利发生争议，但它会导致名称相当模糊。在这些晦涩难懂的名称中，法定名称几乎总是采用一种比用户通常与组织联系的形式更不熟悉、更长的形式。例如，在美国，与“Acme，Inc.”一样，很大一部分合法组织名称以文本“Inc.”结尾。此外，在美国，民事命名基础设施不在全国范围内运行，因此其提供的组织名称必须位于州和地区DIT节点下，在浏览目录时很难找到它们。NADF提出了一种算法推导多属性RDN的方法，该方法允许将条目或别名放置在DIT中更方便的位置，但这些派生名称既麻烦又不受欢迎。例如，假设Nadir是一家在新泽西civil naming infrastructure注册的名为“Nadir Networks，Inc.”的组织，其civil可分辨名称（DN）将为
o="Nadir Networks, Inc.", st=New Jersey, c=US
o="Nadir Networks, Inc.", st=New Jersey, c=US
while its derived name which is unambiguous under c=US directly is
而其派生名称（在c=US下明确无误）是
o="Nadir Networks, Inc." + st=New Jersey, c=US
o="Nadir Networks, Inc." + st=New Jersey, c=US
More generally, the requirement for registration of organizations in X.500 naming has led to the establishment of national registration authorities whose function is mainly limited to assignment of X.500 organization names. Because of the very limited attraction of X.500, interest in registering an organization with one of these national authorities has been minimal. Finally, multi-national organizations are frustrated by a lack of an international registration authority.
更一般地说，X.500命名中组织注册的要求导致建立了国家注册机构，其职能主要限于分配X.500组织名称。由于X.500的吸引力非常有限，在这些国家当局之一登记一个组织的兴趣微乎其微。最后，多国组织因缺乏国际登记机构而感到沮丧。
A directory naming plan must provide a guide for the construction of names (identifiers, labels) for directory objects that are unambiguous (identify only one directory object) within some context (namespace), at a minimum within one isolated directory server.
目录命名计划必须为目录对象的名称（标识符、标签）构造提供指南，这些目录对象在某些上下文（命名空间）中是明确的（仅标识一个目录对象），至少在一个独立的目录服务器中。
A directory object is simply a set of attribute values. The association between a real-world object and a directory object is made by directory-enabled applications and is, in the general case, one to many.
目录对象只是一组属性值。现实世界对象和目录对象之间的关联是由启用目录的应用程序实现的，在一般情况下是一对多的。
The following additional naming characteristics are requirements that this naming plan seeks to satisfy:
以下其他命名特征是本命名计划力求满足的要求：
a) hierarchical
a) 等级制的
The Internet, consisting of a very large number of objects and management domains, requires hierarchical names. Such names permit delegation in the name assignment process and partitioning of directory information among directory servers.
Internet由大量对象和管理域组成，需要分层名称。这样的名称允许在名称分配过程中进行委派，并在目录服务器之间对目录信息进行分区。
b) friendly to loose coupling of directory servers
b) 对目录服务器的松散耦合友好
One purpose of this naming plan is to define a naming pattern that will facilitate one form or another of loose coupling of potentially autonomous directory servers into a larger system.
此命名计划的一个目的是定义一个命名模式，该模式将促进潜在自治目录服务器以某种形式松散耦合到一个更大的系统中。
A name in such a loosely-coupled system should unambiguously identify one real-world object. The real-world object may, however, be represented differently (i.e. by different directory objects having different attributes but the same DN) in different (e.g. independently managed) servers in the loosely-coupled system. The plan does not attempt to produce names to overcome this likely scenario. That is, it does not attempt to produce a single namespace for all directory objects. (This issue is considered in more detail
在这样一个松散耦合的系统中，一个名称应该明确地标识一个真实世界的对象。然而，在松耦合系统中的不同（例如，独立管理的）服务器中，真实世界对象可以不同地表示（即，通过具有不同属性但具有相同DN的不同目录对象）。该计划没有试图提供名称来克服这种可能的情况。也就是说，它不会尝试为所有目录对象生成单个名称空间。（对这一问题进行了更详细的审议。）
in Section 5.1.)
在第5.1节中。）
c) readily usable by LDAP clients and servers
c) LDAP客户端和服务器易于使用
As of this writing, a substantial number of the Lightweight Directory Access Protocol (LDAP) [6][7] implementations are currently available or soon will be. The names specified by this naming plan should be readily usable by these implementations and applications based on them.
在撰写本文时，大量的轻量级目录访问协议（LDAP）[6][7]实现目前可用，或很快将可用。此命名计划指定的名称应可供这些实现和基于它们的应用程序使用。
d) friendly to re-use of existing Internet name registries
d) 易于重复使用现有的Internet名称注册中心
As described in Section 2 above, creation of new global name registries has been highly problematic. Therefore, a fundamental requirement this plan addresses is to enable the reuse of existing Internet name registries such as DNS names and RFC822 mailbox identifiers when constructing directory names.
如上文第2节所述，创建新的全球名称登记册问题重重。因此，该计划提出的一个基本要求是，在构建目录名时，允许重用现有的Internet名称注册中心，如DNS名称和RFC822邮箱标识符。
e) minimally user-friendly
e) 用户友好程度最低
Although we expect that user interfaces of directory-enabled applications will avoid exposing users to DNs, it is unlikely that users can be totally insulated from them. For this reason, the naming plan should permit use of familiar information in name construction. Minimally, a user should be capable of recognizing the information encoded in his/her own DN. Names that are totally opaque to users cannot meet this requirement.
尽管我们期望目录启用应用程序的用户界面将避免将用户暴露于DNs，但用户不太可能完全与DNs隔离。因此，命名计划应允许在名称构造中使用熟悉的信息。至少，用户应该能够识别他/她自己的DN中编码的信息。对用户完全不透明的名称不能满足此要求。
The paper assumes familiarity with the terminology and concepts behind the terms distinguished name (DN) and relative distinguished name (RDN) [2][8][9].
本文假设读者熟悉专有名称（DN）和相对专有名称（RDN）[2][8][9]这两个术语背后的术语和概念。
We describe how DNs can be constructed using three attribute types, domainComponent (dc), userID (uid) and commonName (cn). They are each described in turn.
我们描述了如何使用三种属性类型来构造DNs，即domainComponent（dc）、userID（uid）和commonName（cn）。它们依次被描述。
The domain component attribute is defined and registered in RFC1274 [3][10]. It is used in the construction of a DN from a domain name. Details of the construction algorithm is described in "Using Domains in LDAP Distinguished Names" [1].
域组件属性在RFC1274[3][10]中定义并注册。它用于从域名构造DN。构造算法的详细信息在“使用LDAP可分辨名称中的域”[1]中进行了描述。
An organization wishing to deploy a directory following this naming plan would proceed as follows. Consider an organization, for example "Acme, Inc.", having the registered domain name "acme.com". It would
希望按照此命名计划部署目录的组织将按以下步骤进行。考虑一个组织，例如“ACME公司”，有注册域名“ACME .com”。会的
construct the DN
构建DN
dc=acme, dc=com
dc=acme，dc=com
from its domain name. It would then use this DN as the root of its subtree of directory information.
从它的域名。然后，它将使用此DN作为其目录信息子树的根。
The DN itself can be used to identify a directory organization object that represents information about the organization. The directory schema required to enable this is described below in section 5.2.
DN本身可用于标识表示组织信息的目录组织对象。启用此功能所需的目录架构将在下面的第5.2节中描述。
The subordinates of the DN will be directory objects related to the organization. The domain component attribute can be used to name subdivisions of the organization such as organizational units and localities. Acme, for example, might use the domain names "corporate.acme.com" and "richmond.acme.com" to construct the names
DN的下属将是与组织相关的目录对象。“域组件”属性可用于命名组织的子部门，如组织单位和地区。例如，Acme可能使用域名“corporate.Acme.com”和“richmond.Acme.com”来构造名称
dc=corporate, dc=acme, dc=com
dc=richmond, dc=acme, dc=com
dc=corporate, dc=acme, dc=com
dc=richmond, dc=acme, dc=com
under which to place its directory objects. The directory schema required to name organizationalUnit and locality objects in this way is described below in section 5.2.
在其下放置其目录对象。以这种方式命名organizationalUnit和Location对象所需的目录模式将在下面的第5.2节中描述。
Note that subdivisions of the organization such as organizational units and localities could also be assigned RDNs using the conventional X.500 naming attributes, e.g.
请注意，也可以使用传统的X.500命名属性为组织的子部门（如组织单位和地点）分配RDN，例如。
ou=corporate, dc=acme, dc=com l=richmond, dc=acme, dc=com.
ou=corporate，dc=acme，dc=com l=richmond，dc=acme，dc=com。
Use of the dc attribute for the RDN of directory objects of class "domain" is also possible [1].
也可以为“domain”类目录对象的RDN使用dc属性[1]。
The userid (uid) attribute is defined and registered in RFC1274 [3][10].
用户ID（uid）属性在RFC1274[3][10]中定义和注册。
This attribute may be used to construct the RDN for directory objects subordinate to objects named according to the procedure described in Section 4.1. This plan does not constrain how this attribute is used.
该属性可用于为从属于根据第4.1节所述程序命名的对象的目录对象构造RDN。此计划不限制如何使用此属性。
The commonName (cn) attribute is defined and registered in X.500 [3][11].
commonName（cn）属性在X.500[3][11]中定义和注册。
This attribute may be used to construct the RDN for directory objects subordinate to objects named according to the procedure described in Section 4.1. This plan does not constrain how this attribute is used.
该属性可用于为从属于根据第4.1节所述程序命名的对象的目录对象构造RDN。此计划不限制如何使用此属性。
Although this plan places no constraints on the use of the uid and cn attributes for name construction, we would like to offer some suggestions by way of examples.
尽管这个计划没有限制uid和cn属性在名称构造中的使用，我们还是想通过示例提供一些建议。
In practice, we have used uid for the RDN for person objects were we could make use of an existing registry of names and cn for other objects.
在实践中，我们使用uid作为person对象的RDN，因为我们可以使用现有的名称注册中心和其他对象的cn。
Examples of existing registries of identifiers for person objects are RFC822 mailbox identifiers, employee numbers and employee "handles". Aside from the convenience to administrators of re-use of an existing store of identifiers, if it is ever necessary to display to a user his/her DN, there is some hope that it will be recognizable when such identifiers are used.
person对象的现有标识符注册的示例有RFC822邮箱标识符、员工编号和员工“句柄”。除了方便管理员重新使用现有的标识符存储之外，如果有必要向用户显示他/她的DN，则在使用此类标识符时，它将是可识别的。
We have found RFC822 mailbox identifiers a particularly convenient source for name construction. When a person has several e-mail addresses, one will be selected for the purpose of user identification. We call this the "distinguished" e-mail address or the "distinguished" RFC822 mailbox identifier for the user.
我们发现，RFC822邮箱标识符是构建名称的一个特别方便的来源。当一个人有多个电子邮件地址时，将选择一个用于用户标识。我们将其称为用户的“可分辨”电子邮件地址或“可分辨”RFC822邮箱标识符。
For example, if there is a user affiliated with the organization Acme having distinguished e-mail address J.Smith@acme.com, the uid attribute will be:
例如，如果组织Acme的附属用户具有可分辨电子邮件地址J。Smith@acme.com，uid属性将为：
uid=J.Smith@acme.com
uid=J。Smith@acme.com
The domain component attributes of a user's DN will normally be constructed from the domain name of his/her distinguished e-mail address. That is, for the user uid=J.Smith@acme.com the domain component attributes would typically be:
用户DN的域组件属性通常由其可分辨电子邮件地址的域名构成。也就是说，对于用户uid=J。Smith@acme.com域组件属性通常为：
dc=acme, dc=com
dc=acme，dc=com
The full LDAP DN for this user would then be:
该用户的完整LDAP DN将是：
uid=J.Smith@acme.com, dc=acme, dc=com
uid=J.Smith@acme.com, dc=acme, dc=com
Directory administrators having several RFC822 identifiers to choose from when constructing a DN for a user should consider the following factors:
目录管理员有几个RCF822标识符来选择，当为用户构建一个DN时，应该考虑以下因素：
o Machine-independent addresses are likely to be more stable, resulting in directory names that change less. Thus an identifier such as:
o 与机器无关的地址可能更稳定，从而导致目录名的更改更少。因此，需要一个标识符，例如：
js@acme.com
js@acme.com
may well be preferable to one such as:
很可能比以下情况更好：
js@blaster.third-floor.acme.com.
js@blaster.third-floor.acme.com。
o Use of some form of "handle" for the "local" part that is distinct from a user's real name may result in fewer collisions and thereby lessen user pain and suffering. Thus the identifier:
o 对“本地”部分使用某种形式的“句柄”（与用户的真实姓名不同）可能会减少冲突，从而减轻用户的痛苦和痛苦。因此，标识符：
js@acme.com
js@acme.com
may well be preferable to one such as:
很可能比以下情况更好：
J.Smith@acme.com
JSmith@acme.com
Practical experience with use of the RFC822 mailbox identifier scheme described here has shown that there are situations where it is convenient to use such identifies for all users in a particular population, although a few users do not, in fact, possess working mailboxes. For example, an organization may have a existing unique identification scheme for all employees that is used as a alias to the employees' real mailboxes -- which may be quite heterogeneous in structure. The identification scheme works for all employees to identify unambiguously each employee; it only works as an e-mail alias for those employees having real mailboxes. For this reason it would be a bad assumption for directory-enabled applications to assume the uid to be a valid mailbox; the value(s) of the mail attribute should always be checked.
使用此处描述的RFC822邮箱标识符方案的实际经验表明，在某些情况下，为特定人群中的所有用户使用此类标识符是方便的，尽管事实上少数用户没有工作邮箱。例如，一个组织可能对所有员工都有一个现有的唯一标识方案，该方案用作员工真实邮箱的别名，其结构可能非常异构。识别方案适用于所有员工，以明确识别每个员工；它只能作为具有真实邮箱的员工的电子邮件别名。出于这个原因，启用目录的应用程序假设uid是有效邮箱是一个错误的假设；应始终检查邮件属性的值。
It is important to emphasize that the elements of the domain name of an RFC822 identifier may, BUT NEED NOT, be the same as the domain components of the DN. This means that the domain components provide a degree of freedom to support access control or other directory structuring requirements that need not be mechanically reflected in the user's e-mail address. We do not want under any condition to force the user's e-mail address to change just to facilitate a new system requirement such as a modification in an access control structure. It should also be noted that while we do not require that the domain components match the RFC822 identifier, we DO require that the concatenated domain components form a registered domain name, that is, one that is represented in the DNS. This automatically avoids name conflicts in the directory hierarchy.
必须强调的是，RFC822标识符的域名元素可以（但不必）与DN的域组件相同。这意味着域组件提供一定程度的自由度来支持访问控制或其他目录结构要求，这些要求不需要机械地反映在用户的电子邮件地址中。我们不希望在任何情况下仅仅为了满足新的系统需求（如修改访问控制结构）而强制用户更改电子邮件地址。还应注意，虽然我们不要求域组件与RFC822标识符匹配，但我们确实要求连接的域组件形成注册域名，即DNS中表示的域名。这会自动避免目录层次结构中的名称冲突。
To provide an example of a DN which deviates from what might be considered the default structure, consider the following scenario.
为了提供一个DN的例子，它偏离了可能被认为是默认结构的情况，请考虑下面的场景。
Suppose that J.Smith needs to be granted special permissions to information in the dc=acme, dc=com part of the LDAP DIT. Since it will be, in general, easier to organize special users by their name structure than via groups (an arbitrary collection of DNs), we use subdomains for this purpose. Suppose the special permissions were required by users in the MIS organizational unit. A subdomain "mis.acme.com" is established, if it does not already exist, according to normal DNS procedures. The special permissions will be granted to users with the name structure:
假设J.Smith需要被授予对LDAP DIT的dc=acme，dc=com部分中的信息的特殊权限。一般来说，通过名称结构组织特殊用户比通过组（DNs的任意集合）更容易，因此我们使用子域来实现这一目的。假设MIS组织单元中的用户需要特殊权限。如果子域“mis.acme.com”不存在，则根据正常DNS程序建立子域“mis.acme.com”。特殊权限将授予具有以下名称结构的用户：
uid=*, dc=mis, dc=acme, dc=com
uid=*, dc=mis, dc=acme, dc=com
The DN of J.Smith in this case will be:
在这种情况下，J.Smith的DN为：
uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
uid=J.Smith@acme.com, dc=mis, dc=acme, dc=com
In principal, there is nothing to prevent the domain name elements of the RFC822 identifier from being completely different from the domain components of the DN. For instance, the DN for a J.Smith could be:
原则上，没有什么可以阻止RFC822标识符的域名元素与DN的域组件完全不同。例如，J.Smith的DN可以是：
uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
uid=J.Smith@worldnet.att.net, dc=mis, dc=acme, dc=com
While we do not REQUIRE that the domain name part of the uid match the dc components of the directory distinguished name, we suggest that this be done where possible. At a minimum, if the most significant pieces of the DN and the uid are the same (i.e., "dc=acme, dc=com" and "acme.com") the likelihood, based on a knowledge of a user's e-mail address, of discovering an appropriate directory system to contact to find information about the user is greatly enhanced.
虽然我们不要求uid的域名部分与目录可分辨名称的dc组件匹配，但我们建议尽可能做到这一点。至少，如果DN和uid的最重要部分相同（即“dc=acme，dc=com”和“acme.com”），则基于对用户电子邮件地址的了解，发现适当的目录系统以联系以查找有关用户的信息的可能性大大提高。
The example above represents a situation where this suggestion isn't possible because some of the users in a population have mailbox identifiers that differ from the pattern of the rest of the users, e.g., most mailboxes are of the form local@acme.com, but a subpopulation have mailboxes from an ISP and therefore mailboxes of the form local@worldnet.att.net.
上面的示例表示这样一种情况，即由于人口中的某些用户的邮箱标识符与其他用户的模式不同，因此不可能有此建议，例如，大多数邮箱的形式为local@acme.com,但是，一个子群体拥有来自ISP的邮箱，因此具有以下形式的邮箱local@worldnet.att.net.
We envision the deployment of LDAP-based directory services on the Internet to take the form of loosely coupled LDAP servers. This coupling will occur at two levels.
我们设想在Internet上部署基于LDAP的目录服务，采用松散耦合的LDAP服务器的形式。这种耦合将在两个级别上发生。
Firstly, LDAP servers will be loosely connected into islands (i.e. a set of servers sharing a single DN namespace). The glue connecting the islands will be LDAP referral [12] information configured into the LDAP servers. An LDAP search directed to any server in such an island can be answered, if the information is not available to that server, by an LDAP referral to another, more appropriate server within the same island.
首先，LDAP服务器将松散地连接到孤岛（即，一组共享单个DN命名空间的服务器）。连接孤岛的粘合剂将是配置到LDAP服务器中的LDAP参考[12]信息。如果信息对该服务器不可用，则可以通过LDAP引用到同一个岛内的另一个更合适的服务器来回答指向该岛中任何服务器的LDAP搜索。
Secondly, various techniques will be used span LDAP islands. The concept that enables such techniques is the LDAP URL [13]. By combining a DNS host name and port (corresponding to one or more LDAP servers) with a DN, the LDAP URL provides unified high-level identification scheme (an LDAP URL namespace) for directory objects.
其次，将在LDAP岛上使用各种技术。支持这种技术的概念是LDAP URL[13]。通过将DNS主机名和端口（对应于一个或多个LDAP服务器）与DN相结合，LDAP URL为目录对象提供了统一的高级标识方案（LDAP URL命名空间）。
Because an LDAP referral is expressed as one or more LDAP URL, these two levels of coupling may not sharply distinguished in practice.
因为LDAP引用被表示为一个或多个LDAP URL，所以这两个耦合级别在实践中可能没有明显区别。
We do not envision the X.500 model of a single DIT (i.e. a single DN namespace) to be viable in an environment of competing service providers. This naming plan does not attempt to produce DNs to hide the possibility that a given real-world object may have independently managed directory objects with the same DN associated with it.
我们不认为单一DIT（即单一DN命名空间）的X.500模型在竞争服务提供商的环境中是可行的。此命名计划不会试图生成DNs，以隐藏给定现实世界对象可能具有独立管理的目录对象（与该对象关联的DN相同）的可能性。
The traditional directory schema(s) developed for the X.500 standard and its application to the Internet [4] require extension to be used with the naming plan developed here. The extensions described below attempt to reuse existing schema elements as much as possible. The directory objects for which extensions are required are: organization, organizational unit, and various classes of leaf objects. We describe the schema modifications below for organization, organizationalUnit and selected leaf classes.
为X.500标准开发的传统目录模式及其在互联网上的应用[4]需要扩展才能与此处开发的命名计划一起使用。下面描述的扩展试图尽可能地重用现有的模式元素。需要扩展的目录对象包括：组织、组织单位和各种类型的叶对象。我们在下面描述了organization、organizationalUnit和所选叶类的模式修改。
So as to continue to use existing structural object classes to the extent possible, we propose supplementing entries based on these classes with additional information from two new auxiliary object classes, dcObject and uidObject. They are specified using the notation in Section 4 of [14].
为了尽可能继续使用现有的结构对象类，我们建议使用来自两个新的辅助对象类dcObject和uidObject的附加信息来补充基于这些类的条目。它们是使用[14]第4节中的符号指定的。
The auxiliary object class dcObject is defined in "Using Domains in LDAP Distinguished Names" [1].
辅助对象类dcObject在“使用LDAP专有名称中的域”[1]中定义。
The auxiliary object class uidObject is defined as:
辅助对象类uidObject定义为：
( 1.3.6.1.1.3.1 NAME uidObject SUP top AUXILIARY MUST uid )
（1.3.6.1.1.3.1名称uidObject SUP top辅助uid）
The dc attribute is employed to construct the RDN of an organization object. This is enabled by adding the auxiliary class dcObject to the organization's objectClass attribute.
dc属性用于构造组织对象的RDN。这是通过将辅助类dcObject添加到组织的objectClass属性来启用的。
The dc attribute is employed to construct the RDN of an organizationalUnit object (which is subordinate in the DIT to either an organization or an organizationalUnit object). This is enabled by adding the auxiliary class dcObject to the organizational unit's objectClass attribute.
dc属性用于构造organizationalUnit对象（在DIT中从属于组织或organizationalUnit对象）的RDN。这是通过将辅助类dcObject添加到组织单位的objectClass属性来启用的。
No schema extensions are required for person objects if either the inetOrgPerson [15] (preferred) or the newPilotPerson object classes are used. The attribute uid is permissible in each class. For consistency, the uidObject could be added to person entry objectClass attributes to assist applications filtering on this object class attribute value. Use of other classes for person objects with RDN constructed with the uid attribute such as organizationalPerson requires the use of the uidObject class.
如果使用inetOrgPerson[15]（首选）或newPilotPerson对象类，则person对象不需要架构扩展。属性uid在每个类中都是允许的。为了保持一致性，可以将uidObject添加到person entry objectClass属性中，以帮助应用程序筛选此对象类属性值。对于RDN由uid属性构造的person对象，如organizationalPerson，使用其他类需要使用uidObject类。
It has been traditional in X.500 and LDAP directory services to employ the common name (cn) attribute in naming. While this naming plan doesn't require use of the cn attribute in naming, it should be stressed that it is a required attribute in any class derived from the person class and is still quite important. It will play a significant role in enabling searches to find user entries of interest.
在X.500和LDAP目录服务中，传统的做法是在命名中使用公共名称（cn）属性。虽然此命名计划不需要在命名中使用cn属性，但应该强调的是，它是从person类派生的任何类中的必需属性，仍然非常重要。它将在使搜索能够找到感兴趣的用户条目方面发挥重要作用。
The certification authority (CA) object class is an auxiliary class, meaning it is essentially a set of additional attributes for a base class such as organizationalRole, organization, organizationalUnit or person. Except in the case where the base structural class is inetOrgPerson, use of the uid attribute to construct the RDN of a CA
证书颁发机构（CA）对象类是一个辅助类，这意味着它本质上是基类（如organizationalRole、organizationalUnit或person）的一组附加属性。除非基本结构类是inetOrgPerson，否则使用uid属性来构造CA的RDN
will require the auxiliary class uidObject to permit the uid attribute to be used. In the cases where organizationalUnit or organization is the base class for a CA, use of the auxiliary class dcObject will permit the RDN of the CA to be a domain component.
将要求辅助类uidObject允许使用uid属性。在organizationalUnit或organization是CA的基类的情况下，使用辅助类dcObject将允许CA的RDN成为域组件。
Servers and server applications are typically represented, for want of anything better, by entries of the object class applicationProcess (or a class derived from it). Sometimes the class applicationEntity is used. In either case, the uid attribute should probably not be employed to construct the RDN of a server or server application object. The standard schema uses the attribute cn for such RDNs.
服务器和服务器应用程序通常通过对象类applicationProcess（或从中派生的类）的条目来表示，而不需要更好的东西。有时使用类applicationEntity。在任何一种情况下，都不应该使用uid属性来构造服务器或服务器应用程序对象的RDN。标准模式对此类RDN使用属性cn。
Suppose one wants to use this naming plan both in the construction of DNs for SSL server certificates and for their storage in a directory. It is customary for clients connecting via SSL to compare the server's domain name (e.g. from the URL used to contact the server) with the value of the cn attribute in the subject field (i.e. subject's DN) of the server's certificate. For this reason, it is common practice to set the cn attribute to the server's domain name.
假设有人希望在SSL服务器证书的DNs构造和它们在目录中的存储中都使用此命名计划。通过SSL连接的客户端通常会将服务器的域名（例如，从用于联系服务器的URL）与服务器证书的“主题”字段（即主题的DN）中的cn属性值进行比较。因此，通常将cn属性设置为服务器的域名。
The naming and schema to handle this situation is best explained by an example. Consider the server "host.acme.com". Following the algorithm in "Using Domains in LDAP Distinguished Names" [1], the DN dc=host, dc=acme, dc=com is constructed. To conform to the existing practices just described, the server's subject DN for the SSL server certificate should be cn=host.acme.com, dc=host, dc=acme, dc=com and the server's certificate should be stored in a directory entry with this name. This entry should use application process or application entity as its structural object class and strong authentication user as is auxiliary class.
处理这种情况的命名和模式最好通过一个例子来解释。考虑服务器“主机.ACME.com”。按照“在LDAP可分辨名称中使用域”[1]中的算法，构造DN dc=host，dc=acme，dc=com。为了符合刚才描述的现有实践，SSL服务器证书的服务器主题DN应为cn=host.acme.com、dc=host、dc=acme、dc=com，并且服务器的证书应存储在具有此名称的目录条目中。此条目应使用应用程序进程或应用程序实体作为其结构对象类，使用强身份验证用户作为辅助类。
For X.500 servers or LDAP servers following the X.500 model, our schema requires the definition of new name forms, structure rules, and DIT content rules. Structure rules and DIT content rules are locally defined, and do not involve a globally significant object identifier.
对于X.500服务器或遵循X.500模型的LDAP服务器，我们的模式需要定义新的名称表单、结构规则和DIT内容规则。结构规则和DIT内容规则是本地定义的，不涉及全局重要的对象标识符。
The following name forms are defined using the syntax of section 6.22 of [14] for the convenience of those using such servers.
为了方便使用此类服务器的用户，使用[14]第6.22节的语法定义了以下名称形式。
Note that since the structural object classes organization, organizationalUnit, locality and organizationalPerson do not permit inclusion of the dc attribute, an auxiliary object class such as dcObject [1] must be used for instances of these classes.)
请注意，由于结构对象类organization、organizationalUnit、Location和organizationalPerson不允许包含dc属性，因此这些类的实例必须使用辅助对象类，如dcObject[1]
The OIDs in this group are under the iso.org.dod.internet.directory.NameForm branch of the OID tree (1.3.6.1.1.2).
此组中的OID位于OID树（1.3.6.1.1.2）的iso.org.dod.internet.directory.NameForm分支下。
( 1.3.6.1.1.2.1 NAME domainNameForm OC domain MUST dc )
（1.3.6.1.1.2.1域名形式OC域必须dc）
The domainNameForm name form indicates that objects of structural object class domain have their RDN constructed from a value of the attribute dc.
domainNameForm名称表单表示结构对象类域的对象的RDN是由属性dc的值构造的。
( 1.3.6.1.1.2.2 NAME dcOrganizationNameForm OC organization MUST dc )
（1.3.6.1.1.2.2名称dc组织名称表格OC组织必须dc）
The dcOrganizationNameForm name form indicates that objects of structural object class organization have their RDN constructed from a value of the attribute dc.
dcOrganizationNameForm名称表单表示结构对象类组织的对象的RDN是根据属性dc的值构造的。
( 1.3.6.1.1.2.3 NAME dcOrganizationalUnitNameForm OC organizationalUnit MUST dc )
（1.3.6.1.1.2.3名称数据组织名称表OC organizationalUnit必须为dc）
The dcOrganizationalUnitNameForm name form indicates that objects of structural object class organizationalUnit have their RDN constructed from a value of the attribute dc.
dcOrganizationalUnitNameForm名称表单表示结构对象类organizationalUnit的对象的RDN由属性dc的值构造。
( 1.3.6.1.1.2.4 NAME dcLocalityNameForm OC locality MUST dc )
（1.3.6.1.1.2.4名称dcLocalityNameForm OC locality必须dc）
The dcLocalityNameForm name form indicates that objects of structural object class locality have their RDN constructed from a value of the attribute dc.
DcLocationNameForm名称表单表示结构化对象类局部性的对象的RDN由属性dc的值构造。
( 1.3.6.1.1.2.5 NAME uidOrganizationalPersonNameForm OC organizationalPerson MUST uid )
（1.3.6.1.1.2.5名称uid组织机构名称表格OC组织机构人员必须uid）
The uidOrganizationalPersonNameForm name form indicates that objects of structural object class organizationalPerson have their RDN constructed from a value of the attribute uid.
UIDOrOrganizationalPersonNameForm名称表单表示结构对象类organizationalPerson的对象的RDN是根据属性uid的值构造的。
Although access controls may be placed on portions of the DIT to deny browse access to unauthorized clients, it may be possible to infer directory names and DIT structure in such sensitive portions of the DIT from the results of DNS queries. Providing public visibility to some portions of the DIT may assist those make such inferences.
尽管可以对DIT的某些部分进行访问控制，以拒绝对未经授权的客户端进行浏览访问，但也可以从DNS查询的结果推断DIT的这些敏感部分中的目录名和DIT结构。向公众提供DIT某些部分的可见性可能有助于做出此类推断。
This plan has emerged in the course of a number of fruitful discussions, especially with David Chadwick, John Dale, Joe Gajewski, Mark Jackson, Ryan Moats, Tom Spencer and Chris Tzu.
这项计划是在一系列富有成效的讨论过程中提出的，特别是与戴维·查德威克、约翰·戴尔、乔·加耶夫斯基、马克·杰克逊、瑞安·莫茨、汤姆·斯宾塞和克里斯·齐的讨论。
[1] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri, "Using Domains in LDAP Distinguished Names", RFC 2247, January 1998.
[1] Kille，S.，Wahl，M.，Grimstad，A.，Huber，R.，和S.Sataluri，“使用LDAP专有名称中的域”，RFC 2247，1998年1月。
[2] X.500: The Directory -- Overview of Concepts, Models, and Service, CCITT Recommendation X.500, December, 1988.
[2] X.500：目录——概念、模型和服务概述，CCITT建议X.500，1988年12月。
[3] Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema", RFC 1274, November 1991.
[3] Barker，P.和S.Kille，“余弦和互联网X.500模式”，RFC 1274，1991年11月。
[4] The North American Directory Forum, "A Naming Scheme for c=US", RFC 1255, September 1991.
[4] 北美目录论坛，“c=US的命名方案”，RFC 1255，1991年9月。
[5] The North American Directory Forum, "NADF Standing Documents: A Brief Overview", RFC 1417, February 1993.
[5] 北美目录论坛，“新议程常设文件：简要概述”，RFC 1417，1993年2月。
[6] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995.
[6] Yeong，W.，Howes，T.，和S.Kille，“轻量级目录访问协议”，RFC17771995年3月。
[7] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[7] Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[8] Kille, S., "A String Representation of Distinguished Names", RFC 1779, March 1995.
[8] Kille，S.，“可分辨名称的字符串表示法”，RFC 1779，1995年3月。
[9] Wahl, M., Kille, S., and T. Howes, "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997.
[9] Wahl，M.，Kille，S.，和T.Howes，“轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示”，RFC 2253，1997年12月。
[10] Wahl, M., "A Summary of the Pilot X.500 Schema for use in LDAPv3", Work in Progress.
[10] Wahl，M.，“用于LDAPv3的试点X.500模式摘要”，正在进行的工作。
[11] Wahl, M., "A Summary of the X.500 User Schema for use with LDAPv3", RFC 2256, December 1997.
[11] Wahl，M.“与LDAPv3一起使用的X.500用户模式摘要”，RFC 2256，1997年12月。
[12] Howes, T., and M. Wahl, "Referrals and Knowledge References in LDAP Directories", Work in Progress.
[12] Howes，T.和M.Wahl，“LDAP目录中的引用和知识引用”，正在进行中。
[13] Howes, T., and M. Smith, "The LDAP URL Format", RFC 2255, December 1997.
[13] Howes，T.和M.Smith，“LDAP URL格式”，RFC2255，1997年12月。
[14] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[14] Wahl，M.，Coulbeck，A.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[15] Smith, M., "Definition of the inetOrgPerson Object Class", Work in Progress.
[15] Smith，M.，“inetOrgPerson对象类的定义”，正在进行中。
Al Grimstad AT&T Room 1C-429, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
美国新泽西州霍姆德尔克劳福德角路101号阿尔·格里姆斯塔德电话电报公司1C-429室，邮编：07733-3030
EMail: alg@att.com
EMail: alg@att.com
Rick Huber AT&T Room 1B-433, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Rick Huber美国新泽西州霍姆德尔克劳福德角路101号电话电报室1B-433 07733-3030
EMail: rvh@att.com
EMail: rvh@att.com
Sri Sataluri Lucent Technologies Room 4D-335, 101 Crawfords Corner Road Holmdel, NJ 07733-3030 USA
Sri Sataluri-Lucent Technologies美国新泽西州霍姆德尔克劳福德角路101号4D-335室，邮编：07733-3030
EMail: srs@lucent.com
EMail: srs@lucent.com
Mark Wahl Critical Angle Inc. 4815 W Braker Lane #502-385 Austin, TX 78759 USA
马克·沃尔临界角公司，美国德克萨斯州奥斯汀市布雷克巷西4815号，502-385号，邮编78759
EMail: M.Wahl@critical-angle.com
EMail: M.Wahl@critical-angle.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。