--- /dev/null
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+1. Introduction
+
+ 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.
+
+1.1. Conventions Used in This Document
+
+ In examples, "C:" and "S:" indicate lines sent by the client and
+ server, respectively.
+
+ 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].
+
+
+
+
+
+Burger Standards Track [Page 1]
+\f
+RFC 5032 Search Within September 2007
+
+
+ When describing the general syntax, we omit some definitions, as RFC
+ 3501 [RFC3501] defines them.
+
+2. Protocol Operation
+
+ An IMAP4 server that supports the capability described here MUST
+ return "WITHIN" as one of the server supported capabilities in the
+ CAPABILITY command.
+
+ 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.
+
+ 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.
+
+3. Formal Syntax
+
+ 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].
+
+ This document extends RFC 3501 [RFC3501] with two new search keys:
+ OLDER <interval> and YOUNGER <interval>.
+
+ search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
+ ; search-key defined in RFC 3501
+
+4. Example
+
+ 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.
+
+
+
+
+Burger Standards Track [Page 2]
+\f
+RFC 5032 Search Within September 2007
+
+
+5. Security Considerations
+
+ 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].
+
+6. IANA Considerations
+
+ 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.
+
+7. References
+
+7.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, BCP 14, March 1997.
+
+ [RFC3501] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 3501, March 2003.
+
+ [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 4234, October 2005.
+
+7.2. Informative References
+
+ [CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work
+ in Progress, May 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 3]
+\f
+RFC 5032 Search Within September 2007
+
+
+Appendix A. Contributors
+
+ 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.
+
+Appendix B. Acknowledgements
+
+ 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.
+
+ 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.
+
+Author's Address
+
+ Eric W. Burger (editor)
+ BEA Systems, Inc.
+ USA
+
+ EMail: eric.burger@bea.com
+ URI: http://www.standardstrack.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 4]
+\f
+RFC 5032 Search Within September 2007
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+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.
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Burger Standards Track [Page 5]
+\f
projects / uw-imap / commitdiff