1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc5032.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,283 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                     E. Burger, Ed.
    1.11 +Request for Comments: 5032                             BEA Systems, Inc.
    1.12 +Updates: 3501                                             September 2007
    1.13 +Category: Standards Track
    1.14 +
    1.15 +
    1.16 +              WITHIN Search Extension to the IMAP Protocol
    1.17 +
    1.18 +Status of This Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Abstract
    1.27 +
    1.28 +   This document describes the WITHIN extension to IMAP SEARCH.  IMAP
    1.29 +   SEARCH returns messages whose internal date is within or outside a
    1.30 +   specified interval.  The mechanism described here, OLDER and YOUNGER,
    1.31 +   differs from BEFORE and SINCE in that the client specifies an
    1.32 +   interval, rather than a date.  WITHIN is useful for persistent
    1.33 +   searches where either the device does not have the capacity to
    1.34 +   perform the search at regular intervals or the network is of limited
    1.35 +   bandwidth and thus there is a desire to reduce network traffic from
    1.36 +   sending repeated requests and redundant responses.
    1.37 +
    1.38 +1.  Introduction
    1.39 +
    1.40 +   This extension exposes two new search keys, OLDER and YOUNGER, each
    1.41 +   of which takes a non-zero integer argument corresponding to a time
    1.42 +   interval in seconds.  The server calculates the time of interest by
    1.43 +   subtracting the time interval the client presents from the current
    1.44 +   date and time of the server.  The server then either returns messages
    1.45 +   older or younger than the resultant time and date, depending on the
    1.46 +   search key used.
    1.47 +
    1.48 +1.1.  Conventions Used in This Document
    1.49 +
    1.50 +   In examples, "C:" and "S:" indicate lines sent by the client and
    1.51 +   server, respectively.
    1.52 +
    1.53 +   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    1.54 +   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    1.55 +   document are to be interpreted as described in RFC 2119 [RFC2119].
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Burger                      Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 5032                     Search Within                September 2007
    1.64 +
    1.65 +
    1.66 +   When describing the general syntax, we omit some definitions, as RFC
    1.67 +   3501 [RFC3501] defines them.
    1.68 +
    1.69 +2.  Protocol Operation
    1.70 +
    1.71 +   An IMAP4 server that supports the capability described here MUST
    1.72 +   return "WITHIN" as one of the server supported capabilities in the
    1.73 +   CAPABILITY command.
    1.74 +
    1.75 +   For both the OLDER and YOUNGER search keys, the server calculates a
    1.76 +   target date and time by subtracting the interval, specified in
    1.77 +   seconds, from the current date and time of the server.  The server
    1.78 +   then compares the target time with the INTERNALDATE of the message,
    1.79 +   as specified in IMAP [RFC3501].  For OLDER, messages match if the
    1.80 +   INTERNALDATE is less recent than or equal to the target time.  For
    1.81 +   YOUNGER, messages match if the INTERNALDATE is more recent than or
    1.82 +   equal to the target time.
    1.83 +
    1.84 +   Both OLDER and YOUNGER searches always result in exact matching, to
    1.85 +   the resolution of a second.  However, if one is doing a dynamic
    1.86 +   evaluation, for example, in a context [CONTEXT], one needs to be
    1.87 +   aware that the server might perform the evaluation periodically.
    1.88 +   Thus, the server may delay the updates.  Clients MUST be aware that
    1.89 +   dynamic search results may not reflect the current state of the
    1.90 +   mailbox.  If the client needs a search result that reflects the
    1.91 +   current state of the mailbox, we RECOMMEND that the client issue a
    1.92 +   new search.
    1.93 +
    1.94 +3.  Formal Syntax
    1.95 +
    1.96 +   The following syntax specification uses the Augmented Backus-Naur
    1.97 +   Form (ABNF) notation.  Elements not defined here can be found in the
    1.98 +   formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
    1.99 +
   1.100 +   This document extends RFC 3501 [RFC3501] with two new search keys:
   1.101 +   OLDER <interval> and YOUNGER <interval>.
   1.102 +
   1.103 +   search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
   1.104 +                  ; search-key defined in RFC 3501
   1.105 +
   1.106 +4.  Example
   1.107 +
   1.108 +   C: a1 SEARCH UNSEEN YOUNGER 259200
   1.109 +   S: a1 * SEARCH 4 8 15 16 23 42
   1.110 +
   1.111 +   Search for all unseen messages within the past 3 days, or 259200
   1.112 +   seconds, according to the server's current time.
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Burger                      Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 5032                     Search Within                September 2007
   1.120 +
   1.121 +
   1.122 +5.  Security Considerations
   1.123 +
   1.124 +   The WITHIN extension does not raise any security considerations that
   1.125 +   are not present in the base protocol.  Considerations are the same as
   1.126 +   for IMAP [RFC3501].
   1.127 +
   1.128 +6.  IANA Considerations
   1.129 +
   1.130 +   Per the IMAP RFC [RFC3501], registration of a new IMAP capability in
   1.131 +   the IMAP Capability registry requires the publication of a standards-
   1.132 +   track RFC or an IESG approved experimental RFC.  The registry is
   1.133 +   currently located at
   1.134 +   <http://www.iana.org/assignments/imap4-capabilities>.  This
   1.135 +   standards-track document defines the WITHIN IMAP capability.  IANA
   1.136 +   has added this extension to the IANA IMAP Capability registry.
   1.137 +
   1.138 +7.  References
   1.139 +
   1.140 +7.1.  Normative References
   1.141 +
   1.142 +   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   1.143 +              Requirement Levels", RFC 2119, BCP 14, March 1997.
   1.144 +
   1.145 +   [RFC3501]  Crispin, M., "Internet Message Access Protocol - Version
   1.146 +              4rev1", RFC 3501, March 2003.
   1.147 +
   1.148 +   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
   1.149 +              Specifications: ABNF", RFC 4234, October 2005.
   1.150 +
   1.151 +7.2.  Informative References
   1.152 +
   1.153 +   [CONTEXT]  Melnikov, D. and C. King, "Contexts for IMAP4", Work
   1.154 +              in Progress, May 2006.
   1.155 +
   1.156 +
   1.157 +
   1.158 +
   1.159 +
   1.160 +
   1.161 +
   1.162 +
   1.163 +
   1.164 +
   1.165 +
   1.166 +
   1.167 +
   1.168 +
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Burger                      Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 5032                     Search Within                September 2007
   1.176 +
   1.177 +
   1.178 +Appendix A.  Contributors
   1.179 +
   1.180 +   Stephane Maes and Ray Cromwell wrote the original version of this
   1.181 +   document as part of P-IMAP, as well as the first versions for the
   1.182 +   IETF.  From an attribution perspective, they are clearly authors.
   1.183 +
   1.184 +Appendix B.  Acknowledgements
   1.185 +
   1.186 +   The authors want to thank all who have contributed key insight and
   1.187 +   who have extensively reviewed and discussed the concepts of LPSEARCH.
   1.188 +   They also thank the authors of its early introduction in P-IMAP.
   1.189 +
   1.190 +   We also want to give a special thanks to Arnt Gilbrandsen, Ken
   1.191 +   Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
   1.192 +   review and suggestions.  A special thank you goes to Alexey Melnikov
   1.193 +   for his choice submission of text.
   1.194 +
   1.195 +Author's Address
   1.196 +
   1.197 +   Eric W. Burger (editor)
   1.198 +   BEA Systems, Inc.
   1.199 +   USA
   1.200 +
   1.201 +   EMail: eric.burger@bea.com
   1.202 +   URI:   http://www.standardstrack.com
   1.203 +
   1.204 +
   1.205 +
   1.206 +
   1.207 +
   1.208 +
   1.209 +
   1.210 +
   1.211 +
   1.212 +
   1.213 +
   1.214 +
   1.215 +
   1.216 +
   1.217 +
   1.218 +
   1.219 +
   1.220 +
   1.221 +
   1.222 +
   1.223 +
   1.224 +
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Burger                      Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 5032                     Search Within                September 2007
   1.232 +
   1.233 +
   1.234 +Full Copyright Statement
   1.235 +
   1.236 +   Copyright (C) The IETF Trust (2007).
   1.237 +
   1.238 +   This document is subject to the rights, licenses and restrictions
   1.239 +   contained in BCP 78, and except as set forth therein, the authors
   1.240 +   retain all their rights.
   1.241 +
   1.242 +   This document and the information contained herein are provided on an
   1.243 +   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   1.244 +   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   1.245 +   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   1.246 +   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   1.247 +   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   1.248 +   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.249 +
   1.250 +Intellectual Property
   1.251 +
   1.252 +   The IETF takes no position regarding the validity or scope of any
   1.253 +   Intellectual Property Rights or other rights that might be claimed to
   1.254 +   pertain to the implementation or use of the technology described in
   1.255 +   this document or the extent to which any license under such rights
   1.256 +   might or might not be available; nor does it represent that it has
   1.257 +   made any independent effort to identify any such rights.  Information
   1.258 +   on the procedures with respect to rights in RFC documents can be
   1.259 +   found in BCP 78 and BCP 79.
   1.260 +
   1.261 +   Copies of IPR disclosures made to the IETF Secretariat and any
   1.262 +   assurances of licenses to be made available, or the result of an
   1.263 +   attempt made to obtain a general license or permission for the use of
   1.264 +   such proprietary rights by implementers or users of this
   1.265 +   specification can be obtained from the IETF on-line IPR repository at
   1.266 +   http://www.ietf.org/ipr.
   1.267 +
   1.268 +   The IETF invites any interested party to bring to its attention any
   1.269 +   copyrights, patents or patent applications, or other proprietary
   1.270 +   rights that may cover technology that may be required to implement
   1.271 +   this standard.  Please address the information to the IETF at
   1.272 +   ietf-ipr@ietf.org.
   1.273 +
   1.274 +
   1.275 +
   1.276 +
   1.277 +
   1.278 +
   1.279 +
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Burger                      Standards Track                     [Page 5]
   1.286 +