imapext-2007

annotate docs/rfc/rfc5032.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group E. Burger, Ed.
yuuji@0 8 Request for Comments: 5032 BEA Systems, Inc.
yuuji@0 9 Updates: 3501 September 2007
yuuji@0 10 Category: Standards Track
yuuji@0 11
yuuji@0 12
yuuji@0 13 WITHIN Search Extension to the IMAP Protocol
yuuji@0 14
yuuji@0 15 Status of This Memo
yuuji@0 16
yuuji@0 17 This document specifies an Internet standards track protocol for the
yuuji@0 18 Internet community, and requests discussion and suggestions for
yuuji@0 19 improvements. Please refer to the current edition of the "Internet
yuuji@0 20 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 21 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 22
yuuji@0 23 Abstract
yuuji@0 24
yuuji@0 25 This document describes the WITHIN extension to IMAP SEARCH. IMAP
yuuji@0 26 SEARCH returns messages whose internal date is within or outside a
yuuji@0 27 specified interval. The mechanism described here, OLDER and YOUNGER,
yuuji@0 28 differs from BEFORE and SINCE in that the client specifies an
yuuji@0 29 interval, rather than a date. WITHIN is useful for persistent
yuuji@0 30 searches where either the device does not have the capacity to
yuuji@0 31 perform the search at regular intervals or the network is of limited
yuuji@0 32 bandwidth and thus there is a desire to reduce network traffic from
yuuji@0 33 sending repeated requests and redundant responses.
yuuji@0 34
yuuji@0 35 1. Introduction
yuuji@0 36
yuuji@0 37 This extension exposes two new search keys, OLDER and YOUNGER, each
yuuji@0 38 of which takes a non-zero integer argument corresponding to a time
yuuji@0 39 interval in seconds. The server calculates the time of interest by
yuuji@0 40 subtracting the time interval the client presents from the current
yuuji@0 41 date and time of the server. The server then either returns messages
yuuji@0 42 older or younger than the resultant time and date, depending on the
yuuji@0 43 search key used.
yuuji@0 44
yuuji@0 45 1.1. Conventions Used in This Document
yuuji@0 46
yuuji@0 47 In examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 48 server, respectively.
yuuji@0 49
yuuji@0 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
yuuji@0 52 document are to be interpreted as described in RFC 2119 [RFC2119].
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Burger Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 5032 Search Within September 2007
yuuji@0 61
yuuji@0 62
yuuji@0 63 When describing the general syntax, we omit some definitions, as RFC
yuuji@0 64 3501 [RFC3501] defines them.
yuuji@0 65
yuuji@0 66 2. Protocol Operation
yuuji@0 67
yuuji@0 68 An IMAP4 server that supports the capability described here MUST
yuuji@0 69 return "WITHIN" as one of the server supported capabilities in the
yuuji@0 70 CAPABILITY command.
yuuji@0 71
yuuji@0 72 For both the OLDER and YOUNGER search keys, the server calculates a
yuuji@0 73 target date and time by subtracting the interval, specified in
yuuji@0 74 seconds, from the current date and time of the server. The server
yuuji@0 75 then compares the target time with the INTERNALDATE of the message,
yuuji@0 76 as specified in IMAP [RFC3501]. For OLDER, messages match if the
yuuji@0 77 INTERNALDATE is less recent than or equal to the target time. For
yuuji@0 78 YOUNGER, messages match if the INTERNALDATE is more recent than or
yuuji@0 79 equal to the target time.
yuuji@0 80
yuuji@0 81 Both OLDER and YOUNGER searches always result in exact matching, to
yuuji@0 82 the resolution of a second. However, if one is doing a dynamic
yuuji@0 83 evaluation, for example, in a context [CONTEXT], one needs to be
yuuji@0 84 aware that the server might perform the evaluation periodically.
yuuji@0 85 Thus, the server may delay the updates. Clients MUST be aware that
yuuji@0 86 dynamic search results may not reflect the current state of the
yuuji@0 87 mailbox. If the client needs a search result that reflects the
yuuji@0 88 current state of the mailbox, we RECOMMEND that the client issue a
yuuji@0 89 new search.
yuuji@0 90
yuuji@0 91 3. Formal Syntax
yuuji@0 92
yuuji@0 93 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 94 Form (ABNF) notation. Elements not defined here can be found in the
yuuji@0 95 formal syntax of ABNF [RFC4234] and IMAP [RFC3501].
yuuji@0 96
yuuji@0 97 This document extends RFC 3501 [RFC3501] with two new search keys:
yuuji@0 98 OLDER <interval> and YOUNGER <interval>.
yuuji@0 99
yuuji@0 100 search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number
yuuji@0 101 ; search-key defined in RFC 3501
yuuji@0 102
yuuji@0 103 4. Example
yuuji@0 104
yuuji@0 105 C: a1 SEARCH UNSEEN YOUNGER 259200
yuuji@0 106 S: a1 * SEARCH 4 8 15 16 23 42
yuuji@0 107
yuuji@0 108 Search for all unseen messages within the past 3 days, or 259200
yuuji@0 109 seconds, according to the server's current time.
yuuji@0 110
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Burger Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 5032 Search Within September 2007
yuuji@0 117
yuuji@0 118
yuuji@0 119 5. Security Considerations
yuuji@0 120
yuuji@0 121 The WITHIN extension does not raise any security considerations that
yuuji@0 122 are not present in the base protocol. Considerations are the same as
yuuji@0 123 for IMAP [RFC3501].
yuuji@0 124
yuuji@0 125 6. IANA Considerations
yuuji@0 126
yuuji@0 127 Per the IMAP RFC [RFC3501], registration of a new IMAP capability in
yuuji@0 128 the IMAP Capability registry requires the publication of a standards-
yuuji@0 129 track RFC or an IESG approved experimental RFC. The registry is
yuuji@0 130 currently located at
yuuji@0 131 <http://www.iana.org/assignments/imap4-capabilities>. This
yuuji@0 132 standards-track document defines the WITHIN IMAP capability. IANA
yuuji@0 133 has added this extension to the IANA IMAP Capability registry.
yuuji@0 134
yuuji@0 135 7. References
yuuji@0 136
yuuji@0 137 7.1. Normative References
yuuji@0 138
yuuji@0 139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
yuuji@0 140 Requirement Levels", RFC 2119, BCP 14, March 1997.
yuuji@0 141
yuuji@0 142 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version
yuuji@0 143 4rev1", RFC 3501, March 2003.
yuuji@0 144
yuuji@0 145 [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
yuuji@0 146 Specifications: ABNF", RFC 4234, October 2005.
yuuji@0 147
yuuji@0 148 7.2. Informative References
yuuji@0 149
yuuji@0 150 [CONTEXT] Melnikov, D. and C. King, "Contexts for IMAP4", Work
yuuji@0 151 in Progress, May 2006.
yuuji@0 152
yuuji@0 153
yuuji@0 154
yuuji@0 155
yuuji@0 156
yuuji@0 157
yuuji@0 158
yuuji@0 159
yuuji@0 160
yuuji@0 161
yuuji@0 162
yuuji@0 163
yuuji@0 164
yuuji@0 165
yuuji@0 166
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Burger Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 5032 Search Within September 2007
yuuji@0 173
yuuji@0 174
yuuji@0 175 Appendix A. Contributors
yuuji@0 176
yuuji@0 177 Stephane Maes and Ray Cromwell wrote the original version of this
yuuji@0 178 document as part of P-IMAP, as well as the first versions for the
yuuji@0 179 IETF. From an attribution perspective, they are clearly authors.
yuuji@0 180
yuuji@0 181 Appendix B. Acknowledgements
yuuji@0 182
yuuji@0 183 The authors want to thank all who have contributed key insight and
yuuji@0 184 who have extensively reviewed and discussed the concepts of LPSEARCH.
yuuji@0 185 They also thank the authors of its early introduction in P-IMAP.
yuuji@0 186
yuuji@0 187 We also want to give a special thanks to Arnt Gilbrandsen, Ken
yuuji@0 188 Murchison, Zoltan Ordogh, and most especially Dave Cridland for their
yuuji@0 189 review and suggestions. A special thank you goes to Alexey Melnikov
yuuji@0 190 for his choice submission of text.
yuuji@0 191
yuuji@0 192 Author's Address
yuuji@0 193
yuuji@0 194 Eric W. Burger (editor)
yuuji@0 195 BEA Systems, Inc.
yuuji@0 196 USA
yuuji@0 197
yuuji@0 198 EMail: eric.burger@bea.com
yuuji@0 199 URI: http://www.standardstrack.com
yuuji@0 200
yuuji@0 201
yuuji@0 202
yuuji@0 203
yuuji@0 204
yuuji@0 205
yuuji@0 206
yuuji@0 207
yuuji@0 208
yuuji@0 209
yuuji@0 210
yuuji@0 211
yuuji@0 212
yuuji@0 213
yuuji@0 214
yuuji@0 215
yuuji@0 216
yuuji@0 217
yuuji@0 218
yuuji@0 219
yuuji@0 220
yuuji@0 221
yuuji@0 222
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Burger Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 5032 Search Within September 2007
yuuji@0 229
yuuji@0 230
yuuji@0 231 Full Copyright Statement
yuuji@0 232
yuuji@0 233 Copyright (C) The IETF Trust (2007).
yuuji@0 234
yuuji@0 235 This document is subject to the rights, licenses and restrictions
yuuji@0 236 contained in BCP 78, and except as set forth therein, the authors
yuuji@0 237 retain all their rights.
yuuji@0 238
yuuji@0 239 This document and the information contained herein are provided on an
yuuji@0 240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
yuuji@0 241 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
yuuji@0 242 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
yuuji@0 243 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
yuuji@0 244 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
yuuji@0 245 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 246
yuuji@0 247 Intellectual Property
yuuji@0 248
yuuji@0 249 The IETF takes no position regarding the validity or scope of any
yuuji@0 250 Intellectual Property Rights or other rights that might be claimed to
yuuji@0 251 pertain to the implementation or use of the technology described in
yuuji@0 252 this document or the extent to which any license under such rights
yuuji@0 253 might or might not be available; nor does it represent that it has
yuuji@0 254 made any independent effort to identify any such rights. Information
yuuji@0 255 on the procedures with respect to rights in RFC documents can be
yuuji@0 256 found in BCP 78 and BCP 79.
yuuji@0 257
yuuji@0 258 Copies of IPR disclosures made to the IETF Secretariat and any
yuuji@0 259 assurances of licenses to be made available, or the result of an
yuuji@0 260 attempt made to obtain a general license or permission for the use of
yuuji@0 261 such proprietary rights by implementers or users of this
yuuji@0 262 specification can be obtained from the IETF on-line IPR repository at
yuuji@0 263 http://www.ietf.org/ipr.
yuuji@0 264
yuuji@0 265 The IETF invites any interested party to bring to its attention any
yuuji@0 266 copyrights, patents or patent applications, or other proprietary
yuuji@0 267 rights that may cover technology that may be required to implement
yuuji@0 268 this standard. Please address the information to the IETF at
yuuji@0 269 ietf-ipr@ietf.org.
yuuji@0 270
yuuji@0 271
yuuji@0 272
yuuji@0 273
yuuji@0 274
yuuji@0 275
yuuji@0 276
yuuji@0 277
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Burger Standards Track [Page 5]
yuuji@0 283

UW-IMAP'd extensions by yuuji