Network Working Group A. Melnikov
Request for Comments: 5466 C. King
Category: Standards Track Isode Ltd
February 2009
Network Working Group A. Melnikov
Request for Comments: 5466 C. King
Category: Standards Track Isode Ltd
February 2009
IMAP4 Extension for Named Searches (Filters)
命名搜索（筛选器）的IMAP4扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/ 许可证信息）在本文件发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
The document defines a way to persistently store named IMAP (RFC 3501) searches on the server. Such named searches can be subsequently referenced in a SEARCH or any other command that accepts a search criterion as a parameter.
该文档定义了一种在服务器上持久存储命名IMAP（RFC 3501）搜索的方法。随后，可以在搜索或接受搜索条件作为参数的任何其他命令中引用此类命名搜索。
Table of Contents
目录
1. Introduction and Overview . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . . 2
3.1. FILTER SEARCH Criterion . . . . . . . . . . . . . . . . . . 3
3.2. Managing Filters Using SETMETADATA/GETMETADATA Commands . . 4
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction and Overview . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . . 2
3.1. FILTER SEARCH Criterion . . . . . . . . . . . . . . . . . . 3
3.2. Managing Filters Using SETMETADATA/GETMETADATA Commands . . 4
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Normative References . . . . . . . . . . . . . . . . . . . . . 8
Persistent named searches described in this document allow clients to save favorite searches on the server. Such saved searches can save bandwidth for clients that need to regularly repeat them.
本文档中描述的持久命名搜索允许客户端在服务器上保存收藏夹搜索。这样节省的搜索可以为需要定期重复搜索的客户端节省带宽。
The FILTERS IMAP extension adds a new FILTER search criterion for referencing persistent named searches (a.k.a. "filters"), as well as reuses GETMETADATA/SETMETADATA commands [METADATA] for listing/ creating/updating/deleting such filters.
FILTERS IMAP扩展添加了一个新的过滤器搜索条件，用于引用持久命名搜索（又称“过滤器”），并重用GETMETADATA/SETMETADATA命令[METADATA]来列出/创建/更新/删除此类过滤器。
A filter can be private (only accessible to the logged-in user) or public (accessible to all logged-in users). Both a private and a public filter with the same name can exist at the same time. If both filter types with the same name exist, the FILTER SEARCH criterion (see Section 3.1) MUST use the value of the private filter; otherwise, it MUST use the value of the filter that exists.
筛选器可以是私有的（仅登录用户可以访问）或公共的（所有登录用户都可以访问）。具有相同名称的私有筛选器和公共筛选器可以同时存在。如果存在同名的两种过滤器类型，过滤器搜索条件（见第3.1节）必须使用专用过滤器的值；否则，它必须使用现有筛选器的值。
Let us call a pair of filter name and filter type a "typed filter". Each typed filter can have a value (which is a valid IMAP SEARCH criteria conforming to ABNF for the "search-criteria" non-terminal) and an optional human-readable description. The SETMETADATA command creates or updates the value and/or the description of a typed filter.
让我们将一对过滤器名称和过滤器类型称为“类型化过滤器”。每个类型化过滤器可以有一个值（这是一个有效的IMAP搜索标准，符合ABNF的“搜索标准”非终端）和可选的人类可读描述。SETMETADATA命令创建或更新类型化筛选器的值和/或描述。
Values of all search keys stored in a filter MUST be encoded in UTF-8.
存储在筛选器中的所有搜索键的值必须以UTF-8编码。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。如果单个“C:”或“S:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。
The 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]中所述进行解释。
Basic familiarity with the METADATA-SERVER extension [METADATA] and terms defined therein is required to understand this document.
理解本文档需要基本熟悉元数据服务器扩展[元数据]及其定义的术语。
The IMAP extension for persistent named searches is present in any IMAP4 implementation that advertises "FILTERS" as one of the supported capabilities in the CAPABILITY response or response code.
用于持久命名搜索的IMAP扩展存在于任何IMAP4实现中，该IMAP4实现将“过滤器”作为功能响应或响应代码中支持的功能之一进行宣传。
The FILTER criterion for the SEARCH command allows a client to reference by name a filter stored on the server. Such filter was created by setting the server annotation named "/private/filters/ values/<filter_name>" (or the server annotation "/shared/filters/ values/<filter_name>", if "/private/filters/values/<filter_name>" doesn't exist) using the SETMETADATA command as described in Section 3.2.
SEARCH命令的筛选条件允许客户端按名称引用存储在服务器上的筛选器。如第3.2节所述，通过使用SETMETADATA命令设置名为“/private/filters/values/<filter\u name>”的服务器注释（或服务器注释“/shared/filters/values/<filter\u name>”，如果“/private/filters/values/<filter\u name>”不存在，则创建该过滤器。
Syntax: FILTER <filter_name>
Syntax: FILTER <filter_name>
When the named filter exists, its search criterion (i.e., the associated entry value) is inserted verbatim instead of the FILTER search-key. For example, the following SEARCH command
当命名筛选器存在时，将逐字插入其搜索条件（即关联的条目值），而不是筛选器搜索键。例如，下面的搜索命令
C: a SEARCH UID 300:900 FILTER on-the-road SINCE "3-Dec-2002"
C:自“2002年12月3日”以来，道路上出现了搜索UID 300:900过滤器
would be equivalent to the following
将等同于以下内容
C: a SEARCH UID 300:900 OR SMALLER 5000 FROM "boss@example.com" SINCE "3-Dec-2002"
C:搜索UID 300:900或更小5000“boss@example.com“自2002年12月3日起”
assuming the filter "on-the-road" exists and contains the value 'OR SMALLER 5000 FROM "boss@example.com"'.
假设过滤器“on the road”（在道路上）存在并包含值“或小于5000 FROM”boss@example.com"'.
A reference to a nonexistent or unaccessible (e.g., due to access control restrictions) filter MUST cause failure of the SEARCH command with the tagged NO response that includes the UNDEFINED-FILTER response code followed by the name of the nonexistent/unaccessible filter.
对不存在或不可访问（例如，由于访问控制限制）筛选器的引用必须导致搜索命令失败，带有标记的无响应，其中包括未定义的-filter响应代码，后跟不存在/不可访问筛选器的名称。
Note the server SHOULD verify that each search criterion referenced by the FILTER search key is a full and correct search criterion. For example, the server should fail the SEARCH command if its SEARCH criterion references a filter containing "OR SMALLER" search criterion, because this value is lacking one parameter and thus is not a fully specified search criterion.
注意：服务器应验证筛选器搜索键引用的每个搜索条件是否完整且正确。例如，如果服务器的搜索条件引用了包含“或更小”搜索条件的筛选器，则该服务器应使搜索命令失败，因为该值缺少一个参数，因此不是完全指定的搜索条件。
Note that a named filter itself can reference another filter using the FILTER search-key. Implementations MUST be able to perform at least 3 substitution passes on the SEARCH command criterion. If an implementation allows for more passes, it MUST implement some kind of loop detection. If an implementation detects a loop or still sees a FILTER search-key after performing at least 3 substitutions, it MUST behave as if the specified filter doesn't exist (as described above).
请注意，命名筛选器本身可以使用筛选器搜索键引用另一个筛选器。实现必须能够对搜索命令条件执行至少3次替换传递。如果一个实现允许更多的过程，那么它必须实现某种循环检测。如果实现在执行至少3次替换后检测到循环或仍然看到筛选器搜索键，则它必须表现为指定的筛选器不存在（如上所述）。
Note that use of the FILTER search key implies the CHARSET "UTF-8" parameter to the SEARCH/UID SEARCH command. If the SEARCH/UID SEARCH command includes the explicit CHARSET parameter with the value other than "UTF-8" or "US-ASCII", then such command MUST result in the tagged BAD response from the server. Such tagged response MUST contain the BADCHARSET response code (see [RFC3501]).
注意，使用FILTER search键意味着search/UID search命令的字符集“UTF-8”参数。如果SEARCH/UID SEARCH命令包含值不是“UTF-8”或“US-ASCII”的显式字符集参数，则该命令必须导致来自服务器的标记错误响应。此类标记响应必须包含BADCHARSET响应代码（请参见[RFC3501]）。
Any server compliant with this document MUST either implement the METADATA-SERVER (or METADATA) [METADATA] extension, or implement SETMETADATA/GETMETADATA commands described in [METADATA] so that they work for the case of empty mailbox name (i.e., for managing server annotations) and for the entries specified in this section.
符合本文档要求的任何服务器必须实现METADATA-server（或METADATA）[METADATA]扩展，或实现[METADATA]中描述的SETMETADATA/GETMETADATA命令，以便它们适用于空邮箱名称的情况（即，用于管理服务器批注）和本节中指定的条目。
This document reserves two hierarchies of per-server entries under the "/private/filters/values" and "/shared/filters/values" roots (see [METADATA]) for storing filter values. The value of a "/private/ filters/values/<filter_name>" or a "/shared/filters/values/ <filter_name>" server annotation is an IMAP SEARCH criteria, conforming to ABNF for the "search-criteria" non-terminal. A name of a filter is governed by the ABNF for the "filter-name" non-terminal.
本文档在“/private/filters/values”和“/shared/filters/values”根目录下保留每服务器项的两个层次结构（请参见[元数据]），用于存储筛选器值。“/private/filters/values/<filter\u name>”或“/shared/filters/values/<filter\u name>”服务器批注的值是IMAP搜索条件，符合ABNF的“搜索条件”非终端。过滤器的名称由“过滤器名称”非终端的ABNF管理。
Note that values of all search keys stored in these entries MUST be encoded in UTF-8.
请注意，存储在这些条目中的所有搜索键的值必须用UTF-8编码。
A new filter named "<filter_name>" can be created (or an existing filter can be modified) by storing a non-NIL value in the "/private/ filters/values/<filter_name>" server entry (or in the "/shared/ filters/values/<filter_name>") using the SETMETADATA [METADATA] command. The server SHOULD verify that each search criterion stored in such a server entry is a full and correct search criterion.
A new filter named "<filter_name>" can be created (or an existing filter can be modified) by storing a non-NIL value in the "/private/ filters/values/<filter_name>" server entry (or in the "/shared/ filters/values/<filter_name>") using the SETMETADATA [METADATA] command. The server SHOULD verify that each search criterion stored in such a server entry is a full and correct search criterion.translate error, please retry
A filter can be deleted by storing the NIL value in both the "/private/filters/values/<filter_name>" and the "/shared/filters/ values/<filter_name>" entries.
可以通过在“/private/filters/values/<filter\u name>”和“/shared/filters/values/<filter\u name>”条目中存储NIL值来删除筛选器。
A filter can be renamed by first creating a filter with the new name (that has the same value as the old one) and then deleting the filter with the old one.
通过首先使用新名称（与旧名称具有相同的值）创建过滤器，然后使用旧名称删除过滤器，可以重命名过滤器。
If both "/private/filters/values/<filter_name>" and "/shared/filters/ values/<filter_name>" server annotations exist, then the value of the "/private/filters/values/<filter_name>" is used when evaluating the corresponding FILTER SEARCH key (see Section 3.1). Otherwise the non-NIL (existent) value is used.
如果同时存在“/private/filters/values/<filter\u name>”和“/shared/filters/values/<filter\u name>”服务器批注，则在评估相应的筛选器搜索键时使用“/private/filters/values/<filter\u name>”的值（参见第3.1节）。否则将使用非零（存在）值。
If the server is unable to create a new typed filter because the maximum number of allowed filters has already been reached, the server MUST return a tagged NO response with a "[METADATA TOOMANY]" response code, as defined in [METADATA].
如果服务器无法创建新类型的筛选器，因为已达到允许的筛选器的最大数目，则服务器必须返回带有“[METADATA TOOMANY]”响应代码的标记无响应，如[METADATA]中所定义。
C: a007 SETMETADATA "" ("/private/filters/values/on-the-road"
"OR SMALLER 5000 FROM \"boss@example.com\"")
S: a007 OK SETMETADATA complete
C: a007 SETMETADATA "" ("/private/filters/values/on-the-road"
"OR SMALLER 5000 FROM \"boss@example.com\"")
S: a007 OK SETMETADATA complete
Client implementation note: As multiple clients might read and write filter values, it is possible that one client will use a SEARCH key that might not be recognized by another client that tries to present a user interface for editing a filter value. In order to help other clients to (partially) parse filter values for editing purposes, a client storing a filter value SHOULD use () around any SEARCH key not defined in [RFC3501]. For example, if there is an IMAP extension that defines a new x-dsfa SEARCH key that takes 2 parameters, then the following SEARCH criterion 'from "@example.com>" x-dsfa from 5' should be stored as 'from "@example.com>" (x-dsfa from 5)'.
客户端实现说明：由于多个客户端可能读取和写入筛选器值，因此一个客户端可能会使用另一个客户端可能无法识别的搜索键，而另一个客户端试图提供用于编辑筛选器值的用户界面。为了帮助其他客户端（部分）分析筛选值以进行编辑，存储筛选值的客户端应在[RFC3501]中未定义的任何搜索键周围使用（）。例如，如果有一个IMAP扩展名定义了一个新的x-dsfa搜索键，该键包含2个参数，则以下搜索条件“from”@example.com>“x-dsfa from 5”应存储为“from”@example.com>“（x-dsfa from 5）”。
Note that filter names are restricted to a subset of US-ASCII, as described in Section 4. So they might not always be meaningful to users and thus not necessarily suitable for display purposes. In order to help with storing human-readable descriptions of filters, this document also reserves two hierarchies of server entries under the "/private/filters/descriptions" and "/shared/filters/ descriptions" roots. The value of a "/private/filters/descriptions/ <filter_name>" or a "/shared/filters/descriptions/<filter_name>" server annotation is a human-readable description for the <filter_name> filter, encoded in UTF-8 [UTF-8]. If the "/private/ filters/descriptions/<filter_name>" server annotation exists, its value is used by the client as the filter description. Otherwise, the value of the "/shared/filters/descriptions/<filter_name>" server annotation is used as the filter description. In the absence of both the "/private/filters/descriptions/<filter_name>" and the "/shared/ filters/descriptions/<filter_name>" entries, the client MAY display the name of the filter as its description.
请注意，过滤器名称仅限于US-ASCII的子集，如第4节所述。因此，它们可能并不总是对用户有意义，因此不一定适合用于显示目的。为了帮助存储人类可读的过滤器描述，本文档还在“/private/filters/descriptions”和“/shared/filters/descriptions”根下保留两个服务器条目层次结构。“/private/filters/descriptions/<filter\u name>”或“/shared/filters/descriptions/<filter\u name>”服务器注释的值是以UTF-8[UTF-8]编码的<filter\u name>过滤器的可读描述。如果存在“/private/filters/descriptions/<filter\u name>”服务器批注，则客户端将其值用作筛选器说明。否则，将“/shared/filters/descriptions/<filter\u name>”服务器注释的值用作过滤器描述。如果同时缺少“/private/filters/descriptions/<filter\u name>”和“/shared/filters/descriptions/<filter\u name>”条目，客户端可能会将筛选器的名称显示为其描述。
The description string SHOULD be annotated with one or more language
tags [RFC4646] as specified in Chapter 16.9 of [Unicode]. In the
absence of any language tag, the "i-default" [RFC2277] language
SHOULD be assumed. Description in multiple languages MAY be present
in a single description string. This is done by concatenating
descriptions in multiple languages into a single string, each
description prefixed with its language tag, for example
"<ru><...description in Russian...><fr-ca><...description in
French...>". Note that here <ru> is a language tag consisting of 3
Unicode characters: <U+E0001>, <U+E0072>, <U+E0075>; and <fr-ca> is a
The description string SHOULD be annotated with one or more language
tags [RFC4646] as specified in Chapter 16.9 of [Unicode]. In the
absence of any language tag, the "i-default" [RFC2277] language
SHOULD be assumed. Description in multiple languages MAY be present
in a single description string. This is done by concatenating
descriptions in multiple languages into a single string, each
description prefixed with its language tag, for example
"<ru><...description in Russian...><fr-ca><...description in
French...>". Note that here <ru> is a language tag consisting of 3
Unicode characters: <U+E0001>, <U+E0072>, <U+E0075>; and <fr-ca> is a
language tag consisting of 6 Unicode characters: <U+E0001>, <U+E0066>, <U+E0072>, <U+E002D>, <U+E0063>, <U+E0061>.
由6个Unicode字符组成的语言标记：<U+E0001>，<U+E0066>，<U+E0072>，<U+E002D>，<U+E0063>，<U+E0061>。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。
Non-terminals referenced but not defined below are as defined by [RFC3501] or [IMAPABNF].
以下引用但未定义的非端子由[RFC3501]或[IMAPABNF]定义。
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 =/ "FILTERS"
功能=/“过滤器”
search-criteria = search-key *(SP search-key)
搜索条件=搜索键*（SP搜索键）
search-key =/ "FILTER" SP filter-name
;; New SEARCH criterion for referencing filters
search-key =/ "FILTER" SP filter-name
;; New SEARCH criterion for referencing filters
filter-name = 1*<any ATOM-CHAR except "/">
;; Note that filter-name disallows UTF-8 or
;; the following characters: "(", ")", "{",
;; " ", "%", "*", "]". See definition of
;; ATOM-CHAR [RFC3501].
filter-name = 1*<any ATOM-CHAR except "/">
;; Note that filter-name disallows UTF-8 or
;; the following characters: "(", ")", "{",
;; " ", "%", "*", "]". See definition of
;; ATOM-CHAR [RFC3501].
resp-text-code =/ "UNDEFINED-FILTER" SP filter-name
resp text code=/“UNDEFINED-FILTER”SP筛选器名称
General issues relevant to [RFC3501] (in particular to the SEARCH command) and METADATA-SERVER extension [METADATA] are also relevant to this document.
与[RFC3501]（特别是搜索命令）和元数据服务器扩展[METADATA]相关的一般问题也与本文档相关。
Note that excessive use of filters can potentially simplify denial-of-service attacks, especially if combined with poor implementations and lack of loop detection (i.e., detection of filters referencing each other to create a loop). Servers that allow for anonymous access SHOULD NOT allow anonymous users to create/edit/delete filters.
请注意，过度使用过滤器可能会简化拒绝服务攻击，尤其是在结合了糟糕的实现和缺乏循环检测（即，检测相互引用以创建循环的过滤器）的情况下。允许匿名访问的服务器不应允许匿名用户创建/编辑/删除筛选器。
Also note that stored filters can potentially disclose personal information about users. When confidentiality of such information is important, clients MUST use TLS and/or SASL security layer (or similar) as recommended in [RFC3501]. Also, clients should use
还要注意，存储的过滤器可能会泄露用户的个人信息。当此类信息的保密性非常重要时，客户必须按照[RFC3501]中的建议使用TLS和/或SASL安全层（或类似层）。此外，客户应使用
private filters instead of public, unless they desire to share such information with other users.
私人过滤器而不是公共过滤器，除非它们希望与其他用户共享此类信息。
As always, it is important to thoroughly test clients and servers when implementing this extension.
与往常一样，在实现此扩展时，彻底测试客户端和服务器非常重要。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The IMAP4 capabilities registry is available from http://www.iana.org.
IMAP4功能通过发布标准跟踪或IESG批准的实验RFC进行注册。IMAP4功能注册表可从以下位置获得：http://www.iana.org.
This document defines the FILTERS IMAP capability. IANA has added it to the registry.
本文档定义了过滤器IMAP功能。IANA已将其添加到注册表中。
IANA has added the following 4 entries to the [METADATA] registry:
IANA已将以下4个条目添加到[元数据]注册表中：
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /private/filters/values/<filter_name>
Description: Contains an IMAP SEARCH criteria. Defined in RFC 5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /private/filters/values/<filter_name>
Description: Contains an IMAP SEARCH criteria. Defined in RFC 5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/filters/values/<filter_name>
Description: Contains an IMAP SEARCH criterion. Defined in RFC
5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/filters/values/<filter_name>
Description: Contains an IMAP SEARCH criterion. Defined in RFC
5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /private/filters/descriptions/<filter_name>
Description: Contains a user-specific human-readable description of
a named SEARCH criterion stored in the /private/filters/values/
<filter_name> or /shared/filters/values/<filter_name> annotation.
The value is in UTF-8. Defined in RFC 5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /private/filters/descriptions/<filter_name>
Description: Contains a user-specific human-readable description of
a named SEARCH criterion stored in the /private/filters/values/
<filter_name> or /shared/filters/values/<filter_name> annotation.
The value is in UTF-8. Defined in RFC 5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/filters/descriptions/<filter_name>
Description: Contains a global (shared among all users) human-
readable description of a named SEARCH criterion stored in the
/private/filters/values/<filter_name> or /shared/filters/values/
<filter_name> annotation. The value is in UTF-8. Defined in RFC
5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
To: iana@iana.org
Subject: IMAP METADATA Entry Registration
Type: Server
Name: /shared/filters/descriptions/<filter_name>
Description: Contains a global (shared among all users) human-
readable description of a named SEARCH criterion stored in the
/private/filters/values/<filter_name> or /shared/filters/values/
<filter_name> annotation. The value is in UTF-8. Defined in RFC
5466.
Content-type: text/plain; charset=utf-8
Contact person: Alexey Melnikov
Email: alexey.melnikov@isode.com
Thanks to David Cridland, Arnt Gulbrandsen, Chris Newman, and Timo Sirainen for comments and suggestions on this document. Special thank you to Brian E. Carpenter for the GenArt review.
感谢David Cridland、Arnt Gulbrandsen、Chris Newman和Timo Sirainen对本文件的评论和建议。特别感谢Brian E.Carpenter的GenArt评论。
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.和P.Overell，Ed.，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]Melnikov，A.和C.Daboo，“IMAP4 ABNF的收集扩展”，RFC 4466，2006年4月。
[METADATA] Daboo, C., "The IMAP METADATA Extension", RFC 5464, February 2009.
[元数据]Daboo，C.，“IMAP元数据扩展”，RFC 54642009年2月。
[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月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 46462006年9月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[Unicode] "The Unicode Standard 5.0", Unicode 5.0, 2007, <http://www.unicode.org/versions/Unicode5.0.0/>.
[Unicode]“Unicode标准5.0”，Unicode 5.0，2007年<http://www.unicode.org/versions/Unicode5.0.0/>.
Authors' Addresses
作者地址
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司TW12 2BX
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.com
Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
Curtis King Isode Ltd 5城堡商业村英国米德尔塞克斯郡汉普顿车站路36号TW12 2BX
EMail: Curtis.King@isode.com
EMail: Curtis.King@isode.com