Network Working Group A. Melnikov
Request for Comments: 5182 Isode Ltd.
Updates: 3501 March 2008
Category: Standards Track
Network Working Group A. Melnikov
Request for Comments: 5182 Isode Ltd.
Updates: 3501 March 2008
Category: Standards Track
IMAP Extension for Referencing the Last SEARCH Result
用于引用上次搜索结果的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
摘要
Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
许多IMAP客户端使用搜索命令的结果作为输入来执行其他操作，例如，获取找到的邮件、删除它们或将它们复制到其他邮箱。
This can be achieved using standard IMAP operations described in RFC 3501; however, this would be suboptimal. The server will send the list of found messages to the client; after that, the client will have to parse the list, reformat it, and send it back to the server. The client can't pipeline the SEARCH command with the subsequent command, and, as a result, the server might not be able to perform some optimizations.
这可以使用RFC 3501中描述的标准IMAP操作来实现；然而，这将是次优的。服务器将向客户端发送找到的消息列表；之后，客户机必须解析列表，重新格式化，然后将其发送回服务器。客户端无法通过管道将搜索命令与后续命令连接起来，因此，服务器可能无法执行某些优化。
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or Unique Identifier (UID) SEARCH) command as an input to any subsequent command.
本文档提出了一个IMAP扩展，允许客户端告诉服务器使用搜索（或唯一标识符（UID）搜索）命令的结果作为任何后续命令的输入。
Many IMAP clients use the result of a SEARCH command as the input to perform another operation, for example, fetching the found messages, deleting them, or copying them to another mailbox.
许多IMAP客户端使用搜索命令的结果作为输入来执行其他操作，例如，获取找到的邮件、删除它们或将它们复制到其他邮箱。
This document proposes an IMAP extension that allows a client to tell a server to use the result of a SEARCH (or UID SEARCH) command as an input to any subsequent command.
本文档提出了一个IMAP扩展，允许客户端告诉服务器使用搜索（或UID搜索）命令的结果作为任何后续命令的输入。
The SEARCH result reference extension defines a new SEARCH result option [IMAPABNF] "SAVE" that tells the server to remember the result of the SEARCH or UID SEARCH command (as well as any command based on SEARCH, e.g., SORT and THREAD [SORT]) and store it in an internal
搜索结果引用扩展定义了一个新的搜索结果选项[IMAPABNF]“SAVE”，它告诉服务器记住搜索或UID搜索命令（以及基于搜索的任何命令，例如SORT和THREAD[SORT]）的结果，并将其存储在内部
variable that we will reference as the "search result variable". The client can use the "$" marker to reference the content of this internal variable. The "$" marker can be used instead of message sequence or UID sequence in order to indicate that the server should substitute it with the list of messages from the search result variable. Thus, the client can use the result of the latest remembered SEARCH command as a parameter to another command. The search result marker has several advantages:
我们将引用为“搜索结果变量”的变量。客户端可以使用“$”标记来引用此内部变量的内容。可以使用“$”标记代替消息序列或UID序列，以指示服务器应将其替换为搜索结果变量中的消息列表。因此，客户机可以使用最新记忆的搜索命令的结果作为另一个命令的参数。搜索结果标记有几个优点：
* it avoids wasted bandwidth and associated delay;
* 它避免了浪费带宽和相关延迟；
* it allows the client to pipeline a SEARCH [IMAP4] command with a subsequent FETCH/STORE/COPY/SEARCH [IMAP4] or UID EXPUNGE [UIDPLUS] command;
* 它允许客户端将搜索[IMAP4]命令与后续的FETCH/STORE/COPY/SEARCH[IMAP4]或UID EXPUNGE[UIDPLUS]命令通过管道传输；
* the client doesn't need to spend time reformatting the result of a SEARCH command into a message set used in the subsequent command;
* 客户端不需要花费时间将搜索命令的结果重新格式化为后续命令中使用的消息集；
* it allows the server to perform optimizations. For example, if the server can execute several pipelined commands in parallel (or out of order), presence of the search result marker can allow the server to decide which commands may or may not be executed out of order.
* 它允许服务器执行优化。例如，如果服务器可以并行（或无序）执行多个流水线命令，则搜索结果标记的存在可以允许服务器决定哪些命令可以无序执行，哪些命令不可以无序执行。
In absence of any other SEARCH result option, the SAVE result option also suppresses any SEARCH response that would have been otherwise returned by the SEARCH command.
在没有任何其他搜索结果选项的情况下，“保存结果”选项还将禁止搜索命令以其他方式返回的任何搜索响应。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
在示例中，“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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Explanatory comments in examples start with // and are not part of the protocol.
示例中的解释性注释以//开头，不属于协议的一部分。
The SEARCH result reference extension described in this document is present in any IMAP4 server implementation that returns "SEARCHRES" as one of the supported capabilities in the CAPABILITY command response. Any such server MUST also implement the [ESEARCH] extension.
本文档中描述的搜索结果引用扩展存在于任何IMAP4服务器实现中，该实现将“SEARCHRES”作为CAPABILITY命令响应中支持的功能之一返回。任何此类服务器还必须实现[ESEARCH]扩展。
Upon successful completion of a SELECT or an EXAMINE command (after the tagged OK response), the current search result variable is reset to the empty sequence.
成功完成SELECT或EXAMINE命令后（在标记的OK响应之后），当前搜索结果变量将重置为空序列。
A successful SEARCH command with the SAVE result option sets the value of the search result variable to the list of messages found in the SEARCH command. For example, if no messages were found, the search result variable will contain the empty list.
带有“保存结果”选项的成功搜索命令将搜索结果变量的值设置为搜索命令中找到的消息列表。例如，如果未找到任何消息，则搜索结果变量将包含空列表。
Any of the following SEARCH commands MUST NOT change the search result variable:
以下任何搜索命令不得更改搜索结果变量：
o a SEARCH command that caused the server to return the BAD tagged response,
o 导致服务器返回错误标记响应的搜索命令，
o a SEARCH command with no SAVE result option that caused the server to return NO tagged response,
o 不带“保存结果”选项的搜索命令，导致服务器不返回带标记的响应，
o a successful SEARCH command with no SAVE result option.
o 没有保存结果选项的成功搜索命令。
A SEARCH command with the SAVE result option that caused the server to return the NO tagged response sets the value of the search result variable to the empty sequence.
带有“保存结果”选项的搜索命令导致服务器返回无标记响应，该命令将搜索结果变量的值设置为空序列。
When a message listed in the search result variable is EXPUNGEd, it is automatically removed from the list. Implementors are reminded that if the server stores the list as a list of message numbers, it MUST automatically adjust them when notifying the client about expunged messages, as described in Section 7.4.1 of [IMAP4].
删除搜索结果变量中列出的消息时，该消息将自动从列表中删除。提醒实施者，如果服务器将列表存储为消息编号列表，则必须在通知客户端已删除消息时自动调整列表，如[IMAP4]第7.4.1节所述。
If the server decides to send a new UIDVALIDITY value while the mailbox is opened, this causes resetting of the search variable to the empty list.
如果服务器决定在打开邮箱时发送新的UIDVality值，则会导致将搜索变量重置为空列表。
Note that even if the "$" marker contains the empty list of messages, it must be treated by all commands accepting message sets as parameters as a valid, but non-matching list of messages. For example, the "FETCH $" command would return a tagged OK response and no FETCH responses. See also the Example 5 below.
请注意，即使“$”标记包含空的消息列表，所有接受消息集作为参数的命令都必须将其视为有效但不匹配的消息列表。例如，“FETCH$”命令将返回带标记的OK响应和no FETCH响应。另请参见下面的示例5。
Note that even if the "$" marker contains the empty list of messages, it must be treated as a valid but non-matching list of messages, by all commands that accept message sets as parameters.
请注意，即使“$”标记包含空的消息列表，所有接受消息集作为参数的命令也必须将其视为有效但不匹配的消息列表。
Implementation note: server implementors should note that "$" can reference IMAP message sequences or UID sequences, depending on the context where it is used. For example, the "$" marker can be set as a result of a SEARCH (SAVE) command and used as a parameter to a UID FETCH command (which accepts a UID sequence, not a message sequence), or the "$" marker can be set as a result of a UID SEARCH (SAVE) command and used as a parameter to a FETCH command (which accepts a message sequence, not a UID sequence).
实现说明：服务器实现人员应该注意，“$”可以引用IMAP消息序列或UID序列，具体取决于使用它的上下文。例如，“$”标记可以设置为搜索（保存）命令的结果，并用作UID FETCH命令（接受UID序列而不是消息序列）的参数；或者，“$”标记可以设置为UID搜索（保存）命令的结果，并用作FETCH命令（接受消息序列而不是UID序列）的参数.
1) The following example demonstrates how the client can use the result of a SEARCH command to FETCH headers of interesting messages:
1) 以下示例演示了客户端如何使用搜索命令的结果获取感兴趣消息的标题：
Example 1:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
S: A282 OK SEARCH completed, result saved
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
Example 1:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
S: A282 OK SEARCH completed, result saved
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
The client can also pipeline the two commands:
客户端还可以通过管道传输这两个命令：
Example 2:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: A282 OK SEARCH completed
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
Example 2:
C: A282 SEARCH RETURN (SAVE) FLAGGED SINCE 1-Feb-1994
NOT FROM "Smith"
C: A283 FETCH $ (UID INTERNALDATE FLAGS RFC822.HEADER)
S: A282 OK SEARCH completed
S: * 2 FETCH (UID 14 ...
S: * 84 FETCH (UID 100 ...
S: * 882 FETCH (UID 1115 ...
S: A283 OK completed
2) The following example demonstrates that the result of one SEARCH command can be used as input to another SEARCH command:
2) 以下示例演示了一个搜索命令的结果可以用作另一个搜索命令的输入：
Example 3:
C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
NOT FROM "Smith"
S: A300 OK SEARCH completed
C: A301 UID SEARCH UID $ SMALLER 4096
S: * SEARCH 17 900 901
S: A301 OK completed
Example 3:
C: A300 SEARCH RETURN (SAVE) SINCE 1-Jan-2004
NOT FROM "Smith"
S: A300 OK SEARCH completed
C: A301 UID SEARCH UID $ SMALLER 4096
S: * SEARCH 17 900 901
S: A301 OK completed
Note that the second command in Example 3 can be replaced with: C: A301 UID SEARCH $ SMALLER 4096 and the result of the command would be the same.
请注意，示例3中的第二个命令可以替换为：C:A301 UID SEARCH$SMALLER 4096，并且该命令的结果将是相同的。
3) The following example shows that the "$" marker can be combined with other message numbers using the OR SEARCH criterion.
3) 下面的示例显示，可以使用OR搜索条件将“$”标记与其他邮件编号组合。
Example 4:
C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith"
S: P282 OK SEARCH completed
C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8}
C: YYYYYYYY
S: * SEARCH 882 1102 3003 3005 3006
S: P283 OK completed
Example 4:
C: P282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith"
S: P282 OK SEARCH completed
C: P283 SEARCH CHARSET UTF-8 (OR $ 1,3000:3021) TEXT {8}
C: YYYYYYYY
S: * SEARCH 882 1102 3003 3005 3006
S: P283 OK completed
Note: Since this document format is restricted to 7-bit ASCII text, it is not possible to show actual UTF-8 data. The "YYYYYYYY" is a placeholder for what would be 8 octets of 8-bit data in an actual transaction.
注：由于此文档格式仅限于7位ASCII文本，因此无法显示实际的UTF-8数据。“yyyyyy”是实际事务中8位数据的8个八位字节的占位符。
4) The following example demonstrates that a failed SEARCH sets the search result variable to the empty list.
4) 以下示例演示了失败的搜索将搜索结果变量设置为空列表。
Example 5:
C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith"
S: B282 OK SEARCH completed
C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4}
C: XXXX
S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
//After this command the saved result variable contains
//no messages. A client that wants to reissue the B283
//SEARCH command with another CHARSET would have to reissue
//the B282 command as well. One possible workaround for
//this is to include the desired CHARSET parameter
//in the earliest SEARCH RETURN (SAVE) command in a
//sequence of related SEARCH commands.
//A better approach might be to always use CHARSET UTF-8
//instead.
Example 5:
C: B282 SEARCH RETURN (SAVE) SINCE 1-Feb-1994
NOT FROM "Smith"
S: B282 OK SEARCH completed
C: B283 SEARCH CHARSET KOI8-R (OR $ 1,3000:3021) TEXT {4}
C: XXXX
S: B283 NO [BADCHARSET UTF-8] KOI8-R is not supported
//After this command the saved result variable contains
//no messages. A client that wants to reissue the B283
//SEARCH command with another CHARSET would have to reissue
//the B282 command as well. One possible workaround for
//this is to include the desired CHARSET parameter
//in the earliest SEARCH RETURN (SAVE) command in a
//sequence of related SEARCH commands.
//A better approach might be to always use CHARSET UTF-8
//instead.
Note: Since this document format is restricted to 7-bit ASCII text, it is not possible to show actual KOI8-R data. The "XXXX" is a placeholder for what would be 4 octets of 8-bit data in an actual transaction.
注：由于此文档格式仅限于7位ASCII文本，因此无法显示实际的KOI8-R数据。“XXXX”是实际事务中8位数据的4个八位字节的占位符。
5) The following example demonstrates that it is not an error to use the "$" marker when it contains no messages.
5) 下面的示例演示在“$”标记不包含任何消息时使用它不是错误。
Example 6:
C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
NOT FROM "Eric"
C: E283 COPY $ "Other Messages"
//The "$" contains no messages
S: E282 OK SEARCH completed
S: E283 OK COPY completed, nothing copied
Example 6:
C: E282 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
NOT FROM "Eric"
C: E283 COPY $ "Other Messages"
//The "$" contains no messages
S: E282 OK SEARCH completed
S: E283 OK COPY completed, nothing copied
Use of a SEARCH RETURN (SAVE) command followed by a command using the "$" marker creates direct dependency between the two commands. As directed by Section 5.5 of [IMAP4], a server MUST execute the two commands in the order they were received. (A server capable of out-of-order execution can in some cases execute the two commands in parallel, for example, if a SEARCH RETURN (SAVE) is followed by "SEARCH $", the search criteria from the first command can be directly substituted into the second command.)
使用搜索返回（SAVE）命令，然后使用“$”标记创建两个命令之间的直接依赖关系。按照[IMAP4]第5.5节的指示，服务器必须按照接收的顺序执行这两个命令。（在某些情况下，能够无序执行的服务器可以并行执行两个命令，例如，如果搜索返回（SAVE）后跟“SEARCH$”，则第一个命令中的搜索条件可以直接替换为第二个命令。）
A client supporting this extension MAY pipeline a SEARCH RETURN (SAVE) command with one or more command using the "$" marker, as long as this doesn't create an ambiguity, as described in Section 5.5 of [IMAP4].
如[IMAP4]第5.5节所述，支持此扩展的客户端可以使用“$”标记将搜索返回（保存）命令与一个或多个命令通过管道传输，只要这不会产生歧义。
Example 7:
C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: F283 COPY $ "Junk"
C: F284 STORE $ +FLAGS.Silent (\Deleted)
S: F282 OK SEARCH completed
S: F283 OK COPY completed
S: F284 OK STORE completed
Example 7:
C: F282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: F283 COPY $ "Junk"
C: F284 STORE $ +FLAGS.Silent (\Deleted)
S: F282 OK SEARCH completed
S: F283 OK COPY completed
S: F284 OK STORE completed
Example 8:
C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006
FROM "Eric"
//The server can execute the two SEARCH commands
//in any order, as they don't have any dependency.
//Note that the second command is making use of
//the [ESEARCH] extension.
S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103
S: G283 OK SEARCH completed
S: G282 OK SEARCH completed
Example 8:
C: G282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: G283 SEARCH RETURN (ALL) SINCE 28-Oct-2006
FROM "Eric"
//The server can execute the two SEARCH commands
//in any order, as they don't have any dependency.
//Note that the second command is making use of
//the [ESEARCH] extension.
S: * ESEARCH (TAG "G283") ALL 3:15,27,29:103
S: G283 OK SEARCH completed
S: G282 OK SEARCH completed
The following example demonstrates that the result of the second SEARCH always overrides the result of the first.
以下示例演示了第二次搜索的结果始终覆盖第一次搜索的结果。
Example 9:
C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
FROM "Eric"
S: H282 OK SEARCH completed
S: H283 OK SEARCH completed
Example 9:
C: H282 SEARCH RETURN (SAVE) KEYWORD $Junk
C: H283 SEARCH RETURN (SAVE) SINCE 28-Oct-2006
FROM "Eric"
S: H282 OK SEARCH completed
S: H283 OK SEARCH completed
Servers that implement the extension defined in this document MUST implement [ESEARCH] and conform to additional requirements listed in this section.
实现本文档中定义的扩展的服务器必须实现[ESEARCH]，并符合本节中列出的其他要求。
The SAVE result option doesn't change whether the server would return items corresponding to MIN, MAX, ALL, or COUNT [ESEARCH] result options.
“保存结果”选项不会更改服务器是否返回与“最小”、“最大”、“全部”或“计数[ESEARCH]结果”选项相对应的项目。
When the SAVE result option is combined with the MIN or MAX [ESEARCH] result option, and none of the other ESEARCH result options are present, the corresponding MIN/MAX is returned (if the search result is not empty), but the "$" marker would contain a single message as returned in the MIN/MAX return item.
当“保存结果”选项与“最小”或“最大[ESEARCH]结果”选项组合，且其他ESEARCH结果选项均不存在时，将返回相应的“最小值/最大值”（如果搜索结果不为空），但“$”标记将包含在“最小值/最大值”返回项中返回的单个消息。
If the SAVE result option is combined with both MIN and MAX result options, and none of the other ESEARCH result options are present, the "$" marker would contain one or two messages as returned in the MIN/MAX return items.
如果“保存结果”选项与“最小结果”和“最大结果”选项结合使用，而其他ESEARCH结果选项均不存在，则“$”标记将包含一条或两条在“最小/最大返回”项中返回的消息。
If the SAVE result option is combined with the ALL and/or COUNT result option(s), the "$" marker would always contain all messages found by the SEARCH or UID SEARCH command. (Note that the last rule might affect ESEARCH implementations that optimize how the COUNT result is constructed.)
如果SAVE result选项与ALL和/或COUNT result选项结合使用，“$”标记将始终包含SEARCH或UID SEARCH命令找到的所有消息。（请注意，最后一条规则可能会影响优化计数结果构造方式的ESEARCH实现。）
The following table summarizes the additional requirement on ESEARCH server implementations described in this section.
下表总结了本节中描述的对ESEARCH服务器实现的附加要求。
+----------------+-------------------+
| Combination of | "$" marker value |
| Result option | |
+----------------+-------------------+
| SAVE MIN | MIN |
+----------------+-------------------+
| SAVE MAX | MAX |
+----------------+-------------------+
| SAVE MIN MAX | MIN & MAX |
+----------------+-------------------+
| SAVE * [m] | all found messages|
+----------------+-------------------+
+----------------+-------------------+
| Combination of | "$" marker value |
| Result option | |
+----------------+-------------------+
| SAVE MIN | MIN |
+----------------+-------------------+
| SAVE MAX | MAX |
+----------------+-------------------+
| SAVE MIN MAX | MIN & MAX |
+----------------+-------------------+
| SAVE * [m] | all found messages|
+----------------+-------------------+
where '*' means "ALL" and/or "COUNT" '[m]' means optional "MIN" and/or "MAX"
其中“*”表示“全部”和/或“计数”“[m]”表示可选的“最小”和/或“最大”
The following example demonstrates behavioral difference for different combinations of ESEARCH result options. Explanatory comments start with // and are not part of the protocol:
下面的示例演示了ESEARCH结果选项的不同组合的行为差异。解释性注释以//开头，不属于协议的一部分：
Example 10:
C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value hasn't changed
S: C282 OK SEARCH completed
Example 10:
C: C282 SEARCH RETURN (ALL) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value hasn't changed
S: C282 OK SEARCH completed
C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value is 2,10:15,21
S: C283 OK SEARCH completed
C: C283 SEARCH RETURN (ALL SAVE) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C283") ALL 2,10:15,21
//$ value is 2,10:15,21
S: C283 OK SEARCH completed
C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C284") MIN 2
//$ value is 2
S: C284 OK SEARCH completed
C: C284 SEARCH RETURN (SAVE MIN) SINCE 12-Feb-2006
NOT FROM "Smith"
S: * ESEARCH (TAG "C284") MIN 2
//$ value is 2
S: C284 OK SEARCH completed
C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE
12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C285") MIN 2 MAX 21
//$ value is 2,21
S: C285 OK SEARCH completed
C: C285 SEARCH RETURN (MAX SAVE MIN) SINCE
12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C285") MIN 2 MAX 21
//$ value is 2,21
S: C285 OK SEARCH completed
C: C286 SEARCH RETURN (MAX SAVE MIN COUNT)
SINCE 12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8
//$ value is 2,10:15,21
S: C286 OK SEARCH completed
C: C286 SEARCH RETURN (MAX SAVE MIN COUNT)
SINCE 12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C286") MIN 2 MAX 21 COUNT 8
//$ value is 2,10:15,21
S: C286 OK SEARCH completed
C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE
12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21
//$ value is 2,10:15,21
S: C286 OK SEARCH completed
C: C286 SEARCH RETURN (ALL SAVE MIN) SINCE
12-Feb-2006 NOT FROM "Smith"
S: * ESEARCH (TAG "C286") MIN 2 ALL 2,10:15,21
//$ value is 2,10:15,21
S: C286 OK SEARCH completed
In some cases, the server MAY refuse to save a SEARCH (SAVE) result, for example, if an internal limit on the number of saved results is reached.
在某些情况下，服务器可能会拒绝保存搜索（保存）结果，例如，如果已保存结果的数量达到内部限制。
In this case, the server MUST return a tagged NO response containing the NOTSAVED response code and set the search result variable to the empty sequence, as described in Section 2.1.
在这种情况下，服务器必须返回一个包含NOTSAVED响应代码的标记NO响应，并将搜索结果变量设置为空序列，如第2.1节所述。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. Non-terminals referenced but not defined below are as defined in [IMAP4] or [IMAPABNF].
以下语法规范使用[ABNF]中指定的增广Backus Naur Form（ABNF）表示法。以下引用但未定义的非端子如[IMAP4]或[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 =/ "SEARCHRES"
;; capability is defined in [IMAP4]
capability =/ "SEARCHRES"
;; capability is defined in [IMAP4]
sequence-set =/ seq-last-command ;; extends sequence-set to allow for ;; "result of the last command" indicator.
序列集=/seq last命令；；扩展序列集以允许；；“最后一个命令的结果”指示器。
seq-last-command = "$"
seq last command=“$”
search-return-opt = "SAVE"
;; conforms to generic search-return-opt
;; syntax defined in [IMAPABNF]
search-return-opt = "SAVE"
;; conforms to generic search-return-opt
;; syntax defined in [IMAPABNF]
resp-text-code =/ "NOTSAVED"
;; <resp-text-code> from [IMAP4]
resp-text-code =/ "NOTSAVED"
;; <resp-text-code> from [IMAP4]
This extension requires the server to keep additional state, that may be used to simplify Denial of Service attacks. In order to minimize damage from such attacks, server implementations MAY limit the number of saved searches they allow across all connections at any given time and return the tagged NO response containing the NOTSAVED response code (see Section 2.5) to a SEARCH RETURN (SAVE) command when this limit is exceeded.
此扩展要求服务器保留其他状态，这些状态可用于简化拒绝服务攻击。为了最大限度地减少此类攻击造成的损害，服务器实现可能会限制在任何给定时间允许在所有连接上进行的已保存搜索的数量，并在超过此限制时将包含NOTSAVED响应代码（请参见第2.5节）的标记无响应返回给搜索返回（SAVE）命令。
Apart from that, it is believed that this extension doesn't raise any additional security concerns not already discussed in [IMAP4].
除此之外，据信此扩展不会引起[IMAP4]中未讨论的任何其他安全问题。
This document defines the "SEARCHRES" IMAP capability. IANA has added it to the IMAP4 Capabilities Registry, which is currently located at:
本文档定义了“SEARCHRES”IMAP功能。IANA已将其添加到IMAP4功能注册表中，该注册表当前位于：
http://www.iana.org/assignments/imap4-capabilities
http://www.iana.org/assignments/imap4-capabilities
The author would like to thank Mark Crispin, Cyrus Daboo, and Curtis King for remembering that this document had to be written, as well as for comments and corrections received.
作者要感谢马克·克里斯宾、塞勒斯·达布和柯蒂斯·金，感谢他们记住本文件必须编写，以及收到的评论和更正。
The author would also like to thank Dave Cridland, Mark Crispin, Chris Newman, Dan Karp, and Spencer Dawkins for comments and corrections received.
作者还要感谢Dave Cridland、Mark Crispin、Chris Newman、Dan Karp和Spencer Dawkins的评论和更正。
Valuable comments, both in agreement and in dissent, were received from Arnt Gulbrandsen.
阿恩特·古尔布兰森（Arnt Gulbrandsen）提出了宝贵的意见，无论是一致意见还是不同意见。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[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月。
[ESEARCH] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.
[ESEARCH]Melnikov，A.和D.Cridland，“用于控制返回何种信息的搜索命令的IMAP4扩展”，RFC 47312006年11月。
[UIDPLUS] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, December 2005.
[UIDPLUS]Crispin，M.，“互联网消息访问协议（IMAP）-UIDPLUS扩展”，RFC 4315，2005年12月。
[SORT] Crispin, M. and K. Murchison, "INTERNET MESSAGE ACCESS PROTOCOL - SORT AND THREAD EXTENSIONS", Work in Progress, Septemeber 2007.
[SORT]Crispin，M.和K.Murchison，“互联网消息访问协议-排序和线程扩展”，正在进行的工作，2007年9月。
Author's Address
作者地址
Alexey Melnikov Isode Ltd. 5 Castle Business Village, 36 Station Road, Hampton, Middlesex, TW12 2BX, United Kingdom
英国TW12 2BX米德尔塞克斯汉普顿车站路36号城堡商业村5号Alexey Melnikov Isode有限公司
EMail: Alexey.Melnikov@isode.com
EMail: Alexey.Melnikov@isode.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.