Network Working Group M. Wahl
Request for Comments: 2253 Critical Angle Inc.
Obsoletes: 1779 S. Kille
Category: Standards Track Isode Ltd.
T. Howes
Netscape Communications Corp.
December 1997
Network Working Group M. Wahl
Request for Comments: 2253 Critical Angle Inc.
Obsoletes: 1779 S. Kille
Category: Standards Track Isode Ltd.
T. Howes
Netscape Communications Corp.
December 1997
Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names
轻量级目录访问协议（v3）：可分辨名称的UTF-8字符串表示
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 (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
IESG Note
IESG注释
This document describes a directory access protocol that provides both read and update access. Update access requires secure authentication, but this document does not mandate implementation of any satisfactory authentication mechanisms.
本文档描述了一个目录访问协议，该协议提供读取和更新访问。更新访问需要安全身份验证，但本文档并不要求实现任何令人满意的身份验证机制。
In accordance with RFC 2026, section 4.4.1, this specification is being approved by IESG as a Proposed Standard despite this limitation, for the following reasons:
根据RFC 2026第4.4.1节，IESG批准本规范作为拟定标准，尽管存在此限制，原因如下：
a. to encourage implementation and interoperability testing of these protocols (with or without update access) before they are deployed, and
a. 鼓励在部署这些协议之前实施和互操作性测试（有或没有更新访问），以及
b. to encourage deployment and use of these protocols in read-only applications. (e.g. applications where LDAPv3 is used as a query language for directories which are updated by some secure mechanism other than LDAP), and
b. 鼓励在只读应用程序中部署和使用这些协议。（例如，使用LDAPv3作为目录查询语言的应用程序，这些目录由LDAP以外的安全机制更新），以及
c. to avoid delaying the advancement and deployment of other Internet standards-track protocols which require the ability to query, but not update, LDAPv3 directory servers.
c. 为避免延迟其他Internet标准的推进和部署，跟踪协议需要能够查询但不更新LDAPv3目录服务器。
Readers are hereby warned that until mandatory authentication mechanisms are standardized, clients and servers written according to this specification which make use of update functionality are UNLIKELY TO INTEROPERATE, or MAY INTEROPERATE ONLY IF AUTHENTICATION IS REDUCED TO AN UNACCEPTABLY WEAK LEVEL.
在此警告读者，在强制性身份验证机制标准化之前，根据本规范编写的使用更新功能的客户端和服务器不太可能互操作，或者只有在身份验证降低到不可接受的弱级别时才可能互操作。
Implementors are hereby discouraged from deploying LDAPv3 clients or servers which implement the update functionality, until a Proposed Standard for mandatory authentication in LDAPv3 has been approved and published as an RFC.
在此不鼓励实施者部署实现更新功能的LDAPv3客户端或服务器，直到LDAPv3中的强制性身份验证建议标准获得批准并作为RFC发布。
Abstract
摘要
The X.500 Directory uses distinguished names as the primary keys to entries in the directory. Distinguished Names are encoded in ASN.1 in the X.500 Directory protocols. In the Lightweight Directory Access Protocol, a string representation of distinguished names is transferred. This specification defines the string format for representing names, which is designed to give a clean representation of commonly used distinguished names, while being able to represent any distinguished name.
X.500目录使用可分辨名称作为目录项的主键。可分辨名称在X.500目录协议的ASN.1中编码。在轻量级目录访问协议中，传输可分辨名称的字符串表示。本规范定义了用于表示名称的字符串格式，该格式旨在提供常用可分辨名称的清晰表示，同时能够表示任何可分辨名称。
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 RFC 2119 [6].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[6]中所述进行解释。
This specification assumes familiarity with X.500 [1], and the concept of Distinguished Name. 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 clients with a human user interface would display these strings directly to the user, but would most likely be performing translations (such as expressing attribute type names in one of the local national languages).
本规范假定您熟悉X.500[1]和专有名称的概念。重要的是要有一个通用的格式，以便能够明确地表示一个可分辨的名称。本规范的主要目标是易于编码和解码。第二个目标是使名称具有可读性。不希望具有人机界面的LDAP客户端直接向用户显示这些字符串，但很可能正在执行翻译（例如用一种当地国家语言表示属性类型名称）。
In X.501 [2] the ASN.1 structure of distinguished name is defined as:
在X.501[2]中，可分辨名称的ASN.1结构定义为：
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 }
The following sections define the algorithm for converting from an ASN.1 structured representation to a UTF-8 string representation.
以下各节定义了从ASN.1结构化表示转换为UTF-8字符串表示的算法。
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 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 character (',' ASCII 44).
相邻RelativeDistinguishedNames的编码由逗号（“，”ASCII 44）分隔。
When converting from an ASN.1 RelativeDistinguishedName to a string, the output consists of the string encodings of each AttributeTypeAndValue (according to 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 ('+' ASCII 43) character.
如果存在多值RDN，则相邻AttributeTypeAndValue的输出用加号（“+”ASCII 43）分隔。
The AttributeTypeAndValue is encoded as the string representation of the AttributeType, followed by an equals character ('=' ASCII 61), followed by the string representation of the AttributeValue. The encoding of the AttributeValue is given in section 2.4.
AttributeTypeAndValue编码为AttributeType的字符串表示形式，后跟等于字符（'='ASCII 61），后跟AttributeValue的字符串表示形式。AttributeValue的编码在第2.4节中给出。
If the AttributeType is in a published table of attribute types associated with LDAP [4], then the type name string from that table is used, otherwise it is encoded as the dotted-decimal encoding of the AttributeType's OBJECT IDENTIFIER. The dotted-decimal notation is described in [3]. As an example, strings for a few of the attribute types frequently seen in RDNs include:
如果AttributeType位于与LDAP[4]关联的属性类型的已发布表中，则使用该表中的类型名称字符串，否则将其编码为AttributeType对象标识符的点十进制编码。[3]中描述了点十进制表示法。例如，RDN中常见的一些属性类型的字符串包括：
String X.500 AttributeType
------------------------------
CN commonName
L localityName
ST stateOrProvinceName
O organizationName
OU organizationalUnitName
C countryName
STREET streetAddress
DC domainComponent
UID userid
String X.500 AttributeType
------------------------------
CN commonName
L localityName
ST stateOrProvinceName
O organizationName
OU organizationalUnitName
C countryName
STREET streetAddress
DC domainComponent
UID userid
If the AttributeValue is of a type which does not have a string representation defined for it, then it is simply encoded as an octothorpe character ('#' ASCII 35) followed by the hexadecimal representation of each of the bytes of the BER encoding of the X.500 AttributeValue. This form SHOULD be used if the AttributeType is of the dotted-decimal form.
如果AttributeValue的类型没有为其定义字符串表示形式，则仅将其编码为八进制字符（“#”ASCII 35），后跟X.500 AttributeValue的BER编码的每个字节的十六进制表示形式。如果AttributeType为点十进制形式，则应使用此形式。
Otherwise, if the AttributeValue is of a type which has a string representation, the value is converted first to a UTF-8 string according to its syntax specification (see for example section 6 of [4]).
否则，如果AttributeValue是具有字符串表示的类型，则首先根据其语法规范将该值转换为UTF-8字符串（例如，请参见[4]第6节）。
If the UTF-8 string does not have any of the following characters which need escaping, then that string can be used as the string representation of the value.
如果UTF-8字符串没有以下任何需要转义的字符，则该字符串可以用作值的字符串表示形式。
o a space or "#" character occurring at the beginning of the string
o 字符串开头的空格或“#”字符
o a space character occurring at the end of the string
o 出现在字符串末尾的空格字符
o one of the characters ",", "+", """, "\", "<", ">" or ";"
o 字符“、”、“+”、“、”、“\”、“<”、“>”或“；"
Implementations MAY escape other characters.
实现可以转义其他字符。
If a character to be escaped is one of the list shown above, then it is prefixed by a backslash ('\' ASCII 92).
如果要转义的字符是上面显示的列表中的一个字符，则其前缀为反斜杠（“\”ASCII 92）。
Otherwise the character to be escaped is replaced by a backslash and two hex digits, which form a single byte in the code of the character.
否则，要转义的字符将替换为反斜杠和两个十六进制数字，它们构成字符代码中的一个字节。
Examples of the escaping mechanism are shown in section 5.
逃逸机构的示例如第5节所示。
The structure of the string is specified in a BNF grammar, based on the grammar defined in RFC 822 [5]. Server implementations parsing a DN string generated by an LDAPv2 client MUST also accept (and ignore) the variants given in section 4 of this document.
根据RFC 822[5]中定义的语法，在BNF语法中指定字符串的结构。解析LDAPv2客户端生成的DN字符串的服务器实现还必须接受（并忽略）本文档第4节中给出的变量。
distinguishedName = [name] ; may be empty string
distinguishedName = [name] ; may be empty string
name = name-component *("," name-component)
名称=名称组件*（“，”名称组件）
name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
name-component = attributeTypeAndValue *("+" attributeTypeAndValue)
attributeTypeAndValue = attributeType "=" attributeValue
attributeTypeAndValue=attributeType“=”attributeValue
attributeType = (ALPHA 1*keychar) / oid
keychar = ALPHA / DIGIT / "-"
attributeType = (ALPHA 1*keychar) / oid
keychar = ALPHA / DIGIT / "-"
oid = 1*DIGIT *("." 1*DIGIT)
oid = 1*DIGIT *("." 1*DIGIT)
attributeValue = string
attributeValue = string
string = *( stringchar / pair )
/ "#" hexstring
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
string = *( stringchar / pair )
/ "#" hexstring
/ QUOTATION *( quotechar / pair ) QUOTATION ; only from v2
quotechar = <any character except "\" or QUOTATION >
quotechar = <any character except "\" or QUOTATION >
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
special = "," / "=" / "+" / "<" / ">" / "#" / ";"
pair = "\" ( special / "\" / QUOTATION / hexpair )
stringchar = <any character except one of special, "\" or QUOTATION >
pair = "\" ( special / "\" / QUOTATION / hexpair )
stringchar = <any character except one of special, "\" or QUOTATION >
hexstring = 1*hexpair
hexpair = hexchar hexchar
hexstring = 1*hexpair
hexpair = hexchar hexchar
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
hexchar = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
ALPHA = <any ASCII alphabetic character>
; (decimal 65-90 and 97-122)
DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
ALPHA = <any ASCII alphabetic character>
; (decimal 65-90 and 97-122)
DIGIT = <any ASCII decimal digit> ; (decimal 48-57)
QUOTATION = <the ASCII double quotation mark character '"' decimal 34>
The syntax given in this document is more restrictive than the syntax in RFC 1779. Implementations parsing a string generated by an LDAPv2 client MUST accept the syntax of RFC 1779. Implementations MUST NOT, however, generate any of the RFC 1779 encodings which are not described above in section 2.
本文档中给出的语法比RFC1779中的语法更具限制性。解析LDAPv2客户端生成的字符串的实现必须接受RFC1779的语法。然而，实现不得生成上文第2节中未描述的任何RFC1779编码。
Implementations MUST allow a semicolon character to be used instead of a comma to separate RDNs in a distinguished name, and MUST also allow whitespace characters to be present on either side of the comma or semicolon. The whitespace characters are ignored, and the semicolon replaced with a comma.
实现必须允许使用分号字符而不是逗号来分隔可分辨名称中的RDN，还必须允许在逗号或分号的任一侧出现空白字符。将忽略空白字符，并将分号替换为逗号。
Implementations MUST allow an oid in the attribute type to be prefixed by one of the character strings "oid." or "OID.".
实现必须允许属性类型中的oid以字符串“oid.”或“oid.”之一作为前缀。
Implementations MUST allow for space (' ' ASCII 32) characters to be present between name-component and ',', between attributeTypeAndValue and '+', between attributeType and '=', and between '=' and attributeValue. These space characters are ignored when parsing.
实现必须允许在名称组件和“，”之间、attributeTypeAndValue和“+”之间、attributeType和“=”之间以及“=”和attributeValue之间存在空格（“'ASCII 32”）字符。解析时将忽略这些空格字符。
Implementations MUST allow a value to be surrounded by quote ('"' ASCII 34) characters, which are not part of the value. Inside the quoted value, the following characters can occur without any escaping:
实现必须允许值被引号（““”ASCII 34）字符包围，这些字符不是值的一部分。在引号内，可以出现以下字符而不进行任何转义：
",", "=", "+", "<", ">", "#" and ";"
",", "=", "+", "<", ">", "#" and ";"
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）的名称：
CN=Steve Kille,O=Isode Limited,C=GB
CN=Steve Kille,O=Isode Limited,C=GB
Here is an example name containing three RDNs, in which the first RDN is multi-valued:
下面是一个包含三个RDN的示例名称，其中第一个RDN是多值的：
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
OU=Sales+CN=J. Smith,O=Widget Inc.,C=US
This example shows the method of quoting of a comma in an organization name:
此示例显示了在组织名称中引用逗号的方法：
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB
An example name in which a value contains a carriage return character:
值包含回车字符的示例名称：
CN=Before\0DAfter,O=Test,C=GB
CN=Before\0DAfter,O=Test,C=GB
An example name in which an RDN was of an unrecognized type. The value is the BER encoding of an OCTET STRING containing two bytes 0x48 and 0x69.
RDN类型无法识别的示例名称。该值是包含两个字节0x48和0x69的八位字节字符串的BER编码。
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
Finally, an example of an RDN surname value consisting of 5 letters:
最后，一个由5个字母组成的RDN姓氏值示例：
Unicode Letter Description 10646 code UTF-8 Quoted
=============================== ========== ====== =======
LATIN CAPITAL LETTER L U0000004C 0x4C L
LATIN SMALL LETTER U U00000075 0x75 u
LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
LATIN SMALL LETTER I U00000069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
Unicode Letter Description 10646 code UTF-8 Quoted
=============================== ========== ====== =======
LATIN CAPITAL LETTER L U0000004C 0x4C L
LATIN SMALL LETTER U U00000075 0x75 u
LATIN SMALL LETTER C WITH CARON U0000010D 0xC48D \C4\8D
LATIN SMALL LETTER I U00000069 0x69 i
LATIN SMALL LETTER C WITH ACUTE U00000107 0xC487 \C4\87
Could be written in printable ASCII (useful for debugging purposes):
可以用可打印的ASCII编写（用于调试）：
SN=Lu\C4\8Di\C4\87
SN=Lu\C4\8Di\C4\87
[1] The Directory -- overview of concepts, models and services. ITU-T Rec. X.500(1993).
[1] 目录——概念、模型和服务概述。ITU-T Rec.X.500（1993年）。
[2] The Directory -- Models. ITU-T Rec. X.501(1993).
[2] 目录——模型。ITU-T Rec.X.501（1993年）。
[3] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[3] Wahl，M.，Howes，T.，和S.Kille，“轻量级目录访问协议（v3）”，RFC 2251，1997年12月。
[4] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.
[4] Wahl，M.，Coulbeck，A.，Howes，T.和S.Kille，“轻量级目录访问协议（v3）：属性语法定义”，RFC2252，1997年12月。
[5] Crocker, D., "Standard of the Format of ARPA-Internet Text Messages", STD 11, RFC 822, August 1982.
[5] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119.
[6] Bradner，S.“RFC中用于表示需求水平的关键词”，RFC 2119。
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地址-其物理位置（国家、地区、城市、街道地址）-组织属性（如部门名称或隶属关系）
Most countries have privacy laws regarding the publication of information about people.
大多数国家都有关于发布个人信息的隐私法。
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 or DER form. An example of a situation which 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 of the PrintableString choice would have the same representation CN=Sam.
例如，由一个RDN和一个AVA组成的可分辨名称，其中类型为commonName，值为TeletextString选项，字母为“Sam”，在LDAP中表示为字符串CN=Sam。另一个可分辨名称，其中值仍然为“Sam”，但为可打印字符串选项，其表示形式为CN=Sam。
Applications which 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 octothorpe ('#') as described in the first paragraph of section 2.4.
当将可分辨名称转换为LDAP格式时，需要重构值的顺序形式的应用程序不应使用属性语法的字符串表示。相反，他们应该使用十六进制形式，前缀为八进制（“#”）如第2.4节第一段所述。
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
Steve Kille Isode Ltd. The Dome The Square Richmond, Surrey TW9 1DT England
Steve Kille Isode有限公司位于英格兰萨里郡里士满广场的圆顶
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
Phone: +44-181-332-9091
EMail: S.Kille@ISODE.COM
Tim Howes Netscape Communications Corp. 501 E. Middlefield Rd, MS MV068 Mountain View, CA 94043 USA
Tim Howes Netscape Communications Corp.美国加利福尼亚州山景城MV068米德菲尔德东路501号，邮编94043
Phone: +1 650 937-3419
EMail: howes@netscape.com
Phone: +1 650 937-3419
EMail: howes@netscape.com
Copyright (C) The Internet Society (1997). All Rights Reserved.
版权所有（C）互联网协会（1997年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。