Network Working Group C. Daboo
Request for Comments: 5464 Apple, Inc.
Category: Standards Track February 2009
Network Working Group C. Daboo
Request for Comments: 5464 Apple, Inc.
Category: Standards Track February 2009
The IMAP METADATA Extension
IMAP元数据扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
The METADATA extension to the Internet Message Access Protocol permits clients and servers to maintain "annotations" or "metadata" on IMAP servers. It is possible to have annotations on a per-mailbox basis or on the server as a whole. For example, this would allow comments about the purpose of a particular mailbox to be "attached" to that mailbox, or a "message of the day" containing server status information to be made available to anyone logging in to the server.
Internet消息访问协议的元数据扩展允许客户端和服务器在IMAP服务器上维护“注释”或“元数据”。可以在每个邮箱上或在整个服务器上设置批注。例如，这将允许将有关特定邮箱用途的注释“附加”到该邮箱，或者允许任何登录到服务器的人使用包含服务器状态信息的“当日邮件”。
Table of Contents
目录
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Namespace of Entries . . . . . . . . . . . . . . . . . . . 4
3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5
3.3. Private versus Shared and Access Control . . . . . . . . . 6
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7
4.1. General Considerations . . . . . . . . . . . . . . . . . . 7
4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 8
4.2.1. MAXSIZE GETMETADATA Command Option . . . . . . . . . . 9
4.2.2. DEPTH GETMETADATA Command Option . . . . . . . . . . . 10
4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 10
4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 12
4.4.1. METADATA Response with Values . . . . . . . . . . . . 13
4.4.2. Unsolicited METADATA Response without Values . . . . . 13
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Entry and Attribute Registration Template . . . . . . . . 16
6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 16
6.2.1. /shared/comment . . . . . . . . . . . . . . . . . . . 17
6.2.2. /shared/admin . . . . . . . . . . . . . . . . . . . . 17
6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 17
6.3.1. /shared/comment . . . . . . . . . . . . . . . . . . . 18
6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Namespace of Entries . . . . . . . . . . . . . . . . . . . 4
3.2.1. Entry Names . . . . . . . . . . . . . . . . . . . . . 5
3.3. Private versus Shared and Access Control . . . . . . . . . 6
4. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 7
4.1. General Considerations . . . . . . . . . . . . . . . . . . 7
4.2. GETMETADATA Command . . . . . . . . . . . . . . . . . . . 8
4.2.1. MAXSIZE GETMETADATA Command Option . . . . . . . . . . 9
4.2.2. DEPTH GETMETADATA Command Option . . . . . . . . . . . 10
4.3. SETMETADATA Command . . . . . . . . . . . . . . . . . . . 10
4.4. METADATA Response . . . . . . . . . . . . . . . . . . . . 12
4.4.1. METADATA Response with Values . . . . . . . . . . . . 13
4.4.2. Unsolicited METADATA Response without Values . . . . . 13
5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Entry and Attribute Registration Template . . . . . . . . 16
6.2. Server Entry Registrations . . . . . . . . . . . . . . . . 16
6.2.1. /shared/comment . . . . . . . . . . . . . . . . . . . 17
6.2.2. /shared/admin . . . . . . . . . . . . . . . . . . . . 17
6.3. Mailbox Entry Registrations . . . . . . . . . . . . . . . 17
6.3.1. /shared/comment . . . . . . . . . . . . . . . . . . . 18
6.3.2. /private/comment . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
The goal of the METADATA extension is to provide a means for clients to set and retrieve "annotations" or "metadata" on an IMAP server. The annotations can be associated with specific mailboxes or the server as a whole. The server can choose to support only server annotations or both server and mailbox annotations.
元数据扩展的目标是为客户端提供一种在IMAP服务器上设置和检索“注释”或“元数据”的方法。注释可以与特定邮箱或整个服务器相关联。服务器可以选择仅支持服务器批注，或同时支持服务器批注和邮箱批注。
A server that supports both server and mailbox annotations indicates the presence of this extension by returning "METADATA" as one of the supported capabilities in the CAPABILITY command response.
同时支持服务器和邮箱批注的服务器通过在CAPABILITY命令响应中返回“元数据”作为支持的功能之一来指示此扩展的存在。
A server that supports only server annotations indicates the presence of this extension by returning "METADATA-SERVER" as one of the supported capabilities in the CAPABILITY command response.
仅支持服务器注释的服务器通过在CAPABILITY命令响应中返回“METADATA-server”作为支持的功能之一来指示此扩展的存在。
A server that supports unsolicited annotation change responses MUST support the "ENABLE" [RFC5161] extension to allow clients to turn that feature on.
支持未经请求的注释更改响应的服务器必须支持“启用”[RFC5161]扩展，以允许客户端打开该功能。
The METADATA extension adds two new commands and one new untagged response to the IMAP base protocol.
元数据扩展向IMAP基本协议添加了两个新命令和一个新的未标记响应。
This extension makes the following changes to the IMAP protocol:
此扩展对IMAP协议进行以下更改：
o adds a new SETMETADATA command
o 添加新的SETMETADATA命令
o adds a new GETMETADATA command
o 添加一个新的GETMETADATA命令
o adds a new METADATA untagged response
o 添加新的元数据未标记响应
o adds a new METADATA response code
o 添加新的元数据响应代码
The rest of this document describes the data model and protocol changes more rigorously.
本文档的其余部分更严格地描述了数据模型和协议更改。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Whitespace and line breaks have been added to the examples in this document to promote readability.
本文档中的示例中添加了空格和换行符，以提高可读性。
Mailboxes or the server as a whole may have zero or more annotations associated with them. An annotation contains a uniquely named entry, which has a value. Annotations can be added to mailboxes when a mailbox name is provided as the first argument to the SETMETADATA command, or to the server as a whole when the empty string is provided as the first argument to the command.
邮箱或服务器作为一个整体可能具有零个或多个与其关联的批注。注释包含具有唯一名称的条目，该条目具有值。当邮箱名称作为SETMETADATA命令的第一个参数提供时，可以将批注添加到邮箱中；当空字符串作为该命令的第一个参数提供时，可以将批注添加到整个服务器中。
For example, a general comment being added to a mailbox may have an entry name of "/comment" and a value of "Really useful mailbox".
例如，添加到邮箱的一般性评论可能具有条目名“/comment”和值“Really Usage mailbox”。
The protocol changes to IMAP described below allow a client to access or change the values of any annotation entry, assuming it has sufficient access rights to do so.
下面描述的对IMAP的协议更改允许客户端访问或更改任何注释项的值，前提是它有足够的访问权限。
Each annotation is an entry that has a hierarchical name, with each component of the name separated by a slash ("/"). An entry name MUST NOT contain two consecutive "/" characters and MUST NOT end with a "/" character.
每个注释都是一个具有层次名称的条目，名称的每个组成部分都用斜杠（“/”）分隔。条目名称不得包含两个连续的“/”字符，且不得以“/”字符结尾。
The value of an entry is NIL (has no value), or a string or binary data of zero or more octets. A string MAY contain multiple lines of text. Clients MUST use the CRLF (0x0D 0x0A) character octet sequence to represent line ends in a multi-line string value.
条目的值为NIL（无值），或零个或多个八位字节的字符串或二进制数据。一个字符串可以包含多行文本。客户端必须使用CRLF（0x0D 0x0A）字符八位字节序列来表示多行字符串值中的行结束。
Entry names MUST NOT contain asterisk ("*") or percent ("%") characters and MUST NOT contain non-ASCII characters or characters with octet values in the range 0x00 to 0x19. Invalid entry names result in a BAD response in any IMAP command in which they are used.
条目名称不得包含星号（“*”）或百分比（“%”）字符，也不得包含非ASCII字符或八位字节值在0x00到0x19范围内的字符。无效的条目名称会导致在使用它们的任何IMAP命令中出现错误响应。
Entry names are case-insensitive.
条目名称不区分大小写。
Use of control or punctuation characters in entry names is strongly discouraged.
强烈反对在条目名称中使用控制或标点符号。
This specification defines an initial set of entry names available for use with mailbox and server annotations. In addition, an extension mechanism is described to allow additional names to be added for extensibility.
此规范定义了一组初始条目名称，可用于邮箱和服务器批注。此外，还描述了一种扩展机制，以允许为扩展性添加其他名称。
The first component in entry names defines the scope of the annotation. Currently, only the prefixes "/private" or "/shared" are defined. These prefixes are used to indicate whether an annotation
条目名称中的第一个组件定义注释的范围。目前，仅定义前缀“/private”或“/shared”。这些前缀用于指示注释
is stored on a per-user basis ("/private") and not visible to other users, or whether an annotation is shared between authorized users ("/shared") with a single value that can be read and changed by authorized users with appropriate access. See Section 3.3 for details.
以每个用户（“/private”）为基础存储，其他用户不可见，或者是否在授权用户之间共享批注（“/shared”），该批注具有单个值，授权用户可以通过适当的访问权限读取和更改该值。详见第3.3节。
Entry names can have any number of components starting at 2, unless they fall under the vendor namespaces (i.e., have a /shared/vendor/ <vendor-token> or /private/vendor/<vendor-token> prefix as described below), in which case they have at least 4 components.
条目名称可以有任意数量的组件，从2开始，除非它们属于供应商名称空间（即具有/shared/vendor/<vendor token>或/private/vendor/<vendor token>前缀，如下所述），在这种情况下，它们至少有4个组件。
Entry names MUST be specified in a Standards Track or IESG-approved Experimental RFC, or fall under the vendor namespace. See Section 6.1 for the registration template.
条目名称必须在标准跟踪或IESG批准的实验RFC中指定，或属于供应商名称空间。注册模板见第6.1节。
These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA command is the empty string.
当new SETMETADATA或GETMETADATA命令的邮箱名称参数为空字符串时，将设置或检索这些条目。
/shared/comment
/分享/评论
Defines a comment or note that is associated with the server and that is shared with authorized users of the server.
定义与服务器关联并与服务器授权用户共享的注释或注释。
/shared/admin
/共享/管理
Indicates a method for contacting the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL). This entry is always read-only -- clients cannot change it. It is visible to authorized users of the system.
指示联系服务器管理员的方法。该值必须是URI（例如，mailto:或tel:URL）。此条目始终是只读的--客户端无法更改它。它对系统的授权用户可见。
/shared/vendor/<vendor-token>
/shared/vendor/<vendor-token>
Defines the top level of shared entries associated with the server, as created by a particular product of some vendor. This entry can be used by vendors to provide server- or client-specific annotations. The vendor-token MUST be registered with IANA, using the Application Configuration Access Protocol (ACAP) [RFC2244] vendor subtree registry.
定义由某供应商的特定产品创建的与服务器关联的共享项的顶层。供应商可以使用此条目提供特定于服务器或客户端的注释。供应商令牌必须使用应用程序配置访问协议（ACAP）[RFC2244]供应商子树注册表向IANA注册。
/private/vendor/<vendor-token>
/private/vendor/<vendor-token>
Defines the top level of private entries associated with the server, as created by a particular product of some vendor. This entry can be used by vendors to provide server- or client-specific
定义由某个供应商的特定产品创建的与服务器关联的顶级私有条目。供应商可以使用此条目提供服务器或客户端特定的
annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry.
注释。供应商令牌必须使用ACAP[RFC2244]供应商子树注册表向IANA注册。
These entries are set or retrieved when the mailbox name argument to the new SETMETADATA or GETMETADATA command is not the empty string.
当new SETMETADATA或GETMETADATA命令的邮箱名称参数不是空字符串时，将设置或检索这些条目。
/shared/comment
/分享/评论
Defines a shared comment or note associated with a mailbox.
定义与邮箱关联的共享注释或便笺。
/private/comment
/私人/评论
Defines a private (per-user) comment or note associated with a mailbox.
定义与邮箱关联的专用（每个用户）注释或便笺。
/shared/vendor/<vendor-token>
/shared/vendor/<vendor-token>
Defines the top level of shared entries associated with a specific mailbox, as created by a particular product of some vendor. This entry can be used by vendors to provide client-specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry.
定义与特定邮箱关联的共享项的顶层，该邮箱由某个供应商的特定产品创建。供应商可以使用此条目提供特定于客户端的注释。供应商令牌必须使用ACAP[RFC2244]供应商子树注册表向IANA注册。
/private/vendor/<vendor-token>
/private/vendor/<vendor-token>
Defines the top level of private entries associated with a specific mailbox, as created by a particular product of some vendor. This entry can be used by vendors to provide client-specific annotations. The vendor-token MUST be registered with IANA, using the ACAP [RFC2244] vendor subtree registry.
定义与特定邮箱关联的顶级专用条目，如某些供应商的特定产品所创建的。供应商可以使用此条目提供特定于客户端的注释。供应商令牌必须使用ACAP[RFC2244]供应商子树注册表向IANA注册。
In the absence of the ACL (Access Control List) extension [RFC4314], users can only set and retrieve private or shared mailbox annotations on a mailbox that exists and is returned to them via a LIST or LSUB command, and on which they have either read or write access to the actual message content of the mailbox (as determined by the READ-ONLY and READ-WRITE response codes as described in Section 5.2 of [RFC4314]).
在没有ACL（访问控制列表）扩展[RFC4314]的情况下，用户只能在存在的邮箱上设置和检索私有或共享邮箱批注，该邮箱通过List或LSUB命令返回给用户，并且用户对邮箱的实际邮件内容具有读或写访问权限（由[RFC4314]第5.2节所述的只读和读写响应代码确定）。
When the ACL extension [RFC4314] is present, users can only set and retrieve private or shared mailbox annotations on a mailbox on which they have the "l" right and any one of the "r", "s", "w", "i", or "p" rights.
当存在ACL扩展[RFC4314]时，用户只能在拥有“l”权限和“r”、“s”、“w”、“i”或“p”权限中任何一个的邮箱上设置和检索专用或共享邮箱批注。
If a client attempts to set or retrieve annotations on mailboxes that do not satisfy the conditions above, the server MUST respond with a NO response.
如果客户端试图在不满足上述条件的邮箱上设置或检索批注，服务器必须以无响应进行响应。
Users can always retrieve private or shared server annotations if they exist. Servers MAY restrict the creation of private or shared server annotations as appropriate. When restricted, the server MUST return a NO response when the SETMETADATA command is used to try to create a server annotation.
如果存在私有或共享服务器批注，用户始终可以检索它们。服务器可能会根据需要限制创建专用或共享服务器批注。受限制时，当使用SETMETADATA命令尝试创建服务器批注时，服务器必须返回NO响应。
If the METADATA extension is present, support for shared annotations is REQUIRED, whilst support for private annotations is OPTIONAL. This recognizes the fact that support for private annotations may introduce significantly more complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations, etc.
如果存在元数据扩展，则需要支持共享注释，而支持私有注释是可选的。这承认了这样一个事实，即在跟踪注释的所有权、如何根据用户自己的注释确定配额等方面，对私有注释的支持可能会给服务器带来更大的复杂性。
The new SETMETADATA command and the METADATA response each have a mailbox name argument. An empty string is used for the mailbox name to signify server annotations. A non-empty string is used to signify mailbox annotations attached to the corresponding mailbox.
新的SETMETADATA命令和元数据响应都有一个邮箱名称参数。邮箱名称使用空字符串表示服务器批注。非空字符串用于表示附加到相应邮箱的邮箱批注。
Servers SHOULD ensure that mailbox annotations are automatically moved when the mailbox they refer to is renamed, i.e., the annotations follow the mailbox. This applies to a rename of the INBOX, with the additional behavior that the annotations are copied from the original INBOX to the renamed mailbox, i.e., mailbox annotations are preserved on the INBOX when it is renamed.
服务器应确保在重命名其引用的邮箱时自动移动邮箱批注，即批注跟随邮箱。这适用于收件箱的重命名，还有一个附加行为，即将批注从原始收件箱复制到重命名的邮箱，即重命名时邮箱批注保留在收件箱中。
Servers SHOULD delete annotations for a mailbox when the mailbox is deleted, so that a mailbox created with the same name as a previously existing mailbox does not inherit the old mailbox annotations.
删除邮箱时，服务器应删除邮箱的批注，以便使用与以前存在的邮箱相同的名称创建的邮箱不会继承旧邮箱批注。
Servers SHOULD allow annotations on all 'types' of mailboxes, including ones reporting \Noselect for their LIST response. Servers can implicitly remove \Noselect mailboxes when all child mailboxes are removed, and, at that time any annotations associated with the \Noselect mailbox SHOULD be removed.
服务器应允许对所有“类型”的邮箱进行批注，包括那些报告其列表响应的邮箱。删除所有子邮箱时，服务器可以隐式删除\n选择邮箱，此时应删除与\n选择邮箱关联的任何批注。
The server is allowed to impose limitations on the size of any one annotation or the total number of annotations for a single mailbox or for the server as a whole. However, the server MUST accept an annotation data size of at least 1024 bytes, and an annotation count per server or mailbox of at least 10.
允许服务器对单个邮箱或整个服务器的任何一个批注的大小或批注总数施加限制。但是，服务器必须接受至少1024字节的批注数据大小，以及每个服务器或邮箱至少10个批注计数。
Some annotations may be "read-only" -- i.e., they are set by the server and cannot be changed by the client. Also, such annotations may be "computed" -- i.e., the value changes based on underlying properties of the mailbox or server. For example, an annotation reporting the total size of all messages in the mailbox would change as messages are added or removed. Or, an annotation containing an IMAP URL for the mailbox would change if the mailbox was renamed.
某些注释可能是“只读的”——即，它们由服务器设置，不能由客户端更改。此外，这些注释可以是“计算的”——即，值根据邮箱或服务器的底层属性而改变。例如，报告邮箱中所有邮件的总大小的批注将随着邮件的添加或删除而更改。或者，如果重命名邮箱，则包含邮箱IMAP URL的批注将发生更改。
Servers MAY support sending unsolicited responses for use when annotations are changed by some "third-party" (see Section 4.4). In order to do so, servers MUST support the ENABLE command [RFC5161] and MUST only send unsolicited responses if the client used the ENABLE command [RFC5161] extension with the capability string "METADATA" or "METADATA-SERVER" earlier in the session, depending on which of those capabilities is supported by the server.
服务器可能支持发送未经请求的响应，以便在注释被某些“第三方”更改时使用（参见第4.4节）。为此，服务器必须支持ENABLE命令[RFC5161]，并且仅当客户端在会话早期使用ENABLE命令[RFC5161]扩展名和功能字符串“METADATA”或“METADATA-SERVER”时，服务器才必须发送未经请求的响应，具体取决于服务器支持哪些功能。
This extension adds the GETMETADATA command. This allows clients to retrieve server or mailbox annotations.
此扩展添加了GETMETADATA命令。这允许客户端检索服务器或邮箱批注。
This command is only available in authenticated or selected state [RFC3501].
此命令仅在已验证或选定状态[RFC3501]下可用。
Arguments: mailbox-name options entry-specifier
参数：邮箱名称选项条目说明符
Responses: required METADATA response
响应：必需的元数据响应
Result: OK - command completed NO - command failure: can't access annotations on the server BAD - command unknown or arguments invalid
结果：确定-命令已完成否-命令失败：无法访问服务器上的批注错误-命令未知或参数无效
When the mailbox name is the empty string, this command retrieves server annotations. When the mailbox name is not empty, this command retrieves annotations on the specified mailbox.
当邮箱名称为空字符串时，此命令检索服务器批注。当邮箱名称不为空时，此命令将检索指定邮箱上的批注。
Options MAY be included with this command and are defined below.
此命令中可能包含选项，选项定义如下。
Example:
例子：
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "Shared comment")
S: a OK GETMETADATA complete
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "Shared comment")
S: a OK GETMETADATA complete
In the above example, the contents of the value of the "/shared/ comment" server entry is requested by the client and returned by the server.
在上面的示例中，“/shared/comment”服务器条目的值的内容由客户端请求，并由服务器返回。
Example:
例子：
C: a GETMETADATA "INBOX" /private/comment
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK GETMETADATA complete
C: a GETMETADATA "INBOX" /private/comment
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK GETMETADATA complete
In the above example, the contents of the value of the "/private/ comment" mailbox entry for the mailbox "INBOX" is requested by the client and returned by the server.
在上面的示例中，客户端请求邮箱“收件箱”的“/private/comment”邮箱条目的值的内容，服务器返回该值。
Entry specifiers can be lists of atomic specifiers, so that multiple annotations may be returned in a single GETMETADATA command.
条目说明符可以是原子说明符的列表，因此可以在单个GETMETADATA命令中返回多个注释。
Example:
例子：
C: a GETMETADATA "INBOX" (/shared/comment /private/comment)
S: * METADATA "INBOX" (/shared/comment "Shared comment"
/private/comment "My own comment")
S: a OK GETMETADATA complete
C: a GETMETADATA "INBOX" (/shared/comment /private/comment)
S: * METADATA "INBOX" (/shared/comment "Shared comment"
/private/comment "My own comment")
S: a OK GETMETADATA complete
In the above example, the values of the two server entries "/shared/comment" and "/private/comment" on the mailbox "INBOX" are requested by the client and returned by the server.
在上面的示例中，客户端请求邮箱“收件箱”上的两个服务器条目“/shared/comment”和“/private/comment”的值，并由服务器返回。
When the MAXSIZE option is specified with the GETMETADATA command, it restricts which entry values are returned by the server. Only entry values that are less than or equal in octet size to the specified MAXSIZE limit are returned. If there are any entries with values larger than the MAXSIZE limit, the server MUST include the METADATA LONGENTRIES response code in the tagged OK response for the GETMETADATA command. The METADATA LONGENTRIES response code returns the size of the biggest entry value requested by the client that exceeded the MAXSIZE limit.
当使用GETMETADATA命令指定MAXSIZE选项时，它会限制服务器返回的条目值。仅返回八位字节大小小于或等于指定MAXSIZE限制的条目值。如果有任何条目的值大于MAXSIZE限制，则服务器必须在GETMETADATA命令的标记好响应中包含METADATA LONGENTRIES响应代码。METADATA LONGENTRIES响应代码返回客户端请求的超过MAXSIZE限制的最大条目值的大小。
Example:
例子：
C: a GETMETADATA "INBOX" (MAXSIZE 1024)
(/shared/comment /private/comment)
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete
C: a GETMETADATA "INBOX" (MAXSIZE 1024)
(/shared/comment /private/comment)
S: * METADATA "INBOX" (/private/comment "My own comment")
S: a OK [METADATA LONGENTRIES 2199] GETMETADATA complete
In the above example, the values of the two server entries "/shared/comment" and "/private/comment" on the mailbox "INBOX" are requested by the client, which wants to restrict the size of returned values to 1024 octets. In this case, the "/shared/ comment" entry value is 2199 octets and is not returned.
在上面的示例中，客户端请求邮箱“收件箱”上的两个服务器条目“/shared/comment”和“/private/comment”的值，希望将返回值的大小限制为1024个八位字节。在这种情况下，“/shared/comment”输入值为2199个八位字节，不返回。
When the DEPTH option is specified with the GETMETADATA command, it extends the list of entry values returned by the server. For each entry name specified in the GETMETADATA command, the server returns the value of the specified entry name (if it exists), plus all entries below the entry name up to the specified DEPTH. Three values are allowed for DEPTH:
当使用GETMETADATA命令指定DEPTH选项时，它会扩展服务器返回的条目值列表。对于GETMETADATA命令中指定的每个条目名称，服务器返回指定条目名称（如果存在）的值，加上条目名称下方直到指定深度的所有条目。深度允许三个值：
"0" - no entries below the specified entry are returned "1" - only entries immediately below the specified entry are returned "infinity" - all entries below the specified entry are returned
“0”-不返回指定项下的任何项“1”-仅返回直接位于指定项下的项“无限”-返回指定项下的所有项
Thus, "depth 1" for an entry "/a" will match "/a" as well as its children entries (e.g., "/a/b"), but will not match grandchildren entries (e.g., "/a/b/c").
因此，条目“/a”的“深度1”将匹配“/a”及其子条目（例如“/a/b”），但不会匹配子条目（例如“/a/b/c”）。
If the DEPTH option is not specified, this is the same as specifying "DEPTH 0".
如果未指定深度选项，则与指定“深度0”相同。
Example:
例子：
C: a GETMETADATA "INBOX" (DEPTH 1)
(/private/filters/values)
S: * METADATA "INBOX" (/private/filters/values/small
"SMALLER 5000" /private/filters/values/boss
"FROM \"boss@example.com\"")
S: a OK GETMETADATA complete
C: a GETMETADATA "INBOX" (DEPTH 1)
(/private/filters/values)
S: * METADATA "INBOX" (/private/filters/values/small
"SMALLER 5000" /private/filters/values/boss
"FROM \"boss@example.com\"")
S: a OK GETMETADATA complete
In the above example, 2 entries below the /private/filters/values
entry exist on the mailbox "INBOX": "/private/filters/values/
small" and "/private/filters/values/boss".
In the above example, 2 entries below the /private/filters/values
entry exist on the mailbox "INBOX": "/private/filters/values/
small" and "/private/filters/values/boss".
This extension adds the SETMETADATA command. This allows clients to set annotations.
此扩展添加SETMETADATA命令。这允许客户端设置注释。
This command is only available in authenticated or selected state [RFC3501].
此命令仅在已验证或选定状态[RFC3501]下可用。
Arguments: mailbox-name entry value list of entry, values
参数：邮箱名称条目值条目列表、值
Responses: no specific responses for this command
响应：此命令没有特定的响应
Result: OK - command completed NO - command failure: can't set annotations, or annotation too big or too many BAD - command unknown or arguments invalid
结果：确定-命令完成无-命令失败：无法设置批注，或批注太大或太多错误-命令未知或参数无效
This command sets the specified list of entries by adding or replacing the specified values provided, on the specified existing mailboxes or on the server (if the mailbox argument is the empty string). Clients can use NIL for the value of entries it wants to remove. The server SHOULD NOT return a METADATA response containing the updated annotation data. Clients MUST NOT assume that a METADATA response will be sent, and MUST assume that if the command succeeds, then the annotation has been changed.
此命令通过在指定的现有邮箱或服务器（如果邮箱参数为空字符串）上添加或替换提供的指定值来设置指定的条目列表。客户端可以使用NIL作为它要删除的条目的值。服务器不应返回包含更新注释数据的元数据响应。客户端不能假定将发送元数据响应，并且必须假定如果命令成功，则注释已更改。
If the server is unable to set an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[METADATA MAXSIZE NNN]" response code when NNN is the maximum octet count that it is willing to accept.
如果服务器无法设置批注，因为其值的大小太大，则当NNN是其愿意接受的最大八位字节计数时，服务器必须返回带有“[METADATA MAXSIZE NNN]”响应代码的标记无响应。
If the server is unable to set a new annotation because the maximum number of allowed annotations has already been reached, the server MUST return a tagged NO response with a "[METADATA TOOMANY]" response code.
如果由于已达到允许的最大批注数，服务器无法设置新批注，则服务器必须返回带“[METADATA TOOMANY]”响应代码的标记无响应。
If the server is unable to set a new annotation because it does not support private annotations on one of the specified mailboxes, the server MUST return a tagged NO response with a "[METADATA NOPRIVATE]" response code.
如果服务器无法设置新批注，因为它不支持其中一个指定邮箱上的专用批注，则服务器必须返回带有“[METADATA NOPRIVATE]”响应代码的标记无响应。
When any one annotation fails to be set, resulting in a tagged NO response from the server, then the server MUST NOT change the values for other annotations specified in the SETMETADATA command.
如果任何一个注释设置失败，导致服务器发出标记为“无”的响应，则服务器不得更改SETMETADATA命令中指定的其他注释的值。
Example:
例子：
C: a SETMETADATA INBOX (/private/comment {33}
S: + ready for data
My new comment across
two lines.
)
S: a OK SETMETADATA complete
C: a SETMETADATA INBOX (/private/comment {33}
S: + ready for data
My new comment across
two lines.
)
S: a OK SETMETADATA complete
In the above example, the entry "/private/comment" for the mailbox "INBOX" is created (if not already present) and the value set to a multi-line string.
在上面的示例中，将创建邮箱“收件箱”的条目“/private/comment”（如果尚未存在），并将该值设置为多行字符串。
Example:
例子：
C: a SETMETADATA INBOX (/private/comment NIL)
S: a OK SETMETADATA complete
C: a SETMETADATA INBOX (/private/comment NIL)
S: a OK SETMETADATA complete
In the above example, the entry "/private/comment" is removed from the mailbox "INBOX".
在上面的示例中，条目“/private/comment”将从邮箱“收件箱”中删除。
Multiple entries can be set in a single SETMETADATA command by listing entry-value pairs in the list.
通过在列表中列出条目-值对，可以在单个SETMETADATA命令中设置多个条目。
Example:
例子：
C: a SETMETADATA INBOX (/private/comment "My new comment"
/shared/comment "This one is for you!")
S: a OK SETMETADATA complete
C: a SETMETADATA INBOX (/private/comment "My new comment"
/shared/comment "This one is for you!")
S: a OK SETMETADATA complete
In the above example, the entries "/private/comment" and "/shared/ comment" for the mailbox "INBOX" are created (if not already present) and the values set as specified.
在上面的示例中，将创建邮箱“收件箱”的“/private/comment”和“/shared/comment”条目（如果尚未存在），并按指定设置值。
Example:
例子：
C: a SETMETADATA INBOX (/private/comment "My new comment")
S: a NO [METADATA TOOMANY] SETMETADATA failed
C: a SETMETADATA INBOX (/private/comment "My new comment")
S: a NO [METADATA TOOMANY] SETMETADATA failed
In the above example, the server is unable to set the requested (new) annotation as it has reached the limit on the number of annotations it can support on the specified mailbox.
在上面的示例中，服务器无法设置请求的（新）批注，因为它已达到指定邮箱上可支持的批注数量限制。
The METADATA response displays results of a GETMETADATA command, or can be returned as an unsolicited response at any time by the server in response to a change in a server or mailbox annotation.
元数据响应显示GETMETADATA命令的结果，或者服务器可以随时作为未经请求的响应返回，以响应服务器或邮箱批注中的更改。
When unsolicited responses are activated by the ENABLE [RFC5161] command for this extension, servers MUST send unsolicited METADATA responses if server or mailbox annotations are changed by a third-party, allowing servers to keep clients updated with changes.
当此扩展的ENABLE[RFC5161]命令激活未经请求的响应时，如果第三方更改了服务器或邮箱批注，则服务器必须发送未经请求的元数据响应，从而允许服务器使用更改来更新客户端。
Unsolicited METADATA responses MUST only contain entry names, not the values. If the client wants to update any cached values, it must explicitly retrieve those using a GETMETADATA command.
未经请求的元数据响应只能包含条目名称，而不能包含值。如果客户端想要更新任何缓存的值，它必须使用GETMETADATA命令显式地检索这些值。
The METADATA response can contain multiple entries in a single response, but the server is free to return multiple responses for each entry or group of entries, if it desires.
元数据响应可以在单个响应中包含多个条目，但如果需要，服务器可以为每个条目或条目组自由返回多个响应。
This response is only available in authenticated or selected state [RFC3501].
此响应仅在已验证或选定状态[RFC3501]下可用。
The response consists of a list of entry-value pairs.
响应由条目值对列表组成。
Example:
例子：
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "My comment")
S: a OK GETMETADATA complete
C: a GETMETADATA "" /shared/comment
S: * METADATA "" (/shared/comment "My comment")
S: a OK GETMETADATA complete
In the above example, a single entry with its value is returned by the server.
在上面的示例中，服务器返回一个条目及其值。
Example:
例子：
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment"
/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment"
/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
In the above example, two entries and their values are returned by the server.
在上面的示例中，服务器返回两个条目及其值。
Example:
例子：
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment")
S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
C: a GETMETADATA "INBOX" /private/comment /shared/comment
S: * METADATA "INBOX" (/private/comment "My comment")
S: * METADATA "INBOX" (/shared/comment "Its sunny outside!")
S: a OK GETMETADATA complete
In the above example, the server returns two separate responses for each of the two entries requested.
在上面的示例中，服务器为请求的两个条目中的每一个返回两个单独的响应。
The response consists of a list of entries, each of which have changed on the server or mailbox.
响应由条目列表组成，每个条目在服务器或邮箱上都已更改。
Example:
例子：
C: a NOOP
S: * METADATA "" /shared/comment
S: a OK NOOP complete
C: a NOOP
S: * METADATA "" /shared/comment
S: a OK NOOP complete
In the above example, the server indicates that the "/shared/ comment" server entry has been changed.
在上面的示例中，服务器表示“/shared/comment”服务器条目已更改。
Example:
例子：
C: a NOOP
S: * METADATA "INBOX" /shared/comment /private/comment
S: a OK NOOP complete
C: a NOOP
S: * METADATA "INBOX" /shared/comment /private/comment
S: a OK NOOP complete
In the above example, the server indicates a change to two mailbox entries.
在上面的示例中，服务器指示对两个邮箱条目进行更改。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
以下语法规范使用[RFC5234]中指定的增广巴科斯诺尔形式（ABNF）表示法。
Non-terminals referenced but not defined below are as defined by [RFC3501], with the new definitions in [RFC4466] superseding those in [RFC3501].
以下引用但未定义的非端子由[RFC3501]定义，其中[RFC4466]中的新定义取代了[RFC3501]中的定义。
Except as noted otherwise, all alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
capability =/ "METADATA" / "METADATA-SERVER"
; defines the capabilities for this extension.
capability =/ "METADATA" / "METADATA-SERVER"
; defines the capabilities for this extension.
command-auth =/ setmetadata / getmetadata
; adds to original IMAP command
command-auth =/ setmetadata / getmetadata
; adds to original IMAP command
entries = entry /
"(" entry *(SP entry) ")"
; entry specifiers
entries = entry /
"(" entry *(SP entry) ")"
; entry specifiers
entry = astring ; slash-separated path to entry ; MUST NOT contain "*" or "%"
进入=收缩；斜线分隔的进入路径；不得包含“*”或“%”
entry-value = entry SP value
entry-value = entry SP value
entry-values = "(" entry-value *(SP entry-value) ")"
entry-values = "(" entry-value *(SP entry-value) ")"
entry-list = entry *(SP entry) ; list of entries used in unsolicited ; METADATA response
条目列表=条目*（SP条目）；非邀请函中使用的条目列表；元数据响应
getmetadata = "GETMETADATA" [SP getmetadata-options] SP mailbox SP entries ; empty string for mailbox implies ; server annotation.
getmetadata=“getmetadata”[SP getmetadata选项]SP邮箱SP条目；邮箱提示为空字符串；服务器注释。
getmetadata-options = "(" getmetadata-option *(SP getmetadata-option) ")"
getmetadata options=“（“getmetadata选项*（SP getmetadata选项）”）
getmetadata-option = tagged-ext-label [SP tagged-ext-val] ; tagged-ext-label and tagged-ext-val ; are defined in [RFC4466].
getmetadata选项=标记的外部标签[SP标记的外部值]；标记的ext标签和标记的ext val；在[RFC4466]中定义。
maxsize-opt = "MAXSIZE" SP number ; Used as a getmetadata-option
maxsize opt=“maxsize”SP编号；用作getmetadata选项
metadata-resp = "METADATA" SP mailbox SP (entry-values / entry-list) ; empty string for mailbox implies ; server annotation.
metadata resp=“metadata”SP邮箱SP（条目值/条目列表）；邮箱提示为空字符串；服务器注释。
response-payload =/ metadata-resp ; adds to original IMAP data responses
响应负载=/metadata resp；添加到原始IMAP数据响应中
resp-text-code =/ "METADATA" SP "LONGENTRIES" SP number ; new response codes for GETMETADATA
resp文本代码=/“METADATA”SP“LONGENTRIES”SP编号；GETMETADATA的新响应代码
resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number /
"TOOMANY" / "NOPRIVATE")
; new response codes for SETMETADATA
; failures
resp-text-code =/ "METADATA" SP ("MAXSIZE" SP number /
"TOOMANY" / "NOPRIVATE")
; new response codes for SETMETADATA
; failures
scope-opt = "DEPTH" SP ("0" / "1" / "infinity")
; Used as a getmetadata-option
scope-opt = "DEPTH" SP ("0" / "1" / "infinity")
; Used as a getmetadata-option
setmetadata = "SETMETADATA" SP mailbox SP entry-values ; empty string for mailbox implies ; server annotation.
setmetadata=“setmetadata”SP邮箱SP条目值；邮箱提示为空字符串；服务器注释。
value = nstring / literal8
value = nstring / literal8
All entries MUST have either "/shared" or "/private" as a prefix. Entry names MUST be specified in a Standards Track or IESG-approved Experimental RFC, or fall under the vendor namespace (i.e., use /shared/vendor/<vendor-token> or /private/vendor/<vendor-token> as the prefix).
所有条目的前缀必须为“/shared”或“/private”。条目名称必须在标准跟踪或IESG批准的实验RFC中指定，或归入供应商名称空间（即使用/shared/vendor/<vendor token>或/private/vendor/<vendor token>作为前缀）。
Each entry registration MUST include a content-type that is used to indicate the nature of the annotation value. Where applicable, a charset parameter MUST be included with the content-type.
每个条目注册必须包括用于指示注释值性质的内容类型。如果适用，内容类型中必须包含字符集参数。
To: iana@iana.org Subject: IMAP METADATA Entry Registration
致：iana@iana.org主题：IMAP元数据条目注册
Type: [Either "Mailbox" or "Server"]
类型：[邮箱或服务器]
Name: [the name of the entry]
名称：[条目的名称]
Description: [a description of what the entry is for]
Description:[对条目用途的描述]
Content-type: [MIME Content-Type and charset for the entry value]
内容类型：[输入值的MIME内容类型和字符集]
RFC Number: [for entries published as RFCs]
RFC编号：[对于发布为RFC的条目]
Contact: [email and/or physical address to contact for additional information]
联系人：[有关更多信息，请发送电子邮件和/或实际联系地址]
The following templates specify the IANA registrations of annotation entries specified in this document.
以下模板指定了本文档中指定的注释条目的IANA注册。
To: iana@iana.org Subject: IMAP METADATA Entry Registration
致：iana@iana.org主题：IMAP元数据条目注册
Type: Server
类型：服务器
Name: /shared/comment
Name: /shared/comment
Description: Defines a comment or note that is associated with the server and that is shared with authorized users of the server.
描述：定义与服务器关联并与服务器授权用户共享的注释或注释。
Content-type: text/plain; charset=utf-8
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC编号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
To: iana@iana.org Subject: IMAP METADATA Entry Registration
致：iana@iana.org主题：IMAP元数据条目注册
Type: Server
类型：服务器
Name: /shared/admin
Name: /shared/admin
Description: Indicates a method for contacting the server administrator. The value MUST be a URI (e.g., a mailto: or tel: URL). This entry is always read-only -- clients cannot change it. It is visible to authorized users of the system.
描述：表示联系服务器管理员的方法。该值必须是URI（例如，mailto:或tel:URL）。此条目始终是只读的--客户端无法更改它。它对系统的授权用户可见。
Content-type: text/plain; charset=utf-8
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC编号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
The following templates specify the IANA registrations of annotation entries specified in this document.
以下模板指定了本文档中指定的注释条目的IANA注册。
To: iana@iana.org Subject: IMAP METADATA Entry Registration
致：iana@iana.org主题：IMAP元数据条目注册
Type: Mailbox
类型：邮箱
Name: /shared/comment
Name: /shared/comment
Description: Defines a shared comment or note associated with a mailbox.
描述：定义与邮箱关联的共享注释或便笺。
Content-type: text/plain; charset=utf-8
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC编号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
To: iana@iana.org Subject: IMAP METADATA Entry Registration
致：iana@iana.org主题：IMAP元数据条目注册
Type: Mailbox
类型：邮箱
Name: /private/comment
Name: /private/comment
Description: Defines a private comment or note associated with a mailbox.
描述：定义与邮箱关联的专用注释或便笺。
Content-type: text/plain; charset=utf-8
Content-type: text/plain; charset=utf-8
RFC Number: RFC 5464
RFC编号：RFC 5464
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
Contact: IMAP Extensions mailto:ietf-imapext@imc.org
The security considerations in Section 11 of [RFC3501] apply here with respect to protecting annotations from snooping. Servers MAY choose to only support the METADATA and/or METADATA-SERVER extensions after a privacy layer has been negotiated by the client.
[RFC3501]第11节中的安全注意事项适用于保护注释免受窥探。在客户端协商隐私层后，服务器可以选择仅支持元数据和/或元数据服务器扩展。
Annotations can contain arbitrary data of varying size. As such, servers MUST ensure that size limits are enforced to prevent a user from using up all available space on a server and preventing use by others. Clients MUST treat annotation data values as an "untrusted" source of data as it is possible for it to contain malicious content.
批注可以包含大小不同的任意数据。因此，服务器必须确保实施大小限制，以防止用户耗尽服务器上的所有可用空间，并防止其他人使用。客户端必须将批注数据值视为“不受信任”的数据源，因为它可能包含恶意内容。
Annotations whose values are intended to remain private MUST be stored only in entries that have the "/private" prefix on the entry name.
其值旨在保持私有的注释必须仅存储在条目名称上具有“/private”前缀的条目中。
Excluding the above issues, the METADATA extension does not raise any security considerations that are not present in the base IMAP protocol, and these issues are discussed in [RFC3501].
除上述问题外，元数据扩展不会引起基本IMAP协议中不存在的任何安全注意事项，这些问题将在[RFC3501]中讨论。
[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月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC2244，1997年11月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.
[RFC4314]Melnikov，A.，“IMAP4访问控制列表（ACL）扩展”，RFC 4314，2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[RFC4466]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC4466，2006年4月。
[RFC5161] Gulbrandsen, A. and A. Melnikov, "The IMAP ENABLE Extension", RFC 5161, March 2008.
[RFC5161]Gulbrandsen，A.和A.Melnikov，“IMAP启用扩展”，RFC 51612008年3月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
The ideas expressed in this document are based on the message annotation document that was co-authored by Randall Gellens. The author would like to thank the following individuals for contributing their ideas and support for writing this specification: Dave Cridland, Arnt Gulbrandsen, Dan Karp, Alexey Melnikov, Ken Murchison, Chris Newman, and Michael Wener.
本文档中表达的想法基于Randall Gellens合著的消息注释文档。作者要感谢以下个人为编写本规范贡献了他们的想法和支持：Dave Cridland、Arnt Gulbrandsen、Dan Karp、Alexey Melnikov、Ken Murchison、Chris Newman和Michael Wener。
Author's Address
作者地址
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
Cyrus Daboo苹果公司，美国加利福尼亚州库珀蒂诺市无限环路1号，邮编95014
EMail: cyrus@daboo.name
URI: http://www.apple.com/
EMail: cyrus@daboo.name
URI: http://www.apple.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2009).
版权所有（C）IETF信托基金（2009年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.