Network Working Group C. Daboo
Request for Comments: 5257 Apple Inc.
Category: Experimental R. Gellens
QUALCOMM Incorporated
June 2008
Network Working Group C. Daboo
Request for Comments: 5257 Apple Inc.
Category: Experimental R. Gellens
QUALCOMM Incorporated
June 2008
Internet Message Access Protocol - ANNOTATE Extension
Internet消息访问协议-注释扩展
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
Internet邮件访问协议的注释扩展允许客户端和服务器维护存储在服务器邮箱中的邮件或单个邮件部分的“元数据”。例如，这可用于将注释和其他有用信息附加到消息。还可以将注释附加到消息的特定部分，例如，可以将注释标记为可见、重要或添加的注释。
Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.
请注意，本文件是一个工作组的成果，该工作组就如何处理该问题达成了良好的共识。然而，工作组认为，它没有足够的关于实施和部署障碍的信息来满足拟议标准的所有要求。IETF要求实施和实施报告，以取得进一步进展。
Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension.
实施者应该意识到，当进入提议的标准状态时，该规范可能会以不兼容的方式发生变化。但是，任何不兼容的更改都会导致使用新的功能名称来防止实验扩展的任何部署出现问题。
Table of Contents
目录
1. Introduction and Overview .......................................3
2. Conventions Used in This Document ...............................4
3. Data Model ......................................................4
3.1. Overview ...................................................4
3.2. Namespace of Entries and Attributes ........................4
3.2.1. Entry Names .........................................5
3.2.2. Attribute Names .....................................7
3.3. Private Versus Shared ......................................7
3.4. Access Control .............................................8
3.5. Access to Standard IMAP Flags and Keywords ................11
4. IMAP Protocol Changes ..........................................11
4.1. General Considerations ....................................11
4.2. ANNOTATE Parameter with the SELECT/EXAMINE Commands .......12
4.3. ANNOTATION Message Data Item in FETCH Command .............12
4.4. ANNOTATION Message Data Item in FETCH Response ............14
4.5. ANNOTATION Message Data Item in STORE .....................16
4.6. ANNOTATION Interaction with COPY ..........................18
4.7. ANNOTATION Message Data Item in APPEND ....................18
4.8. ANNOTATION Criterion in SEARCH ............................19
4.9. ANNOTATION Key in SORT ....................................20
4.10. New ACL Rights ...........................................21
5. Formal Syntax ..................................................21
6. IANA Considerations ............................................23
6.1. Entry and Attribute Registration Template .................23
6.2. Entry Registrations .......................................24
6.2.1. /comment ...........................................24
6.2.2. /flags .............................................24
6.2.3. /altsubject ........................................25
6.2.4. /<section-part>/comment ............................25
6.2.5. /<section-part>/flags/seen .........................26
6.2.6. /<section-part>/flags/answered .....................26
6.2.7. /<section-part>/flags/flagged ......................27
6.2.8. /<section-part>/flags/forwarded ....................27
6.3. Attribute Registrations ...................................28
6.3.1. value ..............................................28
6.3.2. size ...............................................28
6.4. Capability Registration ...................................28
7. Internationalization Considerations ............................29
8. Security Considerations ........................................29
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
10. Acknowledgments ...............................................30
1. Introduction and Overview .......................................3
2. Conventions Used in This Document ...............................4
3. Data Model ......................................................4
3.1. Overview ...................................................4
3.2. Namespace of Entries and Attributes ........................4
3.2.1. Entry Names .........................................5
3.2.2. Attribute Names .....................................7
3.3. Private Versus Shared ......................................7
3.4. Access Control .............................................8
3.5. Access to Standard IMAP Flags and Keywords ................11
4. IMAP Protocol Changes ..........................................11
4.1. General Considerations ....................................11
4.2. ANNOTATE Parameter with the SELECT/EXAMINE Commands .......12
4.3. ANNOTATION Message Data Item in FETCH Command .............12
4.4. ANNOTATION Message Data Item in FETCH Response ............14
4.5. ANNOTATION Message Data Item in STORE .....................16
4.6. ANNOTATION Interaction with COPY ..........................18
4.7. ANNOTATION Message Data Item in APPEND ....................18
4.8. ANNOTATION Criterion in SEARCH ............................19
4.9. ANNOTATION Key in SORT ....................................20
4.10. New ACL Rights ...........................................21
5. Formal Syntax ..................................................21
6. IANA Considerations ............................................23
6.1. Entry and Attribute Registration Template .................23
6.2. Entry Registrations .......................................24
6.2.1. /comment ...........................................24
6.2.2. /flags .............................................24
6.2.3. /altsubject ........................................25
6.2.4. /<section-part>/comment ............................25
6.2.5. /<section-part>/flags/seen .........................26
6.2.6. /<section-part>/flags/answered .....................26
6.2.7. /<section-part>/flags/flagged ......................27
6.2.8. /<section-part>/flags/forwarded ....................27
6.3. Attribute Registrations ...................................28
6.3.1. value ..............................................28
6.3.2. size ...............................................28
6.4. Capability Registration ...................................28
7. Internationalization Considerations ............................29
8. Security Considerations ........................................29
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
10. Acknowledgments ...............................................30
The ANNOTATE extension is present in any IMAP [RFC3501] implementation that returns "ANNOTATE-EXPERIMENT-1" as one of the supported capabilities in the CAPABILITY response.
注释扩展存在于任何IMAP[RFC3501]实现中，该实现将“ANNOTATE-experience-1”作为功能响应中支持的功能之一返回。
This extension makes the following changes to the IMAP protocol:
此扩展对IMAP协议进行以下更改：
a. adds a new ANNOTATION message data item for use in FETCH.
a. 添加新的注释消息数据项以用于获取。
b. adds a new ANNOTATION message data item for use in STORE.
b. 添加新的注释消息数据项以在存储中使用。
c. adds a new ANNOTATION search criterion for use in SEARCH.
c. 添加用于搜索的新注释搜索条件。
d. adds a new ANNOTATION sort key for use in the SORT extension.
d. 添加新的注释排序键以在排序扩展中使用。
e. adds a new ANNOTATION data item for use in APPEND.
e. 添加新的注释数据项以在追加中使用。
f. adds a new requirement on the COPY command.
f. 在“复制”命令上添加新要求。
g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE commands.
g. 添加一个新的注释参数，以便与选择/检查命令一起使用。
h. adds two new response codes to indicate store failures of annotations.
h. 添加两个新的响应代码以指示注释的存储失败。
i. adds a new untagged response code for the SELECT or EXAMINE commands to indicate the maximum sized annotation that can be stored.
i. 为“选择”或“检查”命令添加新的未标记响应代码，以指示可存储的最大注释大小。
j. adds a new Access Control List (ACL) "bit" for use with the ACL extensions [RFC2086] and [RFC4314].
j. 添加一个新的访问控制列表（ACL）“位”，用于ACL扩展[RFC2086]和[RFC4314]。
The data model used for the storage of annotations is based on the Application Configuration Access Protocol [RFC2244]. Note that there is no inheritance in annotations.
用于存储注释的数据模型基于应用程序配置访问协议[RFC2244]。请注意，注释中没有继承。
If a server supports annotations, then it MUST store all annotation data permanently, i.e., there is no concept of "session only" annotations that would correspond to the behavior of "session" flags as defined in the IMAP base specification.
如果服务器支持注释，那么它必须永久存储所有注释数据，即，不存在与IMAP基本规范中定义的“会话”标志行为相对应的“仅会话”注释的概念。
In order to provide optimum support for a disconnected client (one that needs to synchronize annotations for use when offline), servers SHOULD also support the Conditional STORE [RFC4551] extension.
为了为断开连接的客户机（需要同步注释以便脱机使用的客户机）提供最佳支持，服务器还应该支持条件存储[RFC4551]扩展。
The rest of this document describes the data model and protocol changes more rigorously.
本文档的其余部分更严格地描述了数据模型和协议更改。
The examples in this document use "C:" and "S:" to 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]中所述进行解释。
The data model for annotations in ANNOTATE uses a uniquely named entry that contains a set of standard attributes. Thus, a single coherent unit of "meta data" for a message is stored as a single entry, made up of several attributes.
ANNOTATE中注释的数据模型使用唯一命名的条目，该条目包含一组标准属性。因此，消息的单个连贯“元数据”单元存储为单个条目，由多个属性组成。
For example, a comment annotation added to a message has an entry name of "/comment". This entry is composed of several attributes such as "value", "size", etc., that contain the properties and data of the entry.
例如，添加到消息的注释注释的条目名称为“/comment”。此条目由几个属性组成，如“值”、“大小”等，这些属性包含条目的属性和数据。
The protocol changes to IMAP, described below, allow a client to access or change the values of any attribute in any entry in a message annotation, assuming it has sufficient access rights to do so (see Section 3.4 for specifics).
下面描述的IMAP协议更改允许客户端访问或更改消息批注中任何条目中任何属性的值，前提是客户端具有足够的访问权限（有关详细信息，请参阅第3.4节）。
A message may contain zero or more annotations, each of which is a single uniquely named entry. Each entry 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.
消息可能包含零个或多个注释，每个注释都是一个唯一命名的条目。每个条目都有一个层次名称，名称的每个组成部分用斜杠（“/”）分隔。条目名称不得包含两个连续的“/”字符，且不得以“/”字符结尾。
Each entry is made up of a set of attributes. Each attribute has a hierarchical name, with each component of the name separated by a period ("."). An attribute name MUST NOT contain two consecutive "." characters and MUST NOT end with a "." character.
每个条目由一组属性组成。每个属性都有一个层次名称，名称的每个组成部分都用句点（“.”）分隔。属性名称不得包含两个连续的“.”字符，且不得以“.”字符结尾。
The value of an attribute is "NIL" (has no value), or is a string of zero or more octets.
属性的值为“NIL”（无值），或者是由零个或多个八位字节组成的字符串。
Entry and attribute names MUST NOT contain asterisk ("*") or percent ("%") characters, and MUST NOT contain non-ASCII characters or the NULL octet. Invalid entry or attribute names result in a BAD response in any IMAP commands where they are used.
条目和属性名称不得包含星号（“*”）或百分比（“%”）字符，且不得包含非ASCII字符或空八位字节。无效的条目或属性名称会导致在使用它们的任何IMAP命令中出现错误响应。
Attribute names MUST NOT contain any hierarchical components with the names "priv" or "shared", as those have special meaning (see Section 3.3).
属性名称不得包含名称为“priv”或“shared”的任何层次结构组件，因为这些组件具有特殊含义（见第3.3节）。
Entry and attribute names are case-sensitive.
条目和属性名称区分大小写。
Use of control or punctuation characters in entry and attribute names is strongly discouraged.
强烈反对在条目和属性名称中使用控件或标点符号。
This specification defines an initial set of entry and attribute names available for use in message annotations. In addition, an extension mechanism is described to allow additional names to be added as needed.
此规范定义了一组初始条目和属性名称，可用于消息注释。此外，还描述了一种扩展机制，允许根据需要添加其他名称。
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节。
/ Defines the top-level of entries associated with an entire message. This entry itself does not contain any attributes. All entries that start with a numeric character ("0" - "9") refer to an annotation on a specific body part. All other entries are for annotations on the entire message.
/定义与整个邮件关联的顶级条目。此条目本身不包含任何属性。所有以数字字符（“0”-“9”）开头的条目都引用特定身体部位上的注释。所有其他条目用于整个消息上的注释。
/comment Defines a comment or note associated with an entire message.
/comment定义与整个消息关联的注释或注释。
/flags This entry hierarchy is reserved for future use.
/标记此条目层次结构保留供将来使用。
/altsubject Contains text supplied by the message recipient to be used by the client, instead of the original message Subject.
/altsubject包含由邮件收件人提供的文本，供客户端使用，而不是原始邮件主题。
/vendor/<vendor-token> Defines the top-level of entries associated with an entire message as created by a particular product of some vendor. These sub-entries can be used by vendors to provide client-specific annotations. The vendor-token MUST be registered with IANA, using the [RFC2244] vendor subtree registry.
/vendor/<vendor token>定义与某个供应商的特定产品创建的整个消息相关联的顶级条目。供应商可以使用这些子条目来提供特定于客户端的注释。供应商令牌必须使用[RFC2244]供应商子树注册表向IANA注册。
/<section-part> Defines the top-level of entries associated with a specific body part of a message. This entry itself does not contain any attributes. The section-part is a numeric part specifier. Its
/<section part>定义与消息的特定正文部分关联的顶级条目。此条目本身不包含任何属性。截面零件是数字零件说明符。它的
syntax is the same as the section-part ABNF element defined in [RFC3501]. The server MUST return a BAD response if the client uses an incorrect part specifier (either incorrect syntax or a specifier referring to a non-existent part). The server MUST return a BAD response if the client uses an empty part specifier (which is used in IMAP to represent the entire message).
语法与[RFC3501]中定义的部分ABNF元素相同。如果客户端使用不正确的部分说明符（语法不正确或说明符引用不存在的部分），服务器必须返回错误响应。如果客户端使用空部分说明符（在IMAP中用于表示整个消息），则服务器必须返回错误响应。
/<section-part>/comment Defines a comment or note associated with a specific body part of a message.
/<section part>/comment定义与消息的特定正文部分关联的注释或注释。
/<section-part>/flags Defines the top-level of entries associated with the flag state for a specific body part of a message. All sub-entries are maintained entirely by the client. There is no implicit change to any flag by the server.
/<section part>/flags定义与消息特定正文部分的标志状态相关联的顶级条目。所有子条目完全由客户机维护。服务器没有对任何标志进行隐式更改。
/<section-part>/flags/seen This is similar to the IMAP \Seen flag, except it applies to only the body part referenced by the entry.
/<section part>/flags/seen这与IMAP\seen标志类似，只是它仅适用于条目引用的身体部位。
/<section-part>/flags/answered This is similar to the IMAP \Answered flag, except it applies to only the body part referenced by the entry.
/<section part>/flags/answered这与IMAP\answered标志类似，只是它仅适用于条目引用的身体部位。
/<section-part>/flags/flagged This is similar to the IMAP \Flagged flag, except it applies to only the body part referenced by the entry.
/<section part>/flags/flagged这与IMAP\flagged标志类似，只是它仅适用于条目引用的身体部位。
/<section-part>/flags/forwarded This is similar to the IMAP $Forwarded keyword, except it applies to only the body part referenced by the entry.
/<section part>/flags/forwarded这与IMAP$forwarded关键字类似，只是它仅适用于条目引用的主体部分。
Defines flags for a specific body part of a message. The "value" attribute of each of the entries described above must be either "1", "0", or "NIL". "1" corresponds to the flag being set.
为消息的特定正文部分定义标志。上述每个条目的“value”属性必须为“1”、“0”或“NIL”。“1”对应于正在设置的标志。
/<section-part>/vendor/<vendor-token> Defines the top-level of entries associated with a specific body part of a message 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.
/<section part>/vendor/<vendor token>定义与某个供应商的特定产品创建的消息的特定正文部分相关联的顶级条目。供应商可以使用此条目提供特定于客户端的注释。供应商令牌必须向IANA注册。
Attribute names MUST be specified in a standards track or IESG approved experimental RFC. See Section 6.1 for the registration template.
属性名称必须在标准跟踪或IESG批准的实验RFC中指定。注册模板见第6.1节。
All attribute names implicitly have a ".priv" and a ".shared" suffix that maps to private and shared versions of the entry. Searching or fetching without using either suffix will include both. The client MUST specify either a ".priv" or ".shared" suffix when storing an annotation or sorting on annotations.
所有属性名称都隐式地具有一个“.priv”和一个“.shared”后缀，该后缀映射到条目的私有和共享版本。不使用任何后缀的搜索或获取将同时包含这两个后缀。在存储批注或对批注进行排序时，客户端必须指定“.priv”或“.shared”后缀。
value A string or binary data representing the value of the annotation. To delete an annotation, the client can store "NIL" into the value. If the client requests the value attribute for a non-existent entry, then the server MUST return "NIL" for the value. The content represented by the string is determined by the content-type used to register the entry (see Section 6.1 for entry registration templates). Where applicable, the registered content-type MUST include a charset parameter. Text values SHOULD use the utf-8 [RFC3629] character set. Note that binary data (data which may contain the NULL octet) is allowed (e.g., for storing images), and this extension uses the "literal8" syntax element [RFC4466] to allow such data to be written to or read from the server.
值表示注释值的字符串或二进制数据。要删除注释，客户端可以将“NIL”存储到值中。如果客户端为不存在的条目请求value属性，那么服务器必须为该值返回“NIL”。字符串表示的内容由用于注册条目的内容类型决定（条目注册模板见第6.1节）。如果适用，注册的内容类型必须包括字符集参数。文本值应使用utf-8[RFC3629]字符集。请注意，允许使用二进制数据（可能包含空八位字节的数据）（例如，用于存储图像），此扩展使用“literal8”语法元素[RFC4466]允许将此类数据写入服务器或从服务器读取。
size The size of the value, in octets. Set automatically by the server, read-only to clients. If the client requests the size attribute for a non-existent entry, then the server MUST return "0" (zero) for the size.
大小值的大小，以八位字节为单位。由服务器自动设置，对客户端为只读。如果客户端为不存在的条目请求size属性，那么服务器必须为该大小返回“0”（零）。
Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an ACL [RFC4314] that permits access by other users, or because it is a shared mailbox.
某些IMAP邮箱是专用的，只能由所属用户访问。其他邮箱不是，这可能是因为所有者设置了允许其他用户访问的ACL[RFC4314]，也可能是因为它是共享邮箱。
This raises the issue of shared versus private annotations.
这就提出了共享注释与私有注释的问题。
If all annotations are private, it is then impossible to have annotations in a shared or otherwise non-private mailbox be visible to other users. This eliminates what could be a useful aspect of annotations in a shared environment. An example of such use is a shared IMAP folder containing bug reports. Engineers may want to use
如果所有批注都是私有的，那么其他用户就不可能看到共享或非私有邮箱中的批注。这消除了共享环境中注释的有用方面。此类使用的一个示例是包含bug报告的共享IMAP文件夹。工程师可能希望使用
annotations to add information to existing messages, indicate assignments, status, etc. This use requires shared annotations.
注释，用于向现有消息添加信息、指示分配、状态等。此用途需要共享注释。
If all annotations are shared, it is impossible to use annotations for private notes on messages in shared mailboxes. Also, modifying an ACL to permit access to a mailbox by other users may unintentionally expose private information.
如果所有批注都是共享的，则无法对共享邮箱中的邮件使用专用批注。此外，修改ACL以允许其他用户访问邮箱可能会无意中公开私人信息。
There are also situations in which both shared and private annotations are useful. For example, an administrator may want to set shared annotations on messages in a shared folder, which individual users may wish to supplement with additional notes.
在某些情况下，共享注释和私有注释都很有用。例如，管理员可能希望在共享文件夹中的邮件上设置共享注释，个别用户可能希望用其他注释来补充这些注释。
If shared and private annotations are to coexist, we need a clear way to differentiate them. Also, it should be as easy as possible for a client to access both and not overlook either. There is also a danger in allowing a client to store an annotation without knowing if it is shared or private.
如果共享注释和私有注释要共存，我们需要一种明确的方法来区分它们。此外，客户机应该尽可能容易地访问这两个方面，而不要忽略这两个方面。允许客户端在不知道注释是共享的还是私有的情况下存储注释也存在危险。
This document proposes two standard suffixes for all attributes: ".shared" and ".priv". A SEARCH or FETCH command that specifies neither, uses both. STORE, APPEND, and SORT commands MUST explicitly use ".priv" or ".shared" suffixes.
本文档为所有属性提供了两个标准后缀：“.shared”和“.priv”。既不指定也不指定的搜索或获取命令将同时使用两者。存储、追加和排序命令必须显式使用“.priv”或“.shared”后缀。
If the ANNOTATE extension is present, support for shared annotations in servers is REQUIRED, while support for private annotations in servers is OPTIONAL. This recognizes the fact that support for private annotations may introduce a significant increase in complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations, etc. Clients that support the ANNOTATE extension MUST handle both shared and private annotations.
如果存在注释扩展，则需要在服务器中支持共享注释，而在服务器中支持私有注释是可选的。这承认了这样一个事实，即对私有注释的支持可能会使服务器在跟踪注释所有权、如何根据用户自己的注释确定配额等方面的复杂性显著增加。支持注释扩展的客户端必须同时处理共享注释和私有注释。
A user needs to have appropriate rights in order to read or write ".priv" or ".shared" annotation values. How those rights are calculated depends on whether or not the ACL [RFC2086] extension or its update [RFC4314] is present. If a client attempts to store or fetch an annotation to which they do not have the appropriate rights, the server MUST respond with a NO response.
用户需要具有适当的权限才能读取或写入“.priv”或“.shared”注释值。这些权限的计算方式取决于是否存在ACL[RFC2086]扩展或其更新[RFC4314]。如果客户机试图存储或获取他们没有相应权限的批注，则服务器必须以“无响应”响应。
When the ACL extension is not present, access to annotation values is governed by the nature of the selected state, in particular whether the mailbox was SELECTED or EXAMINED in READ-ONLY or READ-WRITE mode.
当ACL扩展不存在时，对注释值的访问由所选状态的性质决定，特别是邮箱是以只读还是读写模式选择或检查的。
When the ACL extension is present, the server MUST recognize the new ACL "n" right, in addition to the ones defined by the ACL extension itself.
当存在ACL扩展时，除了ACL扩展本身定义的ACL外，服务器还必须正确识别新的ACL“n”。
For ".priv" annotation values, the "r" right controls both read and write access. When it is on, access to ".priv" annotations is allowed; when it is off, access to ".priv" annotations is disallowed.
对于“.priv”注释值，“r”右侧控制读写访问。打开时，允许访问“.priv”注释；禁用时，不允许访问“.priv”批注。
For ".shared" annotation values, the "r" right controls read access. When it is on, ".shared" annotations can be read; when it is off, ".shared" annotations cannot be read.
对于“.shared”注释值，“r”右侧控制读取访问。打开时，可以读取“.shared”注释；禁用时，无法读取“.shared”批注。
For ".shared" annotation values, the "n" right controls write access. When it is on, ".shared" annotations can be changed or created through either a STORE or APPEND command; when it is off, ".shared" annotations cannot be changed or created. The "n" right constitutes a "shared flag right" as defined in Section 6.2 of [RFC4314].
对于“.shared”注释值，“n”右侧控制写访问。打开时，可以通过STORE或APPEND命令更改或创建“.shared”注释；禁用该选项后，无法更改或创建“.shared”批注。“n”权利构成[RFC4314]第6.2节中定义的“共享标志权利”。
A summary of all the access control restrictions is tabulated below
所有访问控制限制汇总如下表所示
+---------------+---------------+-----------------------------------+
| Server Type | Action on | Type of mailbox |
| | annotation | |
+===============+===============+===================================+
| | | |
| | read .priv | Any mailbox that can be SELECTED |
| | values | or EXAMINED. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .priv | Any SELECTED [READ-WRITE] mailbox.|
| | values | SELECTED [READ-ONLY] mailboxes MAY|
| Server | | also permit writes. |
| without | | |
| ACL Extension +---------------+-----------------------------------+
| | | |
| | read .shared | Any mailbox that can be SELECTED |
| | values | or EXAMINED. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .shared | Any mailbox that can be SELECTED |
| | values | or EXAMINED and is [READ-WRITE]. |
| | | |
+---------------+---------------+-----------------------------------+
| | | |
| | read .priv | Any mailbox with the "r" |
| | values | ACL right. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .priv | Any mailbox with the "r" |
| Server | values | ACL right. |
| with | | |
| ACL Extension +---------------+-----------------------------------+
| | | |
| | read .shared | Any mailbox with the "r" |
| | values | ACL right. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .shared | Any mailbox with the "n" |
| | values | ACL right. |
| | | |
+---------------+---------------+-----------------------------------+
+---------------+---------------+-----------------------------------+
| Server Type | Action on | Type of mailbox |
| | annotation | |
+===============+===============+===================================+
| | | |
| | read .priv | Any mailbox that can be SELECTED |
| | values | or EXAMINED. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .priv | Any SELECTED [READ-WRITE] mailbox.|
| | values | SELECTED [READ-ONLY] mailboxes MAY|
| Server | | also permit writes. |
| without | | |
| ACL Extension +---------------+-----------------------------------+
| | | |
| | read .shared | Any mailbox that can be SELECTED |
| | values | or EXAMINED. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .shared | Any mailbox that can be SELECTED |
| | values | or EXAMINED and is [READ-WRITE]. |
| | | |
+---------------+---------------+-----------------------------------+
| | | |
| | read .priv | Any mailbox with the "r" |
| | values | ACL right. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .priv | Any mailbox with the "r" |
| Server | values | ACL right. |
| with | | |
| ACL Extension +---------------+-----------------------------------+
| | | |
| | read .shared | Any mailbox with the "r" |
| | values | ACL right. |
| | | |
| +---------------+-----------------------------------+
| | | |
| | write .shared | Any mailbox with the "n" |
| | values | ACL right. |
| | | |
+---------------+---------------+-----------------------------------+
Due to the ambiguity of how private and shared values would map to the base IMAP flag and keyword values, the ANNOTATE extension does not expose IMAP flags or keywords as entries. However, the /flags annotation entry is reserved for future use and MUST NOT be used by clients or servers supporting this extension.
由于私有值和共享值映射到基本IMAP标志和关键字值的方式不明确，注释扩展不将IMAP标志或关键字作为条目公开。但是，/flags注释项保留供将来使用，支持此扩展的客户端或服务器不得使用。
Clients that need to implement shared and private "flags" can create their own annotation entries for those, completely bypassing the base IMAP flag/keyword behavior.
需要实现共享和私有“标志”的客户端可以为它们创建自己的注释条目，完全绕过基本IMAP标志/关键字行为。
Servers may be able to offer only a limited level of support for annotations in mailboxes, and it is useful for clients to be able to know what level of support is available. Servers MUST return an ANNOTATIONS response code during the SELECT or EXAMINE command for a mailbox to indicate the level of support. Possible data items used with the ANNOTATIONS response code are:
服务器可能只能为邮箱中的批注提供有限级别的支持，客户机能够了解可用的支持级别非常有用。服务器必须在对邮箱执行SELECT或EXAMINE命令期间返回注释响应代码，以指示支持级别。与注释响应代码一起使用的可能数据项包括：
"NONE" - this indicates that the mailbox being selected does not support annotations at all. Clients MUST NOT attempt to use annotation extensions in commands for this mailbox.
“无”-这表示所选邮箱根本不支持批注。客户端不得尝试在此邮箱的命令中使用批注扩展。
"READ-ONLY" - this indicates that the annotations supported by the mailbox cannot be changed by the client. Clients MUST NOT attempt to store annotations on any messages in a mailbox with this response code.
“只读”-这表示客户端无法更改邮箱支持的批注。客户端不得尝试在具有此响应代码的邮箱中的任何邮件上存储批注。
"NOPRIVATE" - this indicates that the server does not support private annotations on the mailbox. Only shared annotations are supported. Clients SHOULD only attempt to read or store annotations attributes with the ".shared" suffix. If a client uses an attribute with the ".priv" suffix in a FETCH command, then servers should return the attribute value in the FETCH response as "NIL". If a client uses an attribute with the ".priv" suffix in a STORE command (or an APPEND command targeted at the mailbox), then the server MUST return a NO response.
“NOPRIVATE”-这表示服务器不支持邮箱上的专用批注。仅支持共享注释。客户端应仅尝试读取或存储后缀为“.shared”的批注属性。如果客户机在FETCH命令中使用后缀为“.priv”的属性，则服务器应在FETCH响应中将属性值返回为“NIL”。如果客户端在STORE命令（或针对邮箱的APPEND命令）中使用后缀为“.priv”的属性，则服务器必须返回NO响应。
numeric values - if servers support writable annotations, then the server MUST indicate the maximum size in octets for an annotation value by providing the maximum size value in the response code. Clients MUST NOT store annotation values of a size greater than the amount indicated by the server. Servers MUST accept a minimum
数值-如果服务器支持可写批注，则服务器必须通过在响应代码中提供最大大小值来指示批注值的最大大小（以八位字节为单位）。客户端存储的注释值不得大于服务器指示的值。服务器必须接受一个最小值
annotation data size of at least 1024 octets if annotations can be written.
如果可以写入批注，则批注数据大小至少为1024个八位字节。
In addition, the server MAY limit the total number of annotations for a single message. However, the server MUST provide a minimum annotation count per message of at least 10.
此外，服务器可能会限制单个消息的注释总数。但是，服务器必须为每条消息提供至少10的最小批注计数。
The ANNOTATE extension defines a single optional SELECT parameter [RFC4466] "ANNOTATE", which is used to turn on unsolicited responses for annotations as described in Section 4.4. This optional parameter results in a per-mailbox state change, i.e., it must be used in each SELECT/EXAMINE command in order to be effective, irrespective of whether it was used in a previous SELECT/EXAMINE during the same session.
ANNOTATE扩展定义了一个可选的选择参数[RFC4466]“ANNOTATE”，如第4.4节所述，该参数用于打开注释的非请求响应。此可选参数会导致每个邮箱状态的更改，即，无论是否在同一会话期间的上一次选择/检查中使用，都必须在每个选择/检查命令中使用此参数才能生效。
Example:
例子：
C: a SELECT INBOX (ANNOTATE)
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)]
S: * 10268 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 10268]
S: * OK [UIDVALIDITY 890061587]
S: * OK [UIDNEXT 34643]
S: * OK [ANNOTATIONS 20480 NOPRIVATE]
S: a OK [READ-WRITE] Completed
C: a SELECT INBOX (ANNOTATE)
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)]
S: * 10268 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 10268]
S: * OK [UIDVALIDITY 890061587]
S: * OK [UIDNEXT 34643]
S: * OK [ANNOTATIONS 20480 NOPRIVATE]
S: a OK [READ-WRITE] Completed
In the above example, a SELECT command with the ANNOTATE parameter is issued. The response from the server includes the required ANNOTATIONS response that indicates that the server supports annotations up to a maximum size of 20480 octets, and does not support private annotations (only shared).
在上面的示例中，将发出带有注释参数的SELECT命令。来自服务器的响应包括所需的注释响应，该响应指示服务器支持最大大小为20480个八位字节的注释，并且不支持私有注释（仅共享）。
This extension adds an ANNOTATION message data item to the FETCH command. This allows clients to retrieve annotations for a range of messages in the currently selected mailbox.
此扩展将注释消息数据项添加到FETCH命令中。这允许客户端检索当前选定邮箱中一系列邮件的批注。
ANNOTATION <entry-specifier> <attribute-specifier>
ANNOTATION <entry-specifier> <attribute-specifier>
The ANNOTATION message data item, when used by the client in the FETCH command, takes an entry specifier and an attribute specifier.
当客户端在FETCH命令中使用注释消息数据项时，该数据项采用条目说明符和属性说明符。
Example:
例子：
C: a FETCH 1 (ANNOTATION (/comment value))
S: * 1 FETCH (ANNOTATION (/comment
(value.priv "My comment"
value.shared "Group note")))
S: a OK Fetch complete
C: a FETCH 1 (ANNOTATION (/comment value))
S: * 1 FETCH (ANNOTATION (/comment
(value.priv "My comment"
value.shared "Group note")))
S: a OK Fetch complete
In the above example, the content of the "value" attribute for the "/comment" entry is requested by the client and returned by the server. Since neither ".shared" nor ".priv" was specified, both are returned.
在上面的示例中，“/comment”条目的“value”属性的内容由客户机请求并由服务器返回。由于既没有指定“.shared”也没有指定“.priv”，因此都会返回。
"*" and "%" wild card characters can be used in entry specifiers to match one or more characters at that position, with the exception that "%" does not match the "/" hierarchy delimiter. Thus, an entry specifier of "/%" matches entries such as "/comment" and "/altsubject", but not "/1/comment".
条目说明符中可以使用“*”和“%”通配符来匹配该位置的一个或多个字符，但“%”与“/”层次分隔符不匹配的情况除外。因此，“%”的条目说明符匹配“/comment”和“/altsubject”等条目，但不匹配“/1/comment”。
Example:
例子：
C: a UID FETCH 1123 (UID ANNOTATION
(/* (value.priv size.priv)))
S: * 12 FETCH (UID 1123 ANNOTATION
(/comment (value.priv "My comment"
size.priv "10")
/altsubject (value.priv "Rhinoceroses!"
size.priv "13")
/vendor/foobar/label.priv
(value.priv "label43"
size.priv "7")
/vendor/foobar/personality
(value.priv "Tallulah Bankhead"
size.priv "17")))
S: a OK Fetch complete
C: a UID FETCH 1123 (UID ANNOTATION
(/* (value.priv size.priv)))
S: * 12 FETCH (UID 1123 ANNOTATION
(/comment (value.priv "My comment"
size.priv "10")
/altsubject (value.priv "Rhinoceroses!"
size.priv "13")
/vendor/foobar/label.priv
(value.priv "label43"
size.priv "7")
/vendor/foobar/personality
(value.priv "Tallulah Bankhead"
size.priv "17")))
S: a OK Fetch complete
In the above example, the contents of the private "value" and "size" attributes for any entries in the "/" hierarchy are requested by the client and returned by the server.
在上面的示例中，客户机请求“/”层次结构中任何条目的私有“值”和“大小”属性的内容，服务器返回这些内容。
Example:
例子：
C: a FETCH 1 (ANNOTATION (/% value.shared))
S: * 1 FETCH (ANNOTATION
(/comment (value.shared "Patch Mangler")
/altsubject (value.shared "Patches? We don't
need no steenkin patches!")))
S: a OK Fetch complete
C: a FETCH 1 (ANNOTATION (/% value.shared))
S: * 1 FETCH (ANNOTATION
(/comment (value.shared "Patch Mangler")
/altsubject (value.shared "Patches? We don't
need no steenkin patches!")))
S: a OK Fetch complete
In the above example, the contents of the shared "value" attributes for entries at the top level only of the "/" hierarchy are requested by the client and returned by the server.
在上面的示例中，客户机请求并由服务器返回仅位于“/”层次结构顶层的条目的共享“值”属性的内容。
Entry and attribute specifiers can be lists of atomic specifiers, so that multiple items of each type may be returned in a single FETCH command.
条目和属性说明符可以是原子说明符的列表，因此可以在单个FETCH命令中返回每种类型的多个项。
Example:
例子：
C: a FETCH 1 (ANNOTATION
((/comment /altsubject) value.priv))
S: * 1 FETCH (ANNOTATION
(/comment (value.priv "What a chowder-head")
/altsubject (value.priv "How to crush beer cans")))
S: a OK Fetch complete
C: a FETCH 1 (ANNOTATION
((/comment /altsubject) value.priv))
S: * 1 FETCH (ANNOTATION
(/comment (value.priv "What a chowder-head")
/altsubject (value.priv "How to crush beer cans")))
S: a OK Fetch complete
In the above example, the contents of the private "value" attributes for the two entries "/comment" and "/altsubject" are requested by the client and returned by the server.
在上面的示例中，客户端请求并由服务器返回“/comment”和“/altsubject”两个条目的私有“value”属性的内容。
The ANNOTATION message data item in the FETCH response displays information about annotations in a message.
FETCH响应中的注释消息数据项显示有关消息中注释的信息。
ANNOTATION parenthesized list
注释括号列表
The response consists of a list of entries, each of which have a list of attribute-value pairs.
响应由一个条目列表组成，每个条目都有一个属性值对列表。
Example:
例子：
C: a FETCH 1 (ANNOTATION (/comment value))
S: * 1 FETCH (ANNOTATION (/comment
(value.priv "My comment"
value.shared NIL)))
S: a OK Fetch complete
C: a FETCH 1 (ANNOTATION (/comment value))
S: * 1 FETCH (ANNOTATION (/comment
(value.priv "My comment"
value.shared NIL)))
S: a OK Fetch complete
In the above example, a single entry with a single attribute-value pair is returned by the server. Since the client did not specify a ".shared" or ".priv" suffix, both are returned. Only the private attribute has a value (the shared value is "NIL").
在上面的示例中，服务器返回具有单个属性值对的单个条目。由于客户端未指定“.shared”或“.priv”后缀，因此将返回这两个后缀。只有private属性有一个值（共享值为“NIL”）。
Example:
例子：
C: a FETCH 1 (ANNOTATION
((/comment /altsubject) value))
S: * 1 FETCH (ANNOTATION
(/comment (value.priv "My comment"
value.shared NIL)
/altsubject (value.priv "My subject"
value.shared NIL)))
S: a OK Fetch complete
C: a FETCH 1 (ANNOTATION
((/comment /altsubject) value))
S: * 1 FETCH (ANNOTATION
(/comment (value.priv "My comment"
value.shared NIL)
/altsubject (value.priv "My subject"
value.shared NIL)))
S: a OK Fetch complete
In the above example, two entries, each with a single attribute-value pair, are returned by the server. Since the client did not specify a ".shared" or ".priv" suffix, both are returned. Only the private attributes have values; the shared attributes are "NIL".
在上面的示例中，服务器返回两个条目，每个条目都有一个属性值对。由于客户端未指定“.shared”或“.priv”后缀，因此将返回这两个后缀。只有私有属性才有值；共享属性为“NIL”。
Example:
例子：
C: a FETCH 1 (ANNOTATION
(/comment (value size)))
S: * 1 FETCH (ANNOTATION
(/comment
(value.priv "My comment"
value.shared NIL
size.priv "10"
size.shared "0")))
S: a OK Fetch complete
C: a FETCH 1 (ANNOTATION
(/comment (value size)))
S: * 1 FETCH (ANNOTATION
(/comment
(value.priv "My comment"
value.shared NIL
size.priv "10"
size.shared "0")))
S: a OK Fetch complete
In the above example, a single entry with two attribute-value pairs is returned by the server. Since the client did not specify a ".shared" or ".priv" suffix, both are returned. Only the private attributes have values; the shared attributes are "NIL".
在上面的示例中，服务器返回一个具有两个属性值对的条目。由于客户端未指定“.shared”或“.priv”后缀，因此将返回这两个后缀。只有私有属性才有值；共享属性为“NIL”。
Servers SHOULD send ANNOTATION message data items in unsolicited FETCH responses if an annotation entry is changed by a third-party, and the ANNOTATE select parameter was used. This allows servers to keep clients updated with changes to annotations by other clients.
如果第三方更改了注释条目，并且使用了ANNOTATE select参数，则服务器应在未经请求的获取响应中发送注释消息数据项。这允许服务器通过其他客户端对注释的更改来更新客户端。
Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data values -- only the entry name of the ANNOTATION that has changed. This restriction avoids sending ANNOTATION data values (which may be large) to a client unless the client explicitly asks for the value.
未经请求的注释响应不得包括注释数据值——仅包括已更改注释的条目名称。此限制可避免将注释数据值（可能较大）发送到客户端，除非客户端明确要求该值。
Example:
例子：
C: a STORE 1 +FLAGS (\Seen)
S: * 1 FETCH (FLAGS (\Seen))
ANNOTATION (/comment))
S: a OK STORE complete
C: a STORE 1 +FLAGS (\Seen)
S: * 1 FETCH (FLAGS (\Seen))
ANNOTATION (/comment))
S: a OK STORE complete
In the above example, an unsolicited ANNOTATION response is returned during a STORE command. The unsolicited response contains only the entry name of the annotation that changed, and not its value.
在上面的示例中，在STORE命令期间返回未经请求的注释响应。未经请求的响应仅包含已更改注释的条目名称，而不包含其值。
ANNOTATION <parenthesized entry-attribute-value list>
注释<括号内的条目属性值列表>
Sets the specified list of entries by adding or replacing the specified attributes with the values provided. Clients can use "NIL" for values of attributes it wants to remove from entries.
通过使用提供的值添加或替换指定的属性来设置指定的条目列表。客户机可以使用“NIL”表示要从条目中删除的属性值。
The ANNOTATION message data item used with the STORE command has an implicit ".SILENT" behavior. This means the server does not generate an untagged FETCH in response to the STORE command and assumes that the client updates its own cache if the command succeeds. Though note, that if the Conditional STORE extension [RFC4551] is present, then an untagged FETCH response with a MODSEQ data item will be returned by the server as required by [RFC4551].
与STORE命令一起使用的注释消息数据项具有隐式“.SILENT”行为。这意味着服务器不会响应STORE命令生成未标记的获取，并假设如果命令成功，客户端将更新其自己的缓存。但请注意，如果存在条件存储扩展[RFC4551]，则服务器将根据[RFC4551]的要求返回带有MODSEQ数据项的未标记的FETCH响应。
If the server is unable to store an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[ANNOTATE TOOBIG]" response code.
如果由于注释值太大，服务器无法存储注释，则服务器必须返回带有“[ANNOTATE TOOBIG]”响应代码的标记无响应。
If the server is unable to store a new annotation because the maximum number of allowed annotations has already been reached, the server MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response code.
如果由于已达到允许的最大批注数，服务器无法存储新批注，则服务器必须返回带有“[ANNOTATE TOOMANY]”响应代码的标记无响应。
Example:
例子：
C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment"))
S: a OK Store complete
C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment"))
S: a OK Store complete
In the above example, the entry "/comment" is created (if not already present). Its private attribute "value" is created if not already present, or replaced if it exists. "value.priv" is set to "My new comment".
在上面的示例中，创建了条目“/comment”（如果尚未存在）。如果它的私有属性“value”尚未存在，则创建它，如果它存在，则替换它。“value.priv”设置为“我的新评论”。
Example:
例子：
C: a STORE 1 ANNOTATION (/comment
(value.shared NIL))
S: a OK Store complete
C: a STORE 1 ANNOTATION (/comment
(value.shared NIL))
S: a OK Store complete
In the above example, the shared "value" attribute of the entry "/comment" is removed by storing "NIL" into the attribute.
在上面的示例中，条目“/comment”的共享“value”属性通过将“NIL”存储到属性中而被删除。
Multiple entries can be set in a single STORE command by listing entry-attribute-value pairs in the list.
通过在列表中列出条目属性值对，可以在单个STORE命令中设置多个条目。
Example:
例子：
C: a STORE 1 ANNOTATION (/comment
(value.priv "Get tix Tuesday")
/altsubject
(value.priv "Wots On"))
S: a OK Store complete
C: a STORE 1 ANNOTATION (/comment
(value.priv "Get tix Tuesday")
/altsubject
(value.priv "Wots On"))
S: a OK Store complete
In the above example, the entries "/comment" and "/altsubject" are created (if not already present) and the private attribute "value" is created or replaced for each entry.
在上述示例中，将创建条目“/comment”和“/altsubject”（如果尚未存在），并为每个条目创建或替换私有属性“value”。
Multiple attributes can be set in a single STORE command by listing multiple attribute-value pairs in the entry list.
通过在条目列表中列出多个属性值对，可以在单个STORE命令中设置多个属性。
Example:
例子：
C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment"
value.shared "foo's bar"))
S: a OK Store complete
C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment"
value.shared "foo's bar"))
S: a OK Store complete
In the above example, the entry "/comment" is created (if not already present) and the private and shared "value" attributes are created if not already present, or replaced if they exist.
在上面的示例中，将创建条目“/comment”（如果尚未存在），并创建私有和共享“value”属性（如果尚未存在），或者替换它们（如果存在）。
The COPY command can be used to move messages from one mailbox to another on the same server. Servers that support the ANNOTATION extension MUST, for each message being copied, copy all ".priv" annotation data for the current user only, and all ".shared" annotation data along with the message to the new mailbox. The only exceptions to this are if the destination mailbox permissions are such that either the ".priv" or ".shared" annotations are not allowed, or if the destination mailbox is of a type that does not support annotations or does not support storing of annotations (a mailbox that returns a "NONE" or "READ-ONLY" response code in its ANNOTATIONS response), or if the destination mailbox cannot support the size of an annotation because it exceeds the ANNOTATIONS value. Servers MUST NOT copy ".priv" annotation data for users other than the current user.
COPY命令可用于将邮件从一个邮箱移动到同一服务器上的另一个邮箱。对于要复制的每条邮件，支持批注扩展的服务器必须仅将当前用户的所有“.priv”批注数据以及邮件中的所有“.shared”批注数据复制到新邮箱。唯一的例外情况是，如果目标邮箱权限不允许“.priv”或“.shared”批注，或者目标邮箱类型不支持批注或不支持存储批注（返回“无”或“只读”的邮箱）注释响应中的响应代码），或者目标邮箱无法支持注释的大小，因为它超过了注释值。服务器不得为当前用户以外的用户复制“.priv”批注数据。
ANNOTATION <parenthesized entry-attribute-value list>
注释<括号内的条目属性值列表>
Sets the specified list of entries and attributes in the resulting message.
设置结果消息中指定的条目和属性列表。
The APPEND command can include annotations for the message being appended via the addition of a new append data item [RFC4466]. The new data item can also be used with the multi-append [RFC3502] extension that allows multiple messages to be appended via a single APPEND command.
APPEND命令可以通过添加新的APPEND数据项[RFC4466]来包含所追加消息的注释。新数据项还可以与multi append[RFC3502]扩展一起使用，该扩展允许通过单个append命令追加多条消息。
Example:
例子：
C: a APPEND drafts ANNOTATION (/comment
(value.priv "Don't send until I say so")) {310}
S: + Ready for literal data
C: MIME-Version: 1.0
...
C:
S: a OK APPEND completed
C: a APPEND drafts ANNOTATION (/comment
(value.priv "Don't send until I say so")) {310}
S: + Ready for literal data
C: MIME-Version: 1.0
...
C:
S: a OK APPEND completed
In the above example, a comment with a private value is added to a new message appended to the mailbox. The ellipsis represents the bulk of the message.
在上面的示例中，带有私有值的注释被添加到附加到邮箱的新邮件中。省略号表示消息的大部分。
ANNOTATION <entry-name> <attribute-name> <value>
ANNOTATION <entry-name> <attribute-name> <value>
The ANNOTATION criterion for the SEARCH command allows a client to search for a specified string in the value of an annotation entry of a message.
SEARCH命令的注释条件允许客户端在消息注释项的值中搜索指定的字符串。
Messages that have annotations with entries matching <entry-name>, attributes matching <attribute-name>, and the specified string <value> in their values are returned in the SEARCH results. The "*" character can be used in the entry name field to match any content in those items. The "%" character can be used in the entry name field to match a single level of hierarchy only.
搜索结果中将返回注释中的条目匹配<条目名称>、属性匹配<属性名称>、且其值中指定的字符串<值>。条目名称字段中可以使用“*”字符来匹配这些条目中的任何内容。在条目名称字段中，可以使用“%”字符来仅匹配一个层次结构级别。
Only the "value", "value.priv", and "value.shared" attributes can be searched. Clients MUST NOT specify an attribute other than either "value", "value.priv", or "value.shared". Servers MUST return a BAD response if the client tries to search any other attribute.
只能搜索“value”、“value.priv”和“value.shared”属性。客户端不能指定“value”、“value.priv”或“value.shared”以外的属性。如果客户端尝试搜索任何其他属性，则服务器必须返回错误响应。
Example:
例子：
C: a SEARCH ANNOTATION /comment value "IMAP4"
S: * SEARCH 2 3 5 7 11 13 17 19 23
S: a OK Search complete
C: a SEARCH ANNOTATION /comment value "IMAP4"
S: * SEARCH 2 3 5 7 11 13 17 19 23
S: a OK Search complete
In the above example, the message numbers of any messages containing the string "IMAP4" in the shared or private "value" attribute of the "/comment" entry are returned in the search results.
在上面的示例中，搜索结果中返回“/comment”条目的共享或私有“value”属性中包含字符串“IMAP4”的任何消息的消息编号。
Example:
例子：
C: a SEARCH ANNOTATION * value.priv "IMAP4"
S: * SEARCH 1 2 3 5 8 13 21 34
S: a OK Search complete
C: a SEARCH ANNOTATION * value.priv "IMAP4"
S: * SEARCH 1 2 3 5 8 13 21 34
S: a OK Search complete
In the above example, the message numbers of any messages containing the string "IMAP4" in the private "value" attribute of any entry are returned in the search results.
在上面的示例中，在搜索结果中返回任何条目的私有“value”属性中包含字符串“IMAP4”的任何消息的消息编号。
ANNOTATION <entry-name> <attribute-name>
ANNOTATION <entry-name> <attribute-name>
The ANNOTATION criterion for the SORT command [RFC5256] instructs the server to return the sequence numbers or Unique Identifiers (UIDs) of messages in a mailbox, sorted using the values of the specified annotations. The ANNOTATION criterion is available if the server returns both ANNOTATE-EXPERIMENT-1 and SORT as supported capabilities in the CAPABILITY command response.
排序命令[RFC5256]的注释标准指示服务器返回邮箱中邮件的序列号或唯一标识符（UID），并使用指定注释的值进行排序。如果服务器在CAPABILITY命令响应中返回ANNOTATE-EXPERIMENT-1和SORT-as-supported功能，则注释标准可用。
Messages are sorted using the values of the <attribute-name> attributes in the <entry-name> entries.
使用<entry name>条目中的<attribute name>属性值对消息进行排序。
Clients MUST provide either the ".priv" or ".shared" suffix to the attribute name to ensure that the server knows which specific value to sort on.
客户端必须为属性名提供“.priv”或“.shared”后缀，以确保服务器知道要排序的特定值。
Only the "value.priv" and "value.shared" attributes can be used for sorting. Clients MUST NOT specify an attribute other than either "value.priv" or "value.shared". Servers MUST return a BAD response if the client tries to sort on any other attribute.
只有“value.priv”和“value.shared”属性可以用于排序。客户端不能指定“value.priv”或“value.shared”以外的属性。如果客户端尝试对任何其他属性进行排序，服务器必须返回错误响应。
When either "value.priv" or "value.shared" is being sorted, the server MUST use the character set value specified in the SORT command to determine the appropriate sort order.
当对“value.priv”或“value.shared”进行排序时，服务器必须使用SORT命令中指定的字符集值来确定适当的排序顺序。
Example:
例子：
C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL
S: * SORT 2 3 4 5 1 11 10 6 7 9 8
S: a OK Sort complete
C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL
S: * SORT 2 3 4 5 1 11 10 6 7 9 8
S: a OK Sort complete
In the above example, the message numbers of all messages are returned, sorted according to the shared "value" attribute of the "/altsubject" entry.
在上面的示例中，返回所有消息的消息编号，并根据“/altsubject”条目的共享“value”属性进行排序。
Note that the ANNOTATION sort key must include a fully specified entry -- wild cards are not allowed.
请注意，注释排序键必须包含完全指定的条目——不允许使用通配符。
As discussed in Section 3.4, this extension adds a new "n" right to the list of rights provided by the ACL extensions [RFC2086] and [RFC4314].
如第3.4节所述，此扩展在ACL扩展[RFC2086]和[RFC4314]提供的权限列表中添加了一个新的“n”权限。
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.
除非另有说明，否则所有字母字符都不区分大小写。使用大写或小写字符定义标记字符串仅为编辑目的。实现必须以不区分大小写的方式接受这些字符串。
ann-size = "NONE" / (("READ-ONLY" / nz-number) [SP "NOPRIVATE"]) ; response codes indicating the level of ; support for annotations in a mailbox
ann size=“无”/（“只读”/nz编号）[SP“NOPRIVATE”]；响应代码，指示响应级别；支持邮箱中的批注
append-ext =/ att-annotate ; modifies [RFC3501] extension behaviour
追加ext=/att注释；修改[RFC3501]扩展行为
att-annotate = "ANNOTATION" SP "(" entry-att *(SP entry-att) ")"
att annotate=“注释”SP”（“条目att*（SP条目att）”）
att-search = "value" / "value.priv" / "value.shared"
; the only attributes that can be searched
att-search = "value" / "value.priv" / "value.shared"
; the only attributes that can be searched
att-sort = "value.priv" / "value.shared"
; the only attributes that can be sorted
att-sort = "value.priv" / "value.shared"
; the only attributes that can be sorted
att-value = attrib SP value
att-value = attrib SP value
attrib = astring ; dot-separated attribute name ; MUST NOT contain "*" or "%"
attrib=收缩；点分隔属性名；不得包含“*”或“%”
attribs = attrib / "(" attrib *(SP attrib) ")"
; one or more attribute specifiers
attribs = attrib / "(" attrib *(SP attrib) ")"
; one or more attribute specifiers
capability =/ "ANNOTATE-EXPERIMENT-1" ; defines the capability for this extension
能力=/“ANNOTATE-Experience-1”；定义此扩展的功能
entries = entry-match /
"(" entry-match *(SP entry-match) ")"
entries = entry-match /
"(" entry-match *(SP entry-match) ")"
entry = astring ; slash-separated path to entry ; MUST NOT contain "*" or "%"
进入=收缩；斜线分隔的进入路径；不得包含“*”或“%”
entry-att = entry SP "(" att-value *(SP att-value) ")"
entry-att = entry SP "(" att-value *(SP att-value) ")"
entry-match = list-mailbox ; slash-separated path to entry ; MAY contain "*" or "%" for use as wild cards
条目匹配=列表邮箱；斜线分隔的进入路径；可能包含用作通配符的“*”或“%”
fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")"
; modifies original IMAP fetch-att
fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")"
; modifies original IMAP fetch-att
msg-att-dynamic =/ "ANNOTATION" SP
( "(" entry-att *(SP entry-att) ")" /
"(" entry *(SP entry) ")" )
; extends FETCH response with annotation data
msg-att-dynamic =/ "ANNOTATION" SP
( "(" entry-att *(SP entry-att) ")" /
"(" entry *(SP entry) ")" )
; extends FETCH response with annotation data
resp-text-code =/ "ANNOTATE" SP "TOOBIG" / "ANNOTATE" SP "TOOMANY" / "ANNOTATIONS" SP ann-size ; new response codes
resp text code=/“注释”SP“太大”/“注释”SP“太多”/“注释”SP ann大小；新的响应代码
search-key =/ "ANNOTATION" SP entry-match SP att-search SP value ; modifies original IMAP search-key
搜索键=/“注释”SP条目匹配SP att搜索SP值；修改原始IMAP搜索键
select-param =/ "ANNOTATE" ; defines the select parameter used with ; ANNOTATE extension
选择参数=/“注释”；定义与一起使用的select参数；注释扩展名
sort-key =/ "ANNOTATION" SP entry SP att-sort ; modifies original sort-key
排序键=/“注释”SP条目SP att sort；修改原始排序键
store-att-flags =/ att-annotate ; modifies original IMAP STORE command
存储att标志=/att注释；修改原始IMAP存储命令
value = nstring / literal8
value = nstring / literal8
Entry names MUST be specified in a standards track or IESG approved experimental RFC, or fall under the vendor namespace. Vendor names MUST be registered.
条目名称必须在标准跟踪或IESG批准的实验RFC中指定，或属于供应商名称空间。必须注册供应商名称。
Attribute names MUST be specified in a standards track or IESG approved experimental RFC.
属性名称必须在标准跟踪或IESG批准的实验RFC中指定。
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 Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[] Entry [] Attribute
[]条目[]属性
Name: ______________________________
Name: ______________________________
Description: _______________________
Description: _______________________
____________________________________
____________________________________
____________________________________
____________________________________
Content-Type:_______________________
Content-Type:_______________________
Contact person: ____________________
Contact person: ____________________
email: ____________________
email: ____________________
The following templates specify the IANA registrations of annotation entries specified in this document.
以下模板指定了本文档中指定的注释条目的IANA注册。
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /comment
姓名：/comment
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /flags
名称：/flags
Description: Reserved entry hierarchy.
描述：保留条目层次结构。
Content-Type: -
内容类型：-
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /altsubject
姓名：/altsubject
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /<section-part>/comment
Name: /<section-part>/comment
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /<section-part>/flags/seen
Name: /<section-part>/flags/seen
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /<section-part>/flags/answered
Name: /<section-part>/flags/answered
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /<section-part>/flags/flagged
Name: /<section-part>/flags/flagged
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[X] Entry [] Attribute
[十] 条目[]属性
Name: /<section-part>/flags/forwarded
Name: /<section-part>/flags/forwarded
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Content-Type: text/plain; charset=utf-8
Content-Type: text/plain; charset=utf-8
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
The following templates specify the IANA registrations of annotation attributes specified in this document.
以下模板指定了本文档中指定的注释属性的IANA注册。
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[] Entry [X] Attribute
[]条目[X]属性
Name: value
名称：value
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
To: iana@iana.org Subject: IMAP Annotate Registration
致：iana@iana.org主题：IMAP注释注册
Please register the following IMAP Annotate item:
请注册以下IMAP注释项：
[] Entry [X] Attribute
[]条目[X]属性
Name: size
名称：尺码
Description: Defined in IMAP ANNOTATE extension document.
描述：在IMAP注释扩展文档中定义。
Contact person: Cyrus Daboo
联系人：赛勒斯·达布
email: cyrus@daboo.name
电邮：cyrus@daboo.name
This document registers "ANNOTATE-EXPERIMENT-1" as an IMAPEXT capability.
本文档将“ANNOTATE-Experience-1”注册为IMAPEXT功能。
Annotations may contain values that include text strings, and both searching and sorting are possible with annotations. Servers MUST follow standard IMAP text normalization, character set conversion, and collation rules when such operations are carried out, as would be done for other textual fields being searched or sorted on.
注释可能包含包含文本字符串的值，并且可以使用注释进行搜索和排序。在执行此类操作时，服务器必须遵循标准IMAP文本规范化、字符集转换和排序规则，就像对正在搜索或排序的其他文本字段所做的那样。
Annotations whose values are intended to remain private MUST be stored in ".priv" values instead of ".shared" values, which may be accessible to other users.
值要保持私有的批注必须存储在“.priv”值中，而不是其他用户可以访问的“.shared”值中。
Excluding the above issues, the ANNOTATE extension does not raise any security considerations that are not present in the base IMAP protocol; these issues are discussed in [RFC3501].
除上述问题外，ANNOTATE扩展没有提出任何基本IMAP协议中不存在的安全注意事项；[RFC3501]中讨论了这些问题。
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[RFC2086]迈尔斯，J.，“IMAP4 ACL扩展”，RFC2086，1997年1月。
[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月。
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension", RFC 3502, March 2003.
[RFC3502]Crispin，M.，“互联网消息访问协议（IMAP）-多附加扩展”，RFC 35022003年3月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[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月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, June 2008.
[RFC5256]Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，RFC 5256，2008年6月。
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, June 2006.
[RFC4551]Melnikov，A.和S.Hole，“条件存储操作或快速标志更改再同步的IMAP扩展”，RFC 45512006年6月。
Many thanks to Chris Newman for his detailed comments on the first draft of this document, and to the participants at the ACAP working dinner in Pittsburgh. The participants of the IMAPext working group made significant contributions to this work.
非常感谢Chris Newman对本文件初稿的详细评论，并感谢匹兹堡ACAP工作晚宴的与会者。IMAPext工作组的与会者对这项工作作出了重大贡献。
Authors' Addresses
作者地址
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/
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 USA
Randall Gellens高通公司5775 Morehouse Dr.San Diego，CA 92121-2779美国
EMail: randy@qualcomm.com
EMail: randy@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.