Network Working Group M. Crispin
Request for Comments: 4467 University of Washington
Updates: 3501 May 2006
Category: Standards Track
Network Working Group M. Crispin
Request for Comments: 4467 University of Washington
Updates: 3501 May 2006
Category: Standards Track
Internet Message Access Protocol (IMAP) - URLAUTH Extension
Internet消息访问协议（IMAP）-URLAUTH扩展
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
摘要
This document describes the URLAUTH extension to the Internet Message Access Protocol (IMAP) (RFC 3501) and the IMAP URL Scheme (IMAPURL) (RFC 2192). This extension provides a means by which an IMAP client can use URLs carrying authorization to access limited message data on the IMAP server.
本文档描述了对Internet消息访问协议（IMAP）（RFC 3501）和IMAP URL方案（IMAPURL）（RFC 2192）的URLAUTH扩展。此扩展提供了一种方式，通过这种方式，IMAP客户端可以使用带有授权的URL访问IMAP服务器上的有限消息数据。
An IMAP server that supports this extension indicates this with a capability name of "URLAUTH".
支持此扩展的IMAP服务器使用功能名称“URLAUTH”表示此扩展。
In [IMAPURL], a URL of the form imap://fred@example.com/INBOX/;uid=20 requires authorization as userid "fred". However, [IMAPURL] implies that it only supports authentication and confuses the concepts of authentication and authorization.
在[IMAPURL]中，表单的URLimap://fred@example.com/INBOX/；uid=20需要用户ID为“fred”的授权。然而，[IMAPURL]意味着它只支持身份验证，混淆了身份验证和授权的概念。
The URLAUTH extension defines an authorization mechanism for IMAP URLs to replace [IMAPURL]'s authentication-only mechanism. URLAUTH conveys authorization in the URL string itself and reuses a portion of the syntax of the [IMAPURL] authentication mechanism to convey the authorization identity (which also defines the default namespace in [IMAP]).
URLAUTH扩展为IMAP URL定义了一种授权机制，以取代[IMAPURL]的仅验证机制。URLAUTH在URL字符串本身中传递授权，并重用[IMAPURL]身份验证机制的一部分语法来传递授权标识（该标识还定义了[IMAP]中的默认名称空间）。
The URLAUTH extension provides a means by which an authorized user of an IMAP server can create URLAUTH-authorized IMAP URLs. A URLAUTH-authorized URL conveys authorization (not authentication) to the data
URLAUTH扩展提供了一种方法，IMAP服务器的授权用户可以通过该方法创建URLAUTH授权的IMAP URL。URLAUTH授权URL向数据传递授权（而不是身份验证）
addressed by that URL. This URL can be used in another IMAP session to access specific content on the IMAP server, without otherwise providing authorization to any other data (such as other data in the mailbox specified in the URL) owned by the authorizing user.
由该URL寻址。此URL可在另一个IMAP会话中用于访问IMAP服务器上的特定内容，而无需为授权用户拥有的任何其他数据（如URL中指定的邮箱中的其他数据）提供授权。
Conceptually, a URLAUTH-authorized URL can be thought of as a "pawn ticket" that carries no authentication information and can be redeemed by whomever presents it. However, unlike a pawn ticket, URLAUTH has optional mechanisms to restrict the usage of a URLAUTH-authorized URL. Using these mechanisms, URLAUTH-authorized URLs can be usable by:
从概念上讲，URLAUTH授权的URL可以被认为是一张“典当票”，不携带任何身份验证信息，任何人都可以赎回它。但是，与当票不同，URLAUTH具有可选机制来限制URLAUTH授权URL的使用。使用这些机制，URLAUTH授权的URL可以通过以下方式使用：
. anonymous (the "pawn ticket" model) . authenticated users only . a specific authenticated user only . message submission acting on behalf of a specific user only
. 匿名（“当票”模式）。仅限经过身份验证的用户。仅限经过身份验证的特定用户。仅代表特定用户提交邮件
There is also a mechanism for expiration.
还有一种过期机制。
A URLAUTH-authorized URL can be used in the argument to the BURL command in message composition, as described in [BURL], for such purposes as allowing a client (with limited memory or other resources) to submit a message forward or to resend from an IMAP mailbox without requiring the client to fetch that message data.
URLAUTH授权URL可用于消息合成中BURL命令的参数中，如[BURL]中所述，用于允许客户端（内存或其他资源有限）转发消息或从IMAP邮箱重新发送消息，而无需客户端获取该消息数据。
The URLAUTH is generated using an authorization mechanism name and an authorization token, which is generated using a secret mailbox access key. An IMAP client can request that the server generate and assign a new mailbox access key (thus effectively revoking all current URLs using URLAUTH with the old mailbox access key) but cannot set the mailbox access key to a key of its own choosing.
URLAUTH是使用授权机制名称和授权令牌生成的，授权令牌是使用秘密邮箱访问密钥生成的。IMAP客户端可以请求服务器生成并分配新的邮箱访问密钥（从而使用URLAUTH和旧邮箱访问密钥有效地撤销所有当前URL），但不能将邮箱访问密钥设置为自己选择的密钥。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in [KEYWORDS].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”和“可能”应按照[关键词]中的定义进行解释。
The formal syntax uses the Augmented Backus-Naur Form (ABNF) notation including the core rules defined in Appendix A of [ABNF].
形式语法使用扩展的巴科斯-诺尔形式（ABNF）表示法，包括[ABNF]附录A中定义的核心规则。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果单个“C:”或“S:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。
The URLAUTH is a component, appended at the end of a URL, that conveys authorization to access the data addressed by that URL. It contains an authorized access identifier, an authorization mechanism name, and an authorization token. The authorization token is generated from the URL, the authorized access identifier, the authorization mechanism name, and a mailbox access key.
URLAUTH是一个附加在URL末尾的组件，它传递访问该URL寻址的数据的授权。它包含授权访问标识符、授权机制名称和授权令牌。授权令牌由URL、授权访问标识符、授权机制名称和邮箱访问密钥生成。
The mailbox access key is a random string with at least 128 bits of entropy. It is generated by software (not by the human user) and MUST be unpredictable.
邮箱访问密钥是至少具有128位熵的随机字符串。它是由软件（而不是人类用户）生成的，必须是不可预测的。
Each user has a table of mailboxes and an associated mailbox access key for each mailbox. Consequently, the mailbox access key is per-user and per-mailbox. In other words, two users sharing the same mailbox each have a different mailbox access key for that mailbox, and each mailbox accessed by a single user also has a different mailbox access key.
每个用户都有一个邮箱表和每个邮箱的关联邮箱访问密钥。因此，邮箱访问密钥为每个用户和每个邮箱。换句话说，共享同一邮箱的两个用户各自具有该邮箱的不同邮箱访问密钥，并且单个用户访问的每个邮箱也具有不同的邮箱访问密钥。
The authorized access identifier restricts use of the URLAUTH authorized URL to certain users authorized on the server, as described in section 3.
授权访问标识符将URLAUTH授权URL的使用限制为在服务器上授权的某些用户，如第3节所述。
The authorization mechanism is the algorithm by which the URLAUTH is generated and subsequently verified, using the mailbox access key.
授权机制是使用邮箱访问密钥生成并随后验证URLAUTH的算法。
This specification defines the INTERNAL mechanism, which uses a token generation algorithm of the server's choosing and does not involve disclosure of the mailbox access key to the client.
此规范定义了内部机制，该机制使用服务器选择的令牌生成算法，不涉及向客户端公开邮箱访问密钥。
Note: The token generation algorithm chosen by the server implementation should be modern and reasonably secure. At the time of the writing of this document, an [HMAC] such as HMAC-SHA1 is recommended.
注意：服务器实现选择的令牌生成算法应该是现代的，并且相当安全。在编写本文件时，建议使用[HMAC]，如HMAC-SHA1。
If it becomes necessary to change the token generation algorithm of the INTERNAL mechanism (e.g., because an attack against the current algorithm has been discovered), all currently existing URLAUTH-authorized URLs are invalidated by the change in algorithm. Since this would be an unpleasant surprise to applications that depend upon the validity of a URLAUTH-authorized URL, and there is no good way to do a bulk update of existing deployed URLs, it is best to avoid this situation by using a secure algorithm as opposed to one that is "good enough".
如果有必要更改内部机制的令牌生成算法（例如，因为发现了针对当前算法的攻击），则算法的更改将使所有当前存在的URLAUTH授权URL无效。由于这对于依赖URLAUTH授权URL的有效性的应用程序来说是一个令人不快的惊喜，并且没有好的方法对现有部署的URL进行批量更新，因此最好使用安全算法而不是“足够好”的算法来避免这种情况。
Server implementations SHOULD consider the possibility of changing the algorithm. In some cases, it may be desirable to implement the change of algorithm in a way that newly-generated tokens use the new algorithm, but that for a limited period of time tokens using either the new or old algorithm can be validated. Consequently, the server SHOULD incorporate some means of identifying the token generation algorithm within the token.
服务器实现应该考虑改变算法的可能性。在某些情况下，可能希望以新生成的令牌使用新算法的方式来实现算法的更改，但是在有限的时间段内，可以验证使用新算法或旧算法的令牌。因此，服务器应该在令牌中加入一些识别令牌生成算法的方法。
Although this specification is extensible for other mechanisms, none are defined in this document. In addition to the mechanism name itself, other mechanisms may have mechanism-specific data, which is to be interpreted according to the definition of that mechanism.
尽管本规范可扩展用于其他机制，但本文档中未定义任何机制。除了机制名称本身，其他机制可能具有特定于机制的数据，这些数据将根据该机制的定义进行解释。
The authorization token is a deterministic string of at least 128 bits that an entity with knowledge of the secret mailbox access key and URL authorization mechanism can use to verify the URL.
授权令牌是至少128位的确定性字符串，了解秘密邮箱访问密钥和URL授权机制的实体可以使用它来验证URL。
[IMAPURL] is extended by allowing the addition of ";EXPIRE=<datetime>" and ";URLAUTH=<access>:<mech>:<token>" to IMAP URLs that refer to a specific message or message parts.
[IMAPURL]通过允许在引用特定消息或消息部分的IMAP URL中添加“EXPIRE=<datetime>和“URLAUTH=<access>：<mech>：<token>”来扩展。
The URLAUTH is comprised of ";URLAUTH=<access>:<mech>:<token>" and MUST be at the end of the URL.
URLAUTH由“URLAUTH=<access>：<mech>：<token>”组成，必须位于URL的末尾。
URLAUTH does not apply to, and MUST NOT be used with, any IMAP URL that refers to an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.
URLAUTH不适用于引用整个IMAP服务器、邮箱列表、整个IMAP邮箱或IMAP搜索结果的任何IMAP URL，也不得与之一起使用。
When ";EXPIRE=<datetime>" is used, this indicates the latest date and time that the URL is valid. After that date and time, the URL has expired, and server implementations MUST reject the URL. If ";EXPIRE=<datetime>" is not used, the URL has no expiration, but still can be revoked as discussed below.
当使用“EXPIRE=<datetime>”时，这表示URL有效的最新日期和时间。在该日期和时间之后，URL已过期，服务器实现必须拒绝该URL。如果未使用“EXPIRE=<datetime>，则URL不会过期，但仍可以按照下面的讨论撤销。
The URLAUTH takes the form ";URLAUTH=<access>:<mech>:<token>". It is composed of three parts. The <access> portion provides the authorized access identifiers, which may constrain the operations and users that are permitted to use this URL. The <mech> portion provides the authorization mechanism used by the IMAP server to generate the authorization token that follows. The <token> portion provides the authorization token.
URLAUTH的形式为“URLAUTH=<access>：<mech>：<token>”。它由三部分组成。<access>部分提供授权访问标识符，这可能会限制允许使用此URL的操作和用户。<mech>部分提供IMAP服务器用于生成以下授权令牌的授权机制。<token>部分提供授权令牌。
The "submit+" access identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use this URL. The IMAP server does not validate the specified userid but does validate that the IMAP session has an authorization identity that is authorized as a message submission entity. The authorized message submission entity MUST validate the userid prior to contacting the IMAP server.
“submit+”访问标识符前缀后跟用户ID，表示仅允许代表指定用户ID授权为消息提交实体的用户ID使用此URL。IMAP服务器不验证指定的用户ID，但验证IMAP会话是否具有作为消息提交实体授权的授权标识。授权邮件提交实体必须在联系IMAP服务器之前验证用户ID。
The "user+" access identifier prefix, followed by a userid, indicates that use of this URL is limited to IMAP sessions that are logged in as the specified userid (that is, have authorization identity as that userid).
“user+”访问标识符前缀后跟userid，表示此URL的使用仅限于以指定userid登录的IMAP会话（即，具有该userid的授权标识）。
Note: If a SASL mechanism that provides both authorization and authentication identifiers is used to authenticate to the IMAP server, the "user+" access identifier MUST match the authorization identifier.
注意：如果使用同时提供授权和身份验证标识符的SASL机制对IMAP服务器进行身份验证，“用户+”访问标识符必须与授权标识符匹配。
The "authuser" access identifier indicates that use of this URL is limited to IMAP sessions that are logged in as an authorized user (that is, have authorization identity as an authorized user) of that IMAP server. Use of this URL is prohibited to anonymous IMAP sessions.
“authuser”访问标识符表示此URL的使用仅限于作为该IMAP服务器的授权用户（即具有授权用户身份）登录的IMAP会话。禁止在匿名IMAP会话中使用此URL。
The "anonymous" access identifier indicates that use of this URL is not restricted by session authorization identity; that is, any IMAP session in authenticated or selected state (as defined in [IMAP]), including anonymous sessions, may issue a URLFETCH using this URL.
“匿名”访问标识符表示此URL的使用不受会话授权标识的限制；也就是说，任何处于已验证或选定状态（如[IMAP]中定义）的IMAP会话，包括匿名会话，都可以使用此URL发出URLFETCH。
The authorization token is represented as an ASCII-encoded hexadecimal string, which is used to authorize the URL. The length and the calculation of the authorization token depends upon the mechanism used; but, in all cases, the authorization token is at least 128 bits (and therefore at least 32 hexadecimal digits).
授权令牌表示为ASCII编码的十六进制字符串，用于授权URL。授权令牌的长度和计算取决于所使用的机制；但是，在所有情况下，授权令牌至少为128位（因此至少为32位十六进制数字）。
In [IMAPURL], the userid before the "@" in the URL has two purposes:
在[IMAPURL]中，URL中“@”前面的用户ID有两个用途：
1) It provides context for user-specific mailbox paths such as "INBOX".
1) 它为特定于用户的邮箱路径（如“收件箱”）提供上下文。
2) It specifies that resolution of the URL requires logging in as that user and limits use of that URL to only that user.
2) 它指定URL解析需要以该用户身份登录，并将该URL的使用限制为仅限该用户。
An obvious limitation of using the same field for both purposes is that the URL can only be resolved by the mailbox owner.
将同一字段用于两个目的的一个明显限制是URL只能由邮箱所有者解析。
URLAUTH overrides the second purpose of the userid in the IMAP URL and by default permits the URL to be resolved by any user permitted by the access identifier.
URLAUTH覆盖IMAP URL中用户ID的第二个用途，默认情况下允许访问标识符允许的任何用户解析URL。
The "user+<userid>" access identifier limits resolution of that URL to a particular userid, whereas the "submit+<userid>" access identifier is more general and simply requires that the session be authorized by a user that has been granted a "submit" role within the authentication system. Use of either of these access identifiers makes it impossible for an attacker, spying on the session, to use the same URL, either directly or by submission to a message submission entity.
“user+<userid>”访问标识符将该URL的解析限制为特定的userid，而“submit+<userid>”访问标识符更一般，只要求会话由在身份验证系统中被授予“submit”角色的用户授权。使用这些访问标识符中的任何一个都会使监视会话的攻击者无法直接或通过提交到消息提交实体来使用相同的URL。
The "authuser" and "anonymous" access identifiers do not have this level of protection and should be used with caution. These access identifiers are primarily useful for public export of data from an IMAP server, without requiring that it be copied to a web or anonymous FTP server. Refer to the Security Considerations for more details.
“authuser”和“anonymous”访问标识符没有此级别的保护，应谨慎使用。这些访问标识符主要用于从IMAP服务器公开导出数据，而无需将数据复制到web或匿名FTP服务器。有关更多详细信息，请参阅安全注意事项。
A URLAUTH-authorized URL is generated from an initial URL as follows:
URLAUTH授权URL由初始URL生成，如下所示：
An initial URL is built, ending with ";URLAUTH=<access>" but without the ":<mech>:<token>" components. An authorization mechanism is selected and used to calculate the authorization token, with the initial URL as the data and a secret known to the IMAP server as the key. The URLAUTH-authorized URL is generated by taking the initial URL and appending ":", the URL authorization mechanism name, ":", and the ASCII-encoded hexadecimal representation of the authorization token.
生成初始URL，以“URLAUTH=<access>”结尾，但不包含“：<mech>：<token>”组件。选择并使用授权机制来计算授权令牌，初始URL作为数据，IMAP服务器已知的秘密作为密钥。URLAUTH授权URL是通过获取初始URL并附加“：”、URL授权机制名称“：”，以及授权令牌的ASCII编码十六进制表示形式生成的。
Note: ASCII-encoded hexadecimal is used instead of BASE64 because a BASE64 representation may have "=" padding characters, which would be problematic in a URL.
注意：使用ASCII编码的十六进制而不是BASE64，因为BASE64表示可能有“=”填充字符，这在URL中会有问题。
In the INTERNAL mechanism, the mailbox access key for that mailbox is the secret known to the IMAP server, and a server-selected algorithm is used as described in section 2.4.1.
在内部机制中，该邮箱的邮箱访问密钥是IMAP服务器已知的秘密，使用服务器选择的算法，如第2.4.1节所述。
A URLAUTH-authorized URL is validated as follows:
URLAUTH授权的URL验证如下：
The URL is split at the ":" that separates "<access>" from "<mech>:<token>" in the ";URLAUTH=<access>:<mech>:<token>" portion of the URL. The "<mech>:<token>" portion is first parsed and saved as the authorization mechanism and the authorization token. The URL is truncated, discarding the ":" described above, to create a "rump URL" (the URL minus the ":" and the "<mech>:<token>" portion). The rump URL is then analyzed to identify the mailbox.
URL在“：”处拆分，它将“<access>”与URL的“<mech>：<token>”部分中的“<mech>：<token>”分隔开来。首先解析“<mech>：<token>”部分并将其保存为授权机制和授权令牌。URL将被截断，丢弃上面描述的“：”以创建“尾部URL”（URL减去“：”和“<mech>：<token>”部分）。然后分析剩余URL以识别邮箱。
If the mailbox cannot be identified, an authorization token is calculated on the rump URL, using random "plausible" keys (selected by the server) as needed, before returning a validation failure. This prevents timing attacks aimed at identifying mailbox names.
如果无法识别邮箱，则在返回验证失败之前，根据需要使用随机“合理”密钥（由服务器选择）在剩余URL上计算授权令牌。这可以防止针对识别邮箱名称的定时攻击。
If the mailbox can be identified, the authorization token is calculated on the rump URL and a secret known to the IMAP server using the given URL authorization mechanism. Validation is successful if, and only if, the calculated authorization token for that mechanism matches the authorization token supplied in ";URLAUTH=<access>:<mech>:<token>".
如果可以识别邮箱，则使用给定的URL授权机制，根据剩余URL和IMAP服务器已知的秘密计算授权令牌。如果且仅当为该机制计算的授权令牌与“URLAUTH=<access>：<mech>：<token>”中提供的授权令牌匹配时，验证才会成功。
Removal of the ":<mech>:<token>" portion of the URL MUST be the only operation applied to the URLAUTH-authorized URL to get the rump URL. In particular, URL percent escape decoding and case-folding (including to the domain part of the URL) MUST NOT occur.
删除URL的“：<mech>：<token>”部分必须是应用于URLAUTH授权URL以获取尾部URL的唯一操作。特别是，不得进行URL转义解码和大小写折叠（包括URL的域部分）。
In the INTERNAL mechanism, the mailbox access key for that mailbox is used as the secret known to the IMAP server, and the same server-selected algorithm used for generating URLs is used to calculate the authorization token for verification.
在内部机制中，该邮箱的邮箱访问密钥用作IMAP服务器已知的秘密，并使用用于生成URL的相同服务器选择算法计算授权令牌以进行验证。
These commands are extensions to the [IMAP] base protocol.
这些命令是[IMAP]基本协议的扩展。
The section headings of these commands are intended to correspond with where they would be located in the base protocol document if they were part of that document.
这些命令的节标题旨在与它们在基本协议文档中的位置相对应，如果它们是该文档的一部分。
BASE.6.3.RESETKEY. RESETKEY Command
BASE.6.3.reset键。重置键命令
Arguments: optional mailbox name optional mechanism name(s)
参数：可选邮箱名称可选机制名称
Responses: none other than in result
回答：结果就是这样
Result: OK - RESETKEY completed, URLMECH containing new data
NO - RESETKEY error: can't change key of that mailbox
BAD - command unknown or arguments invalid
Result: OK - RESETKEY completed, URLMECH containing new data
NO - RESETKEY error: can't change key of that mailbox
BAD - command unknown or arguments invalid
The RESETKEY command has two forms.
RESETKEY命令有两种形式。
The first form accepts a mailbox name as an argument and generates a new mailbox access key for the given mailbox in the user's mailbox access key table, replacing any previous mailbox access key (and revoking any URLs that were authorized with a URLAUTH using that key) in that table. By default, the mailbox access key is generated for the INTERNAL mechanism; other mechanisms can be specified with the optional mechanism argument.
第一个表单接受邮箱名称作为参数，并在用户的邮箱访问密钥表中为给定邮箱生成新的邮箱访问密钥，替换该表中以前的任何邮箱访问密钥（并撤销使用该密钥的URLAUTH授权的任何URL）。默认情况下，为内部机制生成邮箱访问密钥；可以使用可选的机制参数指定其他机制。
The second form, with no arguments, removes all mailbox access keys in the user's mailbox access key table, revoking all URLs currently authorized using URLAUTH by the user.
第二种形式不带参数，删除用户邮箱访问密钥表中的所有邮箱访问密钥，撤消用户当前使用URLAUTH授权的所有URL。
Any current IMAP session logged in as the user that has the mailbox selected will receive an untagged OK response with the URLMECH status response code (see section BASE.7.1.URLMECH for more details about the URLMECH status response code).
以选中邮箱的用户身份登录的任何当前IMAP会话将收到带有URLMECH状态响应代码的未标记OK响应（有关URLMECH状态响应代码的更多详细信息，请参阅BASE.7.1.URLMECH节）。
Example:
例子：
C: a31 RESETKEY
S: a31 OK All keys removed
C: a32 RESETKEY INBOX
S: a32 OK [URLMECH INTERNAL] mechs
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
C: a31 RESETKEY
S: a31 OK All keys removed
C: a32 RESETKEY INBOX
S: a32 OK [URLMECH INTERNAL] mechs
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
BASE.6.3.GENURLAUTH. GENURLAUTH Command
BASE.6.3.GENURLAUTH。GENURLAUTH命令
Argument: one or more URL/mechanism pairs
参数：一个或多个URL/机制对
Response: untagged response: GENURLAUTH
响应：未标记响应：GENURLAUTH
Result: OK - GENURLAUTH completed
NO - GENURLAUTH error: can't generate a URLAUTH
BAD - command unknown or arguments invalid
Result: OK - GENURLAUTH completed
NO - GENURLAUTH error: can't generate a URLAUTH
BAD - command unknown or arguments invalid
The GENURLAUTH command requests that the server generate a URLAUTH-authorized URL for each of the given URLs using the given URL authorization mechanism.
GENURLAUTH命令请求服务器使用给定的URL授权机制为每个给定URL生成一个经过URLAUTH授权的URL。
The server MUST validate each supplied URL as follows:
服务器必须验证每个提供的URL，如下所示：
(1) The mailbox component of the URL MUST refer to an existing mailbox.
(1) URL的邮箱组件必须引用现有邮箱。
(2) The server component of the URL MUST contain a valid userid that identifies the owner of the mailbox access key table that will be used to generate the URLAUTH-authorized URL. As a consequence, the iserver rule of [IMAPURL] is modified so that iuserauth is mandatory.
(2) URL的服务器组件必须包含有效的用户标识，该用户标识将用于生成URLAUTH授权URL的邮箱访问密钥表的所有者。因此，[IMAPURL]的iserver规则被修改，因此iuserauth是强制性的。
Note: the server component of the URL is generally the logged in userid and server. If not, then the logged in userid and server MUST have owner-type access to the mailbox access key table owned by the userid and server indicated by the server component of the URL.
注意：URL的服务器组件通常是登录的用户ID和服务器。如果不是，则登录的userid和服务器必须具有所有者类型的权限，可以访问由URL的服务器组件指示的userid和服务器拥有的邮箱访问密钥表。
(3) There is a valid access identifier that, in the case of "submit+" and "user+", will contain a valid userid. This userid is not necessarily the same as the owner userid described in (2).
(3) 存在一个有效的访问标识符，在“提交+”和“用户+”的情况下，该标识符将包含一个有效的用户ID。此用户标识不一定与（2）中描述的所有者用户标识相同。
(4) The server MAY also verify that the iuid and/or isection components (if present) are valid.
(4) 服务器还可以验证iuid和/或isection组件（如果存在）是否有效。
If any of the above checks fail, the server MUST return a tagged BAD response with the following exception. If an invalid userid is supplied as the mailbox access key owner and/or as part of the access identifier, the server MAY issue a tagged OK response with a generated mailbox key that always fails validation when used with a URLFETCH command. This exception prevents an attacker from validating userids.
如果上述任何检查失败，服务器必须返回带标记的错误响应，并出现以下异常。如果作为邮箱访问密钥所有者和/或作为访问标识符的一部分提供了无效的用户标识，则服务器可能会发出带有生成邮箱密钥的带标记的OK响应，该邮箱密钥在与URLFETCH命令一起使用时始终未通过验证。此异常可防止攻击者验证用户标识。
If there is currently no mailbox access key for the given mailbox in the owner's mailbox access key table, one is automatically generated. That is, it is not necessary to use RESETKEY prior to first-time use of GENURLAUTH.
如果所有者的邮箱访问密钥表中当前没有给定邮箱的邮箱访问密钥，则会自动生成一个。也就是说，在首次使用GENURLAUTH之前，不必使用RESETKEY。
If the command is successful, a GENURLAUTH response code is returned listing the requested URLs as URLAUTH-authorized URLs.
如果命令成功，将返回一个GENURLAUTH响应代码，将请求的URL列为URLAUTH授权的URL。
Examples:
示例：
C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2" INTERNAL
S: a775 BAD missing access identifier in supplied URL
C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: a776 BAD missing owner username in supplied URL
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
C: a775 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2" INTERNAL
S: a775 BAD missing access identifier in supplied URL
C: a776 GENURLAUTH "imap://example.com/Shared/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: a776 BAD missing owner username in supplied URL
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
BASE.6.3.URLFETCH. URLFETCH Command
BASE.6.3.URLFETCH。URLFETCH命令
Argument: one or more URLs
参数：一个或多个URL
Response: untagged response: URLFETCH
响应：未标记响应：URLFETCH
Result: OK - urlfetch completed NO - urlfetch failed due to server internal error BAD - command unknown or arguments invalid
结果：确定-urlfetch已完成否-urlfetch因服务器内部错误错误而失败-命令未知或参数无效
The URLFETCH command requests that the server return the text data associated with the specified IMAP URLs, as described in [IMAPURL] and extended by this document. The data is returned for all validated URLs, regardless of whether or not the session would otherwise be able to access the mailbox containing that data via SELECT or EXAMINE.
URLFETCH命令请求服务器返回与指定IMAP URL关联的文本数据，如[IMAPURL]中所述，并由本文档扩展。返回所有已验证URL的数据，无论会话是否能够通过SELECT或Inspect访问包含该数据的邮箱。
Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.
注意：此命令不要求URL引用所选邮箱；也不要求选择任何邮箱。它也不会以任何方式干扰任何选定的邮箱。
The URLFETCH command effectively executes with the access of the userid in the server component of the URL (which is generally the userid that issued the GENURLAUTH). By itself, the URLAUTH does NOT grant access to the data; once validated, it grants whatever access to the data is held by the userid in the server component of the URL. That access may have changed since the GENURLAUTH was done.
URLFETCH命令通过访问URL的服务器组件中的用户ID（通常是发出GENURLAUTH的用户ID）有效地执行。URLAUTH本身不授予对数据的访问权；一旦验证，它将授予URL的服务器组件中的用户ID对数据的任何访问权限。自GENURLAUTH完成后，该访问可能已更改。
The URLFETCH command MUST return an untagged URLFETCH response and a tagged OK response to any URLFETCH command that is syntactically valid. A NO response indicates a server internal failure that may be resolved on later retry.
URLFETCH命令必须向语法有效的任何URLFETCH命令返回未标记的URLFETCH响应和标记的OK响应。无响应表示服务器内部故障，可在稍后重试时解决。
Note: The possibility of a NO response is to accommodate implementations that would otherwise have to issue an untagged BYE with a fatal error due to an inability to respond to a valid request. In an ideal world, a server SHOULD NOT issue a NO response.
注意：无响应的可能性是为了适应由于无法响应有效请求而不得不发出带有致命错误的未标记BYE的实现。在理想情况下，服务器不应发出NO响应。
The server MUST return NIL for any IMAP URL that references an entire IMAP server, a list of mailboxes, an entire IMAP mailbox, or IMAP search results.
对于引用整个IMAP服务器、邮箱列表、整个IMAP邮箱或IMAP搜索结果的任何IMAP URL，服务器必须返回NIL。
Example:
例子：
Note: For clarity, this example uses the LOGIN command, which SHOULD NOT be used over a non-encrypted communication path.
注意：为清楚起见，此示例使用LOGIN命令，该命令不应在非加密通信路径上使用。
This example is of a submit server, obtaining a message segment for a message that it has already validated was submitted by "fred".
此示例是一个提交服务器，它为“fred”提交的已验证消息获取消息段。
S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
C: a001 LOGIN submitserver secret
S: a001 OK submitserver logged in
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
S: * OK [CAPABILITY IMAP4REV1 URLAUTH] example.com IMAP server
C: a001 LOGIN submitserver secret
S: a001 OK submitserver logged in
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
These responses are extensions to the [IMAP] base protocol.
这些响应是对[IMAP]基本协议的扩展。
The section headings of these responses are intended to correspond with where they would be located in the base protocol document if they were part of that document.
这些回复的章节标题旨在与它们在基本协议文件中的位置相对应，如果它们是该文件的一部分。
BASE.7.1.URLMECH. URLMECH Status Response Code
BASE.7.1.URLMECH。URLMECH状态响应代码
The URLMECH status response code is followed by a list of URL authorization mechanism names. Mechanism names other than INTERNAL may be appended with an "=" and BASE64-encoded form of mechanism-specific data.
URLMECH状态响应代码后面是URL授权机制名称列表。内部以外的机制名称可以附加“=”和BASE64编码形式的机制特定数据。
This status response code is returned in an untagged OK response in response to a RESETKEY, SELECT, or EXAMINE command. In the case of the RESETKEY command, this status response code can be sent in the tagged OK response instead of requiring a separate untagged OK response.
此状态响应代码在未标记的OK响应中返回，以响应RESETKEY、SELECT或Inspect命令。在RESETKEY命令的情况下，该状态响应代码可以在标记的OK响应中发送，而不需要单独的未标记OK响应。
Example:
例子：
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
C: a33 RESETKEY INBOX XSAMPLE
S: a33 OK [URLMECH INTERNAL XSAMPLE=P34OKhO7VEkCbsiYY8rGEg==] done
In this example, the server supports the INTERNAL mechanism and an experimental mechanism called XSAMPLE, which also holds some mechanism-specific data (the name "XSAMPLE" is for illustrative purposes only).
在本例中，服务器支持内部机制和称为XSAMPLE的实验机制，该机制还保存一些特定于机制的数据（名称“XSAMPLE”仅用于说明目的）。
BASE.7.4.GENURLAUTH. GENURLAUTH Response
BASE.7.4.GENURLAUTH。GENURLAUTH反应
Contents: One or more URLs
内容：一个或多个URL
The GENURLAUTH response returns the URLAUTH-authorized URL(s) requested by a GENURLAUTH command.
GENURLAUTH响应返回GENURLAUTH命令请求的URLAUTH授权URL。
Example:
例子：
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
C: a777 GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred" INTERNAL
S: * GENURLAUTH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal:91354a473744909de610943775f92038"
S: a777 OK GENURLAUTH completed
BASE.7.4.URLFETCH. URLFETCH Response
BASE.7.4.URLFETCH。URLFETCH响应
Contents: One or more URL/nstring pairs
内容：一个或多个URL/nstring对
The URLFETCH response returns the message text data associated with one or more IMAP URLs, as described in [IMAPURL] and extended by this document. This response occurs as the result of a URLFETCH command.
URLFETCH响应返回与一个或多个IMAP URL关联的消息文本数据，如[IMAPURL]中所述，并由本文档扩展。此响应是URLFETCH命令的结果。
The returned data string is NIL if the URL is invalid for any reason (including validation failure). If the URL is valid, but the IMAP fetch of the body part returned NIL (this should not happen), the returned data string should be the empty string ("") and not NIL.
如果URL因任何原因（包括验证失败）无效，则返回的数据字符串为零。如果URL有效，但主体部分的IMAP fetch返回NIL（不应发生这种情况），则返回的数据字符串应为空字符串（“”），而不是NIL。
Note: This command does not require that the URL refer to the selected mailbox; nor does it require that any mailbox be selected. It also does not in any way interfere with any selected mailbox.
注意：此命令不要求URL引用所选邮箱；也不要求选择任何邮箱。它也不会以任何方式干扰任何选定的邮箱。
Example:
例子：
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
C: a002 URLFETCH "imap://joe@example.com/INBOX/;uid=20/
;section=1.2;urlauth=submit+fred:internal
:91354a473744909de610943775f92038"
S: * URLFETCH "imap://joe@example.com/INBOX/;uid=20/;section=1.2
;urlauth=submit+fred:internal
:91354a473744909de610943775f92038" {28}
S: Si vis pacem, para bellum.
S:
S: a002 OK URLFETCH completed
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。
The following modifications are made to the Formal Syntax in [IMAP]:
[IMAP]中的形式语法做了以下修改：
resetkey = "RESETKEY" [SP mailbox *(SP mechanism)]
resetkey=“resetkey”[SP邮箱*（SP机制）]
capability =/ "URLAUTH"
能力=/“URLAUTH”
command-auth =/ resetkey / genurlauth / urlfetch
command-auth =/ resetkey / genurlauth / urlfetch
resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
resp-text-code =/ "URLMECH" SP "INTERNAL" *(SP mechanism ["=" base64])
genurlauth = "GENURLAUTH" 1*(SP url-rump SP mechanism)
genurlauth=“genurlauth”1*（SP url尾部SP机制）
genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
genurlauth-data = "*" SP "GENURLAUTH" 1*(SP url-full)
url-full = astring ; contains authimapurlfull as defined below
url full=astring；包含如下定义的authimapurlfull
url-rump = astring ; contains authimapurlrump as defined below
url-rump=astring；包含如下定义的authimapurlrump
urlfetch = "URLFETCH" 1*(SP url-full)
urlfetch=“urlfetch”1*（SP url已满）
urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
urlfetch-data = "*" SP "URLFETCH" 1*(SP url-full SP nstring)
The following extensions are made to the Formal Syntax in [IMAPURL]:
对[IMAPURL]中的形式语法进行了以下扩展：
authimapurl = "imap://" enc-user [iauth] "@" hostport "/"
imessagepart
; replaces "imapurl" and "iserver" rules for
; URLAUTH authorized URLs
authimapurl = "imap://" enc-user [iauth] "@" hostport "/"
imessagepart
; replaces "imapurl" and "iserver" rules for
; URLAUTH authorized URLs
authimapurlfull = authimapurl iurlauth
authimapurlfull = authimapurl iurlauth
authimapurlrump = authimapurl iurlauth-rump
authimapurlrump = authimapurl iurlauth-rump
enc-urlauth = 32*HEXDIG
enc urlauth=32*HEXDIG
enc-user = 1*achar
; same as "enc_user" in RFC 2192
enc-user = 1*achar
; same as "enc_user" in RFC 2192
iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth
iurlauth = iurlauth-rump ":" mechanism ":" enc-urlauth
iurlauth-rump = [expire] ";URLAUTH=" access
iurlauth-rump = [expire] ";URLAUTH=" access
access = ("submit+" enc-user) / ("user+" enc-user) /
"authuser" / "anonymous"
access = ("submit+" enc-user) / ("user+" enc-user) /
"authuser" / "anonymous"
expire = ";EXPIRE=" date-time
; date-time defined in [DATETIME]
expire = ";EXPIRE=" date-time
; date-time defined in [DATETIME]
mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
; case-insensitive
; new mechanisms MUST be registered with IANA
mechanism = "INTERNAL" / 1*(ALPHA / DIGIT / "-" / ".")
; case-insensitive
; new mechanisms MUST be registered with IANA
Security considerations are discussed throughout this memo.
本备忘录中讨论了安全注意事项。
The mailbox access key SHOULD have at least 128 bits of entropy (refer to [RANDOM] for more details) and MUST be unpredictable.
邮箱访问密钥应至少具有128位熵（有关更多详细信息，请参阅[RANDOM]），并且必须是不可预测的。
The server implementation of the INTERNAL mechanism SHOULD consider the possibility of needing to change the token generation algorithm, and SHOULD incorporate some means of identifying the token generation algorithm within the token.
内部机制的服务器实现应该考虑需要改变令牌生成算法的可能性，并且应该包括标识令牌内的令牌生成算法的一些手段。
The URLMECH status response code may expose sensitive data in the mechanism-specific data for mechanisms other than INTERNAL. A server implementation MUST implement a configuration that will not return a URLMECH status response code unless some mechanism is provided that protects the session from snooping, such as a TLS or SASL security layer that provides confidentiality protection.
URLMECH状态响应代码可能会公开内部机制以外的机制特定数据中的敏感数据。服务器实现必须实现不会返回URLMECH状态响应代码的配置，除非提供了保护会话免受窥探的机制，例如提供机密性保护的TLS或SASL安全层。
The calculation of an authorization token with a "plausible" key if the mailbox can not be identified is necessary to avoid attacks in which the server is probed to see if a particular mailbox exists on the server by measuring the amount of time taken to reject a known bad name versus some other name.
如果无法识别邮箱，则需要使用“合理”密钥计算授权令牌，以避免攻击。在攻击中，通过测量拒绝已知坏名与拒绝其他名称所花费的时间，探测服务器以查看服务器上是否存在特定邮箱。
To protect against a computational denial-of-service attack, a server MAY impose progressively longer delays on multiple URL requests that fail validation.
为了防止计算拒绝服务攻击，服务器可能会对验证失败的多个URL请求施加越来越长的延迟。
The decision to use the "authuser" access identifier should be made with caution. An "authuser" access identifier can be used by any authorized user of the IMAP server; therefore, use of this access identifier should be limited to content that may be disclosed to any authorized user of the IMAP server.
使用“authuser”访问标识符的决定应谨慎。IMAP服务器的任何授权用户都可以使用“authuser”访问标识符；因此，该访问标识符的使用应限于可公开给IMAP服务器的任何授权用户的内容。
The decision to use the "anonymous" access identifier should be made with extreme caution. An "anonymous" access identifier can be used by anyone; therefore, use of this access identifier should be limited to content that may be disclosed to anyone. Many IMAP servers do not permit anonymous access; in this case, the "anonymous" access identifier is equivalent to "authuser", but this MUST NOT be relied upon.
使用“匿名”访问标识符的决定应极其谨慎。任何人都可以使用“匿名”访问标识符；因此，该访问标识符的使用应限于可能向任何人公开的内容。许多IMAP服务器不允许匿名访问；在这种情况下，“匿名”访问标识符相当于“authuser”，但不能依赖于此。
Although this specification does not prohibit the theoretical capability to generate a URL with a server component other than the logged in userid and server, this capability should only be provided
尽管本规范不禁止使用登录的用户ID和服务器以外的服务器组件生成URL的理论功能，但仅应提供此功能
when the logged in userid/server has been authorized as equivalent to the server component userid/server, or otherwise has access to that userid/server mailbox access key table.
当登录的userid/server已被授权为等同于服务器组件userid/server，或以其他方式访问该userid/server邮箱访问密钥表时。
This document constitutes registration of the URLAUTH capability in the imap4-capabilities registry.
本文档构成了URLAUTH功能在imap4功能注册表中的注册。
URLAUTH authorization mechanisms are registered by publishing a standards track or IESG-approved experimental RFC. The registry is currently located at:
URLAUTH授权机制通过发布标准跟踪或IESG批准的实验RFC进行注册。注册处目前位于：
http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
http://www.iana.org/assignments/urlauth-authorization-mechanism-registry
This registry is case-insensitive.
此注册表不区分大小写。
This document constitutes registration of the INTERNAL URLAUTH authorization mechanism.
本文档构成内部URLAUTH授权机制的注册。
IMAP URLAUTH Authorization Mechanism Registry
IMAP URLAUTH授权机制注册表
Mechanism Name Reference
-------------- ---------
INTERNAL [RFC4467]
Mechanism Name Reference
-------------- ---------
INTERNAL [RFC4467]
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[BURL] Newman, C., "Message Submission BURL Extension", RFC 4468, May 2006.
[BURL]Newman，C.，“消息提交BURL扩展”，RFC 4468，2006年5月。
[DATETIME] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[日期时间]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，2002年7月。
[IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[IMAPURL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997.
[IMAPURL]纽曼，C.，“IMAP URL方案”，RFC 2192192191997年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RANDOM]Eastlake，D.，3rd，Schiller，J.和S.Crocker，“安全的随机性要求”，BCP 106，RFC 40862005年6月。
Author's Address
作者地址
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527
Mark R. Crispin网络与分布式计算华盛顿大学西雅图第十五大街4545号WA98105-427
Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
电话：（206）543-5762电子邮件：MRC@CAC.Washington.EDU
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）提供。