diff options
Diffstat (limited to 'imap/docs/rfc/rfc5032.txt')
| -rw-r--r-- | imap/docs/rfc/rfc5032.txt | 283 |
1 files changed, 0 insertions, 283 deletions
diff --git a/imap/docs/rfc/rfc5032.txt b/imap/docs/rfc/rfc5032.txt deleted file mode 100644 index f8e48953..00000000 --- a/imap/docs/rfc/rfc5032.txt +++ /dev/null @@ -1,283 +0,0 @@ - - - - - - -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] - -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] - -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] - -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] - -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] - |