Network Working Group E. Burger, Ed.
Request for Comments: 5032 BEA Systems, Inc.
Updates: 3501 September 2007
Category: Standards Track
Network Working Group E. Burger, Ed.
Request for Comments: 5032 BEA Systems, Inc.
Updates: 3501 September 2007
Category: Standards Track
WITHIN Search Extension to the IMAP Protocol
在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
摘要
This document describes the WITHIN extension to IMAP SEARCH. IMAP SEARCH returns messages whose internal date is within or outside a specified interval. The mechanism described here, OLDER and YOUNGER, differs from BEFORE and SINCE in that the client specifies an interval, rather than a date. WITHIN is useful for persistent searches where either the device does not have the capacity to perform the search at regular intervals or the network is of limited bandwidth and thus there is a desire to reduce network traffic from sending repeated requests and redundant responses.
本文档介绍了IMAP搜索的扩展。IMAP搜索返回内部日期在指定间隔内或之外的消息。这里描述的机制，不管是老机制还是年轻机制，都不同于以前，因为客户机指定的是一个时间间隔，而不是一个日期。在设备没有能力以固定间隔执行搜索或网络带宽有限的情况下，内搜索对于持久搜索非常有用，因此希望通过发送重复请求和冗余响应来减少网络流量。
This extension exposes two new search keys, OLDER and YOUNGER, each of which takes a non-zero integer argument corresponding to a time interval in seconds. The server calculates the time of interest by subtracting the time interval the client presents from the current date and time of the server. The server then either returns messages older or younger than the resultant time and date, depending on the search key used.
这个扩展公开了两个新的搜索键，一个旧的和一个新的，每一个都接受一个非零整数参数，对应于以秒为单位的时间间隔。服务器通过从服务器的当前日期和时间中减去客户端显示的时间间隔来计算感兴趣的时间。然后，服务器返回比结果时间和日期早或早的消息，具体取决于使用的搜索键。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
When describing the general syntax, we omit some definitions, as RFC 3501 [RFC3501] defines them.
在描述一般语法时，我们省略了一些定义，因为RFC 3501[RFC3501]定义了它们。
An IMAP4 server that supports the capability described here MUST return "WITHIN" as one of the server supported capabilities in the CAPABILITY command.
支持此处所述功能的IMAP4服务器必须在capability命令中将“in”作为服务器支持的功能之一返回。
For both the OLDER and YOUNGER search keys, the server calculates a target date and time by subtracting the interval, specified in seconds, from the current date and time of the server. The server then compares the target time with the INTERNALDATE of the message, as specified in IMAP [RFC3501]. For OLDER, messages match if the INTERNALDATE is less recent than or equal to the target time. For YOUNGER, messages match if the INTERNALDATE is more recent than or equal to the target time.
对于较旧和较新的搜索键，服务器通过从服务器的当前日期和时间中减去以秒为单位指定的间隔来计算目标日期和时间。然后，服务器将目标时间与消息的内部日期进行比较，如IMAP[RFC3501]中所述。对于较旧的，如果INTERNALDATE小于或等于目标时间，则消息匹配。对于年轻人，如果INTERNALDATE比目标时间最近或等于目标时间，则消息匹配。
Both OLDER and YOUNGER searches always result in exact matching, to the resolution of a second. However, if one is doing a dynamic evaluation, for example, in a context [CONTEXT], one needs to be aware that the server might perform the evaluation periodically. Thus, the server may delay the updates. Clients MUST be aware that dynamic search results may not reflect the current state of the mailbox. If the client needs a search result that reflects the current state of the mailbox, we RECOMMEND that the client issue a new search.
无论是较旧的搜索还是较年轻的搜索，都会得到精确匹配，分辨率为一秒。但是，如果要进行动态评估，例如，在上下文[context]中，则需要注意服务器可能会定期执行评估。因此，服务器可能会延迟更新。客户端必须知道，动态搜索结果可能无法反映邮箱的当前状态。如果客户端需要反映邮箱当前状态的搜索结果，建议客户端进行新的搜索。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation. Elements not defined here can be found in the formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
以下语法规范使用增广的Backus-Naur形式（ABNF）表示法。这里未定义的元素可以在ABNF[RFC4234]和IMAP[RFC3501]的形式语法中找到。
This document extends RFC 3501 [RFC3501] with two new search keys: OLDER <interval> and YOUNGER <interval>.
本文档使用两个新的搜索键扩展了RFC 3501[RFC3501]：OLDER<interval>和YOUNGER<interval>。
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
; search-key defined in RFC 3501
search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
; search-key defined in RFC 3501
C: a1 SEARCH UNSEEN YOUNGER 259200
S: a1 * SEARCH 4 8 15 16 23 42
C: a1 SEARCH UNSEEN YOUNGER 259200
S: a1 * SEARCH 4 8 15 16 23 42
Search for all unseen messages within the past 3 days, or 259200 seconds, according to the server's current time.
根据服务器的当前时间，搜索过去3天或259200秒内所有未看到的邮件。
The WITHIN extension does not raise any security considerations that are not present in the base protocol. Considerations are the same as for IMAP [RFC3501].
内部扩展不会引起基本协议中不存在的任何安全注意事项。注意事项与IMAP[RFC3501]相同。
Per the IMAP RFC [RFC3501], registration of a new IMAP capability in the IMAP Capability registry requires the publication of a standards-track RFC or an IESG approved experimental RFC. The registry is currently located at <http://www.iana.org/assignments/imap4-capabilities>. This standards-track document defines the WITHIN IMAP capability. IANA has added this extension to the IANA IMAP Capability registry.
根据IMAP RFC[RFC3501]，在IMAP能力注册表中注册新IMAP能力需要发布标准轨道RFC或IESG批准的实验RFC。注册处目前位于<http://www.iana.org/assignments/imap4-capabilities>. 本标准跟踪文档定义了IMAP内的功能。IANA已将此扩展添加到IANA IMAP功能注册表中。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[RFC3501] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work in Progress, May 2006.
[背景]Melnikov，D.和C.King，“IMAP4的背景”，进展中的工作，2006年5月。
Stephane Maes and Ray Cromwell wrote the original version of this document as part of P-IMAP, as well as the first versions for the IETF. From an attribution perspective, they are clearly authors.
Stephane Maes和Ray Cromwell编写了本文件的原始版本，作为P-IMAP的一部分，以及IETF的第一个版本。从归因的角度来看，他们显然是作者。
The authors want to thank all who have contributed key insight and who have extensively reviewed and discussed the concepts of LPSEARCH. They also thank the authors of its early introduction in P-IMAP.
作者要感谢所有对LPSEARCH做出重要贡献的人，感谢他们对LPSEARCH的概念进行了广泛的回顾和讨论。他们还感谢在P-IMAP中早期介绍它的作者。
We also want to give a special thanks to Arnt Gilbrandsen, Ken Murchison, Zoltan Ordogh, and most especially Dave Cridland for their review and suggestions. A special thank you goes to Alexey Melnikov for his choice submission of text.
我们还要特别感谢Arnt Gilbrandsen、Ken Murchison、Zoltan Ordogh，尤其是Dave Cridland的评论和建议。特别感谢阿列克谢·梅尔尼科夫选择提交文本。
Author's Address
作者地址
Eric W. Burger (editor) BEA Systems, Inc. USA
Eric W.Burger（编辑）美国BEA系统公司
EMail: eric.burger@bea.com
URI: http://www.standardstrack.com
EMail: eric.burger@bea.com
URI: http://www.standardstrack.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.