1 files changed, 283 insertions, 0 deletions
diff --git a/imap/docs/rfc/rfc5032.txt b/imap/docs/rfc/rfc5032.txt
new file mode 100644
index 00000000..f8e48953
--- /dev/null
+++ b/imap/docs/rfc/rfc5032.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+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]
+