Network Working Group K. Zeilenga, Ed.
Request for Comments: 4514 OpenLDAP Foundation
Obsoletes: 2253 June 2006
Category: Standards Track
Network Working Group K. Zeilenga, Ed.
Request for Comments: 4514 OpenLDAP Foundation
Obsoletes: 2253 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
轻量级目录访问协议（LDAP）：可分辨名称的字符串表示
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The X.500 Directory uses distinguished names (DNs) as primary keys to entries in the directory. This document defines the string representation used in the Lightweight Directory Access Protocol (LDAP) to transfer distinguished names. The string representation is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.
X.500目录使用可分辨名称（DNs）作为目录项的主键。本文档定义了轻量级目录访问协议（LDAP）中用于传输可分辨名称的字符串表示形式。字符串表示法旨在提供常用可分辨名称的清晰表示，同时能够表示任何可分辨名称。
In X.500-based directory systems [X.500], including those accessed using the Lightweight Directory Access Protocol (LDAP) [RFC4510], distinguished names (DNs) are used to unambiguously refer to directory entries [X.501][RFC4512].
在基于X.500的目录系统[X.500]中，包括使用轻型目录访问协议（LDAP）[RFC4510]访问的目录系统，可分辨名称（DNs）用于明确地引用目录条目[X.501][RFC4512]。
The structure of a DN [X.501] is described in terms of ASN.1 [X.680]. In the X.500 Directory Access Protocol [X.511] (and other ITU-defined directory protocols), DNs are encoded using the Basic Encoding Rules (BER) [X.690]. In LDAP, DNs are represented in the string form described in this document.
DN[X.501]的结构在ASN.1[X.680]中描述。在X.500目录访问协议[X.511]（和其他ITU定义的目录协议）中，使用基本编码规则（BER）[X.690]对DNs进行编码。在LDAP中，DNs以本文档中描述的字符串形式表示。
It is important to have a common format to be able to unambiguously represent a distinguished name. The primary goal of this specification is ease of encoding and decoding. A secondary goal is to have names that are human readable. It is not expected that LDAP
重要的是要有一个通用的格式，以便能够明确地表示一个可分辨的名称。本规范的主要目标是易于编码和解码。第二个目标是使名称具有可读性。不希望LDAP
implementations with a human user interface would display these strings directly to the user, but that they would most likely be performing translations (such as expressing attribute type names in the local national language).
具有人类用户界面的实现将直接向用户显示这些字符串，但它们很可能执行翻译（例如用当地国家语言表示属性类型名称）。
This document defines the string representation of Distinguished Names used in LDAP [RFC4511][RFC4517]. Section 2 details the RECOMMENDED algorithm for converting a DN from its ASN.1 structured representation to a string. Section 3 details how to convert a DN from a string to an ASN.1 structured representation.
本文档定义了LDAP[RFC4511][RFC4517]中使用的可分辨名称的字符串表示形式。第2节详细介绍了将DN从ASN.1结构化表示转换为字符串的推荐算法。第3节详细介绍了如何将DN从字符串转换为ASN.1结构化表示。
While other documents may define other algorithms for converting a DN from its ASN.1 structured representation to a string, all algorithms MUST produce strings that adhere to the requirements of Section 3.
虽然其他文档可能会定义将DN从ASN.1结构化表示转换为字符串的其他算法，但所有算法必须生成符合第3节要求的字符串。
This document does not define a canonical string representation for DNs. Comparison of DNs for equality is to be performed in accordance with the distinguishedNameMatch matching rule [RFC4517].
本文档未定义DNs的规范字符串表示形式。根据DifferentiedNameMatch匹配规则[RFC4517]对DNs进行相等性比较。
This document is a integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety. This document obsoletes RFC 2253. Changes since RFC 2253 are summarized in Appendix B.
本文档是LDAP技术规范[RFC4510]不可分割的一部分，该规范完全废除了先前定义的LDAP技术规范RFC 3377。本文件废除了RFC 2253。附录B总结了自RFC 2253以来的变化。
This specification assumes familiarity with X.500 [X.500] and the concept of Distinguished Name [X.501][RFC4512].
本规范假设您熟悉X.500[X.500]和可分辨名称[X.501][RFC4512]的概念。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14[RFC2119]中所述进行解释。
Character names in this document use the notation for code points and names from the Unicode Standard [Unicode]. For example, the letter "a" may be represented as either <U+0061> or <LATIN SMALL LETTER A>.
本文档中的字符名称使用Unicode标准[Unicode]中的代码点和名称表示法。例如，字母“a”可以表示为<U+0061>或<拉丁文小写字母a>。
Note: a glossary of terms used in Unicode can be found in [Glossary]. Information on the Unicode character encoding model can be found in [CharModel].
注：Unicode中使用的术语表可在[glossary]中找到。有关Unicode字符编码模型的信息可在[CharModel]中找到。
X.501 [X.501] defines the ASN.1 [X.680] structure of distinguished name. The following is a variant provided for discussion purposes.
X.501[X.501]定义了可分辨名称的ASN.1[X.680]结构。以下是为讨论目的提供的变体。
DistinguishedName ::= RDNSequence
DistinguishedName ::= RDNSequence
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RDNSequence ::= SEQUENCE OF RelativeDistinguishedName
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
AttributeTypeAndValue
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
AttributeTypeAndValue ::= SEQUENCE {
type AttributeType,
value AttributeValue }
This section defines the RECOMMENDED algorithm for converting a distinguished name from an ASN.1-structured representation to a UTF-8 [RFC3629] encoded Unicode [Unicode] character string representation. Other documents may describe other algorithms for converting a distinguished name to a string, but only strings that conform to the grammar defined in Section 3 SHALL be produced by LDAP implementations.
本节定义了将可分辨名称从ASN.1结构化表示转换为UTF-8[RFC3629]编码的Unicode[Unicode]字符串表示的推荐算法。其他文档可能描述将可分辨名称转换为字符串的其他算法，但LDAP实现只能生成符合第3节中定义的语法的字符串。
If the RDNSequence is an empty sequence, the result is the empty or zero-length string.
如果RDNSequence是空序列，则结果是空字符串或零长度字符串。
Otherwise, the output consists of the string encodings of each RelativeDistinguishedName in the RDNSequence (according to Section 2.2), starting with the last element of the sequence and moving backwards toward the first.
否则，输出由RDN序列中每个RelativeDistinguishedName的字符串编码组成（根据第2.2节），从序列的最后一个元素开始，向后移动到第一个元素。
The encodings of adjoining RelativeDistinguishedNames are separated by a comma (',' U+002C) character.
相邻RelativeDistinguishedNames的编码由逗号（'，'U+002C）字符分隔。
When converting from an ASN.1 RelativeDistinguishedName to a string, the output consists of the string encodings of each AttributeTypeAndValue (according to Section 2.3), in any order.
当从ASN.1 RelativeDistinguishedName转换为字符串时，输出由每个AttributeTypeAndValue（根据第2.3节）的字符串编码以任意顺序组成。
Where there is a multi-valued RDN, the outputs from adjoining AttributeTypeAndValues are separated by a plus sign ('+' U+002B) character.
如果存在多值RDN，则相邻AttributeTypeAndValue的输出由加号（“+”U+002B）字符分隔。
The AttributeTypeAndValue is encoded as the string representation of the AttributeType, followed by an equals sign ('=' U+003D) character, followed by the string representation of the AttributeValue. The encoding of the AttributeValue is given in Section 2.4.
AttributeTypeAndValue编码为AttributeType的字符串表示形式，后跟等号（'='U+003D）字符，后跟AttributeValue的字符串表示形式。AttributeValue的编码在第2.4节中给出。
If the AttributeType is defined to have a short name (descriptor) [RFC4512] and that short name is known to be registered [REGISTRY] [RFC4520] as identifying the AttributeType, that short name, a <descr>, is used. Otherwise the AttributeType is encoded as the dotted-decimal encoding, a <numericoid>, of its OBJECT IDENTIFIER. The <descr> and <numericoid> are defined in [RFC4512].
如果将AttributeType定义为具有短名称（描述符）[RFC4512]，并且已知该短名称注册为[REGISTRY][RFC4520]以标识AttributeType，则使用该短名称a<descr>。否则，AttributeType将被编码为其对象标识符的点十进制编码，即<numericoid>。[RFC4512]中定义了<descr>和<numericoid>。
Implementations are not expected to dynamically update their knowledge of registered short names. However, implementations SHOULD provide a mechanism to allow their knowledge of registered short names to be updated.
实现不需要动态更新它们对已注册短名称的了解。但是，实现应该提供一种机制，允许更新他们对已注册短名称的了解。
If the AttributeType is of the dotted-decimal form, the AttributeValue is represented by an number sign ('#' U+0023) character followed by the hexadecimal encoding of each of the octets of the BER encoding of the X.500 AttributeValue. This form is also used when the syntax of the AttributeValue does not have an LDAP-specific ([RFC4517], Section 3.1) string encoding defined for it, or the LDAP-specific string encoding is not restricted to UTF-8-encoded Unicode characters. This form may also be used in other cases, such as when a reversible string representation is desired (see Section 5.2).
如果AttributeType为点十进制形式，则AttributeValue由数字符号（“#”U+0023）字符表示，后跟X.500 AttributeValue的BER编码的每个八位字节的十六进制编码。当AttributeValue的语法没有为其定义特定于LDAP的（[RFC4517]，第3.1节）字符串编码，或者特定于LDAP的字符串编码不限于UTF-8编码的Unicode字符时，也可以使用此表单。这种形式也可用于其他情况，如需要可逆字符串表示时（见第5.2节）。
Otherwise, if the AttributeValue is of a syntax that has a LDAP-specific string encoding, the value is converted first to a UTF-8- encoded Unicode string according to its syntax specification (see [RFC4517], Section 3.3, for examples). If that UTF-8-encoded Unicode string does not have any of the following characters that need escaping, then that string can be used as the string representation of the value.
否则，如果AttributeValue的语法具有LDAP特定的字符串编码，则该值将首先根据其语法规范转换为UTF-8编码的Unicode字符串（例如，请参见[RFC4517]，第3.3节）。如果UTF-8编码的Unicode字符串没有以下任何需要转义的字符，则该字符串可以用作值的字符串表示形式。
- a space (' ' U+0020) or number sign ('#' U+0023) occurring at the beginning of the string;
- 出现在字符串开头的空格（''U+0020）或数字符号（'#'U+0023）；
- a space (' ' U+0020) character occurring at the end of the string;
- 出现在字符串末尾的空格（“”U+0020）字符；
- one of the characters '"', '+', ',', ';', '<', '>', or '\' (U+0022, U+002B, U+002C, U+003B, U+003C, U+003E, or U+005C, respectively);
- 其中一个字符为“'”、“+”、“、”、“；”、“<”、“>”或“\”（分别为U+0022、U+002B、U+002C、U+003B、U+003C、U+003E或U+005C）；
- the null (U+0000) character.
- 空（U+0000）字符。
Other characters may be escaped.
其他字符可能会被转义。
Each octet of the character to be escaped is replaced by a backslash and two hex digits, which form a single octet in the code of the character. Alternatively, if and only if the character to be escaped is one of
要转义的字符的每个八位字节都由一个反斜杠和两个十六进制数字替换，它们在字符代码中形成一个八位字节。或者，当且仅当要转义的字符是
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
U+003C, U+003D, U+003E, U+005C, respectively)
' ', '"', '#', '+', ',', ';', '<', '=', '>', or '\'
(U+0020, U+0022, U+0023, U+002B, U+002C, U+003B,
U+003C, U+003D, U+003E, U+005C, respectively)
it can be prefixed by a backslash ('\' U+005C).
它的前缀可以是反斜杠（“\”U+005C）。
Examples of the escaping mechanism are shown in Section 4.
逃逸机构的示例如第4节所示。
The string representation of Distinguished Names is restricted to UTF-8 [RFC3629] encoded Unicode [Unicode] characters. The structure of this string representation is specified using the following Augmented BNF [RFC4234] grammar:
可分辨名称的字符串表示形式仅限于UTF-8[RFC3629]编码的Unicode[Unicode]字符。此字符串表示的结构是使用以下扩充的BNF[RFC4234]语法指定的：
distinguishedName = [ relativeDistinguishedName
*( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
*( PLUS attributeTypeAndValue )
attributeTypeAndValue = attributeType EQUALS attributeValue
attributeType = descr / numericoid
attributeValue = string / hexstring
distinguishedName = [ relativeDistinguishedName
*( COMMA relativeDistinguishedName ) ]
relativeDistinguishedName = attributeTypeAndValue
*( PLUS attributeTypeAndValue )
attributeTypeAndValue = attributeType EQUALS attributeValue
attributeType = descr / numericoid
attributeValue = string / hexstring
; The following characters are to be escaped when they appear
; in the value to be encoded: ESC, one of <escaped>, leading
; SHARP or SPACE, trailing SPACE, and NULL.
string = [ ( leadchar / pair ) [ *( stringchar / pair )
( trailchar / pair ) ] ]
; The following characters are to be escaped when they appear
; in the value to be encoded: ESC, one of <escaped>, leading
; SHARP or SPACE, trailing SPACE, and NULL.
string = [ ( leadchar / pair ) [ *( stringchar / pair )
( trailchar / pair ) ] ]
leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
leadchar = LUTF1 / UTFMB
LUTF1 = %x01-1F / %x21 / %x24-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
trailchar = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
trailchar = TUTF1 / UTFMB
TUTF1 = %x01-1F / %x21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
%x3D/%x3F-5B/%x5D-7F
stringchar = SUTF1 / UTFMB
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
stringchar = SUTF1 / UTFMB
SUTF1 = %x01-21 / %x23-2A / %x2D-3A /
%x3D / %x3F-5B / %x5D-7F
pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
hexstring = SHARP 1*hexpair
hexpair = HEX HEX
pair = ESC ( ESC / special / hexpair )
special = escaped / SPACE / SHARP / EQUALS
escaped = DQUOTE / PLUS / COMMA / SEMI / LANGLE / RANGLE
hexstring = SHARP 1*hexpair
hexpair = HEX HEX
where the productions <descr>, <numericoid>, <COMMA>, <DQUOTE>, <EQUALS>, <ESC>, <HEX>, <LANGLE>, <NULL>, <PLUS>, <RANGLE>, <SEMI>, <SPACE>, <SHARP>, and <UTFMB> are defined in [RFC4512].
其中，[RFC4512]中定义了产品<descr>、<numericoid>、<COMMA>、<DQUOTE>、<EQUALS>、<HEX>、<LANGLE>、<NULL>、<PLUS>、<RANGLE>、<SEMI>、<SPACE>、<SHARP>和<UTFMB>。
Each <attributeType>, either a <descr> or a <numericoid>, refers to an attribute type of an attribute value assertion (AVA). The <attributeType> is followed by an <EQUALS> and an <attributeValue>. The <attributeValue> is either in <string> or <hexstring> form.
每个<attributeType>（一个<descr>或一个<numericoid>）都引用属性值断言（AVA）的属性类型。<attributeType>后面跟着一个<EQUALS>和一个<attributeValue>。<attributeValue>的格式为<string>或<hexstring>。
If in <string> form, a LDAP string representation asserted value can be obtained by replacing (left to right, non-recursively) each <pair> appearing in the <string> as follows:
如果是<string>形式，则可以通过替换<string>中出现的每个<pair>来获得LDAP字符串表示断言值，如下所示：
replace <ESC><ESC> with <ESC>;
replace <ESC><special> with <special>;
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
replace <ESC><ESC> with <ESC>;
replace <ESC><special> with <special>;
replace <ESC><hexpair> with the octet indicated by the <hexpair>.
If in <hexstring> form, a BER representation can be obtained from converting each <hexpair> of the <hexstring> to the octet indicated by the <hexpair>.
如果采用<hextring>形式，则可以通过将<hextring>的每个<hextpair>转换为<hextpair>指示的八位字节来获得BER表示。
There is one or more attribute value assertions, separated by <PLUS>, for a relative distinguished name.
对于相对可分辨名称，有一个或多个属性值断言，以<PLUS>分隔。
There is zero or more relative distinguished names, separated by <COMMA>, for a distinguished name.
一个可分辨名称有零个或多个相对可分辨名称，以“<逗号>”分隔。
Implementations MUST recognize AttributeType name strings (descriptors) listed in the following table, but MAY recognize other name strings.
实现必须识别下表中列出的AttributeType名称字符串（描述符），但可以识别其他名称字符串。
String X.500 AttributeType
------ --------------------------------------------
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
String X.500 AttributeType
------ --------------------------------------------
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
These attribute types are described in [RFC4519].
[RFC4519]中描述了这些属性类型。
Implementations MAY recognize other DN string representations. However, as there is no requirement that alternative DN string representations be recognized (and, if so, how), implementations SHOULD only generate DN strings in accordance with Section 2 of this document.
实现可以识别其他DN字符串表示形式。但是，由于不要求识别替代的DN字符串表示（以及，如果是，如何识别），实现应仅根据本文档第2节生成DN字符串。
This notation is designed to be convenient for common forms of name. This section gives a few examples of distinguished names written using this notation. First is a name containing three relative distinguished names (RDNs):
这种符号的设计是为了方便通用的名称形式。本节给出了几个使用此符号编写的可分辨名称的示例。第一个是包含三个相对可分辨名称（RDN）的名称：
UID=jsmith,DC=example,DC=net
UID=jsmith,DC=example,DC=net
Here is an example of a name containing three RDNs, in which the first RDN is multi-valued:
以下是包含三个RDN的名称示例，其中第一个RDN是多值的：
OU=Sales+CN=J. Smith,DC=example,DC=net
OU=Sales+CN=J. Smith,DC=example,DC=net
This example shows the method of escaping of a special characters appearing in a common name:
此示例显示了转义公用名称中出现的特殊字符的方法：
CN=James \"Jim\" Smith\, III,DC=example,DC=net
CN=James \"Jim\" Smith\, III,DC=example,DC=net
The following shows the method for encoding a value that contains a carriage return character:
下面显示了对包含回车符的值进行编码的方法：
CN=Before\0dAfter,DC=example,DC=net
CN=Before\0dAfter,DC=example,DC=net
In this RDN example, the type in the RDN is unrecognized, and the value is the BER encoding of an OCTET STRING containing two octets, 0x48 and 0x69.
在这个RDN示例中，RDN中的类型无法识别，该值是包含两个八位字节0x48和0x69的八位字节字符串的BER编码。
1.3.6.1.4.1.1466.0=#04024869
1.3.6.1.4.1.1466.0=#04024869
Finally, this example shows an RDN whose commonName value consists of 5 letters:
最后，此示例显示了一个RDN，其commonName值由5个字母组成：
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
Unicode Character Code UTF-8 Escaped
------------------------------- ------ ------ --------
LATIN CAPITAL LETTER L U+004C 0x4C L
LATIN SMALL LETTER U U+0075 0x75 u
LATIN SMALL LETTER C WITH CARON U+010D 0xC48D \C4\8D
LATIN SMALL LETTER I U+0069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U+0107 0xC487 \C4\87
This could be encoded in printable ASCII [ASCII] (useful for debugging purposes) as:
这可以用可打印的ASCII[ASCII]（用于调试目的）进行编码，如下所示：
CN=Lu\C4\8Di\C4\87
CN=Lu\C4\8Di\C4\87
The following security considerations are specific to the handling of distinguished names. LDAP security considerations are discussed in [RFC4511] and other documents comprising the LDAP Technical Specification [RFC4510].
以下安全注意事项特定于可分辨名称的处理。LDAP安全注意事项在[RFC4511]和包含LDAP技术规范[RFC4510]的其他文档中进行了讨论。
Distinguished Names typically consist of descriptive information about the entries they name, which can be people, organizations, devices, or other real-world objects. This frequently includes some of the following kinds of information:
可分辨名称通常包含有关其命名的条目的描述性信息，这些条目可以是人员、组织、设备或其他真实对象。这通常包括以下几种信息：
- the common name of the object (i.e., a person's full name) - an email or TCP/IP address - its physical location (country, locality, city, street address) - organizational attributes (such as department name or affiliation)
- 对象的通用名称（即某人的全名）-电子邮件或TCP/IP地址-其物理位置（国家、地区、城市、街道地址）-组织属性（如部门名称或隶属关系）
In some cases, such information can be considered sensitive. In many countries, privacy laws exist that prohibit disclosure of certain kinds of descriptive information (e.g., email addresses). Hence, server implementers are encouraged to support Directory Information Tree (DIT) structural rules and name forms [RFC4512], as these provide a mechanism for administrators to select appropriate naming attributes for entries. Administrators are encouraged to use mechanisms, access controls, and other administrative controls that may be available to restrict use of attributes containing sensitive information in naming of entries. Additionally, use of
在某些情况下，此类信息可能被视为敏感信息。在许多国家，隐私法禁止披露某些类型的描述性信息（如电子邮件地址）。因此，鼓励服务器实现人员支持目录信息树（DIT）结构规则和名称表单[RFC4512]，因为它们为管理员提供了为条目选择适当命名属性的机制。鼓励管理员使用机制、访问控制和其他管理控制，以限制在条目命名中使用包含敏感信息的属性。此外，使用
authentication and data security services in LDAP [RFC4513][RFC4511] should be considered.
应考虑LDAP[RFC4513][RFC4511]中的身份验证和数据安全服务。
The transformations of an AttributeValue value from its X.501 form to an LDAP string representation are not always reversible back to the same BER (Basic Encoding Rules) or DER (Distinguished Encoding Rules) form. An example of a situation that requires the DER form of a distinguished name is the verification of an X.509 certificate.
AttributeValue值从其X.501形式到LDAP字符串表示形式的转换并不总是可逆地返回到相同的BER（基本编码规则）或DER（区分编码规则）形式。验证X.509证书是需要可分辨名称的DER格式的一个示例。
For example, a distinguished name consisting of one RDN with one AVA, in which the type is commonName and the value is of the TeletexString choice with the letters 'Sam', would be represented in LDAP as the string <CN=Sam>. Another distinguished name in which the value is still 'Sam', but is of the PrintableString choice, would have the same representation <CN=Sam>.
例如，一个由一个RDN和一个AVA组成的可分辨名称（其中类型为commonName，值为Teletex字符串选项，字母为“Sam”）将在LDAP中表示为字符串<CN=Sam>。另一个可分辨名称的值仍然是'Sam'，但为可打印字符串选择，其表示形式将相同<CN=Sam>。
Applications that require the reconstruction of the DER form of the value SHOULD NOT use the string representation of attribute syntaxes when converting a distinguished name to the LDAP format. Instead, they SHOULD use the hexadecimal form prefixed by the number sign ('#' U+0023) as described in the first paragraph of Section 2.4.
在将可分辨名称转换为LDAP格式时，需要重构值的顺序形式的应用程序不应使用属性语法的字符串表示。相反，他们应该使用十六进制形式，前缀是数字符号（“#”U+0023），如第2.4节第一段所述。
This document is an update to RFC 2253, by Mark Wahl, Tim Howes, and Steve Kille. RFC 2253 was a product of the IETF ASID Working Group.
本文档是由Mark Wahl、Tim Howes和Steve Kille对RFC 2253的更新。RFC2253是IETF ASID工作组的产品。
This document is a product of the IETF LDAPBIS Working Group.
本文件是IETF LDAPBIS工作组的成果。
[REGISTRY] IANA, Object Identifier Descriptors Registry, <http://www.iana.org/assignments/ldap-parameters>.
[注册表]IANA，对象标识符描述符注册表<http://www.iana.org/assignments/ldap-parameters>.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0" is defined by "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201- 61633-5), as amended by the "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[Unicode]Unicode联盟“Unicode标准，版本3.2.0”由“Unicode标准，版本3.0”（雷丁，马萨诸塞州，Addison-Wesley，2000.ISBN 0-201-61633-5）定义，并由“Unicode标准附录27:Unicode 3.1”修订(http://www.unicode.org/reports/tr27/)根据“Unicode标准附录28:Unicode 3.2”(http://www.unicode.org/reports/tr28/).
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Models," X.501(1993) (also ISO/IEC 9594- 2:1994).
[X.501]国际电信联盟-电信标准化部门，“目录——模型”，X.501（1993）（也指ISO/IEC 9594-2:1994）。
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(1997) (also ISO/IEC 8824-1:1998).
[X.680]国际电信联盟-电信标准化部门，“抽象语法符号1（ASN.1）-基本符号规范”，X.680（1997）（也称ISO/IEC 8824-1:1998）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，Ed.“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511]Sermersheim，J.，Ed.，“轻量级目录访问协议（LDAP）：协议”，RFC4511，2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，“轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[RFC4513]Harrison，R.，Ed.“轻量级目录访问协议（LDAP）：身份验证方法和安全机制”，RFC4513，2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，Ed.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，2006年6月。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519]Sciberras，A.，Ed.，“轻量级目录访问协议（LDAP）：用户应用程序模式”，RFC4519，2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 4520，2006年6月。
[ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986.
[ASCII]编码字符集——信息交换用7位美国标准代码，ANSI X3.4-1986。
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report #17, Character Encoding Model", UTR17, <http://www.unicode.org/unicode/reports/tr17/>, August 2000.
[CharModel]Whistler，K.和M.Davis，“Unicode技术报告#17，字符编码模型”，UTR17<http://www.unicode.org/unicode/reports/tr17/>，2000年8月。
[Glossary] The Unicode Consortium, "Unicode Glossary", <http://www.unicode.org/glossary/>.
[词汇表]Unicode联盟，“Unicode词汇表”<http://www.unicode.org/glossary/>.
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory -- Overview of concepts, models and services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国际电信联盟-电信标准化部门，“目录——概念、模型和服务概述”，X.500（1993）（也指ISO/IEC 9594-1:1994）。
[X.511] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Abstract Service Definition", X.511(1993) (also ISO/IEC 9594-3:1993).
[X.511]国际电信联盟-电信标准化部门，“目录：抽象服务定义”，X.511（1993）（也称ISO/IEC 9594-3:1993）。
[X.690] International Telecommunication Union - Telecommunication Standardization Sector, "Specification of ASN.1 encoding rules: Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER)", X.690(1997) (also ISO/IEC 8825-1:1998).
[X.690]国际电信联盟-电信标准化部门，“ASN.1编码规则规范：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）”，X.690（1997）（另见ISO/IEC 8825-1:1998）。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849]Good，G.，“LDAP数据交换格式（LDIF）-技术规范”，RFC 28492000年6月。
This appendix is provided for informational purposes only; it is not a normative part of this specification.
本附录仅供参考；它不是本规范的规范性部分。
The string representation described in this document is not intended to be presented to humans without translation. However, at times it may be desirable to present non-translated DN strings to users. This section discusses presentation issues associated with non-translated DN strings. Issues with presentation of translated DN strings are not discussed in this appendix. Transcoding issues are also not discussed in this appendix.
本文档中描述的字符串表示法不打算在没有翻译的情况下呈现给人类。然而，有时可能希望向用户呈现未翻译的DN字符串。本节讨论与未翻译的DN字符串相关的表示问题。本附录不讨论翻译后的DN字符串的表示问题。本附录中也未讨论代码转换问题。
This appendix provides guidance for applications presenting DN strings to users. This section is not comprehensive; it does not discuss all presentation issues that implementers may face.
本附录为向用户呈现DN字符串的应用程序提供了指南。这一部分不全面；它并没有讨论实现者可能面临的所有表示问题。
Not all user interfaces are capable of displaying the full set of Unicode characters. Some Unicode characters are not displayable.
并非所有用户界面都能够显示完整的Unicode字符集。某些Unicode字符不可显示。
It is recommended that human interfaces use the optional hex pair escaping mechanism (Section 2.3) to produce a string representation suitable for display to the user. For example, an application can generate a DN string for display that escapes all non-printable characters appearing in the AttributeValue's string representation (as demonstrated in the final example of Section 4).
建议人机界面使用可选的十六进制对转义机制（第2.3节）生成适合向用户显示的字符串表示。例如，应用程序可以生成用于显示的DN字符串，该字符串转义AttributeValue的字符串表示中出现的所有不可打印字符（如第4节的最后一个示例所示）。
When a DN string is displayed in free-form text, it is often necessary to distinguish the DN string from surrounding text. While this is often done with whitespace (as demonstrated in Section 4), it is noted that DN strings may end with whitespace. Careful readers of Section 3 will note that the characters '<' (U+003C) and '>' (U+003E) may only appear in the DN string if escaped. These characters are intended to be used in free-form text to distinguish a DN string from surrounding text. For example, <CN=Sam\ > distinguishes the string representation of the DN composed of one RDN consisting of the AVA (the commonName (CN) value 'Sam ') from the surrounding text. It should be noted to the user that the wrapping '<' and '>' characters are not part of the DN string.
当DN字符串以自由格式文本显示时，通常需要将DN字符串与周围文本区分开来。虽然这通常是用空格来完成的（如第4节所示），但需要注意的是，DN字符串可能以空格结尾。仔细阅读第3节的读者会注意到，字符“<”（U+003C）和“>”（U+003E）只有在转义后才会出现在DN字符串中。这些字符用于自由格式文本中，以区分DN字符串和周围文本。例如，<CN=Sam\>将由一个RDN组成的DN的字符串表示形式与周围的文本区分开来，该RDN由AVA（commonName（CN）值“Sam”）组成。用户应注意，换行“<”和“>”字符不是DN字符串的一部分。
DN strings can be quite long. It is often desirable to line-wrap overly long DN strings in presentations. Line wrapping should be done by inserting whitespace after the RDN separator character or, if necessary, after the AVA separator character. It should be noted to the user that the inserted whitespace is not part of the DN string and is to be removed before use in LDAP. For example, the following DN string is long:
DN字符串可能相当长。在演示文稿中，通常需要将过长的DN字符串换行。换行应通过在RDN分隔符后插入空格来完成，如有必要，可在AVA分隔符后插入空格。用户应该注意，插入的空格不是DN字符串的一部分，在LDAP中使用之前要删除。例如，以下DN字符串很长：
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
So it has been line-wrapped for readability. The extra whitespace is to be removed before the DN string is used in LDAP.
因此，为了可读性，它被行包装。在LDAP中使用DN字符串之前，将删除额外的空白。
Inserting whitespace is not advised because it may not be obvious to the user which whitespace is part of the DN string and which whitespace was added for readability.
不建议插入空格，因为对于用户来说，哪些空格是DN字符串的一部分，哪些空格是为了可读性而添加的，这可能并不明显。
Another alternative is to use the LDAP Data Interchange Format (LDIF) [RFC2849]. For example:
另一种选择是使用LDAP数据交换格式（LDIF）[RFC2849]。例如：
# This entry has a long DN...
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
CN: Kurt D. Zeilenga
SN: Zeilenga
objectClass: person
# This entry has a long DN...
dn: CN=Kurt D. Zeilenga,OU=Engineering,L=Redwood Shores,
O=OpenLDAP Foundation,ST=California,C=US
CN: Kurt D. Zeilenga
SN: Zeilenga
objectClass: person
This appendix is provided for informational purposes only, it is not a normative part of this specification.
本附录仅供参考，不是本规范的规范性部分。
The following substantive changes were made to RFC 2253:
对RFC 2253进行了以下实质性更改：
- Removed IESG Note. The IESG Note has been addressed. - Replaced all references to ISO 10646-1 with [Unicode]. - Clarified (in Section 1) that this document does not define a canonical string representation. - Clarified that Section 2 describes the RECOMMENDED encoding algorithm and that alternative algorithms are allowed. Some encoding options described in RFC 2253 are now treated as alternative algorithms in this specification. - Revised specification (in Section 2) to allow short names of any registered attribute type to appear in string representations of DNs instead of being restricted to a "published table". Removed "as an example" language. Added statement (in Section 3) allowing recognition of additional names but require recognition of those names in the published table. The table now appears in Section 3. - Removed specification of additional requirements for LDAPv2 implementations which also support LDAPv3 (RFC 2253, Section 4) as LDAPv2 is now Historic. - Allowed recognition of alternative string representations. - Updated Section 2.4 to allow hex pair escaping of all characters and clarified escaping for when multiple octet UTF-8 encodings
- 删除IESG注释。IESG说明已被处理。-将对ISO 10646-1的所有引用替换为[Unicode]。-澄清（在第1节中）本文档未定义规范字符串表示形式。-阐明了第2节描述了推荐的编码算法，以及允许使用替代算法。RFC 2253中描述的一些编码选项现在被视为本规范中的替代算法。-修订了规范（第2节），允许任何注册属性类型的短名称出现在DNs的字符串表示中，而不限于“已发布的表”。删除“作为示例”语言。添加的语句（第3节）允许识别其他名称，但要求识别已发布表中的这些名称。该表现在出现在第3节中。-删除了还支持LDAPv3的LDAPv2实施的附加要求规范（RFC 2253，第4节），因为LDAPv2现已成为历史。-允许识别备选字符串表示形式。-更新了第2.4节，允许所有字符的十六进制对转义，并澄清了多个八进制UTF-8编码时的转义
are present. Indicated that null (U+0000) character is to be escaped. Indicated that equals sign ('=' U+003D) character may be escaped as '\='. - Rewrote Section 3 to use ABNF as defined in RFC 4234. - Updated the Section 3 ABNF. Changes include: + allowed AttributeType short names of length 1 (e.g., 'L'), + used more restrictive <oid> production in AttributeTypes, + did not require escaping of equals sign ('=' U+003D) characters, + did not require escaping of non-leading number sign ('#' U+0023) characters, + allowed space (' ' U+0020) to be escaped as '\ ', + required hex escaping of null (U+0000) characters, and + removed LDAPv2-only constructs. - Updated Section 3 to describe how to parse elements of the grammar. - Rewrote examples. - Added reference to documentations containing general LDAP security considerations. - Added discussion of presentation issues (Appendix A). - Added this appendix.
我们在场。指示将转义空（U+0000）字符。指示等号（'='U+003D）字符可以转义为'\='重写第3节，使用RFC 4234中定义的ABNF。-更新了第3节ABNF。更改包括：+允许的AttributeType长度为1的短名称（例如，“L”），+在AttributeType中使用了限制性更强的<oid>结果，+不要求转义等号（'='U+003D）字符，+不要求转义非前导数字符号（'.'U+0023）字符，+允许将空格（'U+0020）转义为'\'，+所需的null（U+0000）字符的十六进制转义，以及+仅删除了LDAPv2构造。-更新了第3节，描述了如何解析语法元素重写例子添加了对包含一般LDAP安全注意事项的文档的引用。-增加了对演示问题的讨论（附录A）。-增加了这个附录。
In addition, numerous editorial changes were made.
此外，还进行了许多编辑性修改。
Editor's Address
编辑地址
Kurt D. Zeilenga OpenLDAP Foundation
库尔特D.Zeeliga OpenLDAP基金会
EMail: Kurt@OpenLDAP.org
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。