idnits 2.17.1 draft-ietf-lemonade-search-within-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 218. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2007) is 6265 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (ref. '2') (Obsoleted by RFC 9051) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade E. Burger, Ed. 3 Internet-Draft BEA Systems, Inc. 4 Intended status: Standards Track R. Cromwell 5 Expires: August 27, 2007 S. Maes 6 Oracle Corporation 7 February 23, 2007 9 WITHIN Search extension to the IMAP Protocol 10 draft-ietf-lemonade-search-within-04 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 27, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes the WITHIN extension to IMAP SEARCH. IMAP 44 SEARCH returns messages whose internal date is within or outside a 45 specified interval. The mechanism described here, OLDER and YOUNGER, 46 differs from BEFORE and SINCE in that the client specifies an 47 interval, rather than a date. We expect WITHIN to be most useful for 48 persistent searches from mobile devices. 50 Conventions Used in this Document 52 In examples, "C:" and "S:" indicate lines sent by the client and 53 server respectively. 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in RFC 2119 [1]. 59 When describing the general syntax, we omit some definitions as RFC 60 3501 [2] defines them. 62 1. Introduction 64 This extension exposes two new search keys, OLDER and YOUNGER, each 65 of which takes a non-zero integer argument corresponding to a time 66 interval. The server calculates the time of interest by subtracting 67 the time interval presented by the client, and either returning 68 messages older or younger than the resultant time and date. 70 2. Protocol Operation 72 An IMAP4 server that supports the capability described here MUST 73 return "WITHIN" as one of the server supported capabilities in the 74 CAPABILITY command. 76 For both the OLDER and YOUNGER search keys, the server calculates a 77 target date and time by subtracting the interval from the current 78 date and time of the server. The server then compares the target 79 time with the INTERNALDATE of the message, as specified in IMAP [2]. 80 For OLDER, messages match if the INTERNALDATE is less recent than, or 81 equal to, the target time. For YOUNGER, messages match if the 82 INTERNALDATE is more recent than, or equal to, the target time. 84 In some cases, the server may be unable, or unwilling, to use a 85 precision of a single second. This is expected to be the case 86 particularly for dynamically updated searches. In these cases, 87 servers are permitted to reduce the precision used for date 88 calulcations and comparisons, but SHOULD ensure that a precision of 89 no less than an hour (3600 seconds) is used. This might mean re- 90 running the search criteria only every hour for a dynamic search, for 91 example. Clients MUST be aware that search results, whether viewed 92 directly or through some other mechanism, MAY not be accurate as a 93 result. 95 For example, if the client requests messages that are younger than 96 4020 (67 minutes), but the server only performs searches with hourly 97 accuracy (as mandated above), the server performs the search as if 98 the client requested a 60-minute interval. Note the choice of 99 rounding up or down is at the discretion of the server. However, 100 rounding down to zero is NOT RECOMMENDED, as this may result in 101 searches for messages YOUNGER than a value being rounded to YOUNGER 102 0, which will always fail. 104 3. Formal Syntax 106 The following syntax specification uses the Augmented Backus-Naur 107 Form (ABNF) notation. Elements not defined here can be found in the 108 formal syntax of ABNF [1], IMAP [2], and IMAP Extended ABNF [3] 110 This document extends RFC 3501 [2] with two new search keys: OLDER 111 and YOUNGER . 112 search-key /= ( "OLDER" | "YOUNGER" ) SP nz-number 113 ; search-key defined in RFC 3501 115 4. Example 116 C: a1 SEARCH UNSEEN YOUNGER 259200 117 S: a1 * SEARCH 4 8 15 16 23 42 119 Search for all unseen messages within the past 3 days (72 hours) 120 according to the server's current time. 122 5. Security Considerations 124 The WITHIN extension does not raise any security considerations which 125 are not present in the base protocol. Considerations are the same as 126 for IMAP [2]. 128 6. IANA Considerations 130 None. 132 7. Normative References 134 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 135 Levels", RFC 2119, BCP 14, March 1997. 137 [2] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 138 RFC 3501, March 2003. 140 [3] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", 141 RFC 4466, April 2006. 143 Appendix A. Acknowledgements 145 The authors want to thank all who have contributed key insight and 146 extensively reviewed and discussed the concepts of LPSEARCH and the 147 authors of its early introduction in P-IMAP. 149 We also want to give a special thanks to Arnt Gilbrandsen, Alexey 150 Melnikov, Ken Murchison, Zoltan Ordogh, and most especially Dave 151 Cridland for their review and suggestions. 153 Authors' Addresses 155 Eric W. Burger (editor) 156 BEA Systems, Inc. 157 USA 159 Phone: 160 Fax: 161 Email: eric.burger@bea.com 162 URI: 164 Ray Cromwell 165 Oracle Corporation 166 500 Oracle Parkway 167 Redwood Shores, CA 94065 168 USA 170 Email: ray.cromwell@oracle.com 172 Stephane H. Maes 173 Oracle Corporation 174 500 Oracle Parkway, M/S 4op634 175 Redwood Shores, CA 94065 176 USA 178 Email: stephane.maes@oracle.com 180 Full Copyright Statement 182 Copyright (C) The IETF Trust (2007). 184 This document is subject to the rights, licenses and restrictions 185 contained in BCP 78, and except as set forth therein, the authors 186 retain all their rights. 188 This document and the information contained herein are provided on an 189 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 190 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 191 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 192 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 193 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 194 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 196 Intellectual Property 198 The IETF takes no position regarding the validity or scope of any 199 Intellectual Property Rights or other rights that might be claimed to 200 pertain to the implementation or use of the technology described in 201 this document or the extent to which any license under such rights 202 might or might not be available; nor does it represent that it has 203 made any independent effort to identify any such rights. Information 204 on the procedures with respect to rights in RFC documents can be 205 found in BCP 78 and BCP 79. 207 Copies of IPR disclosures made to the IETF Secretariat and any 208 assurances of licenses to be made available, or the result of an 209 attempt made to obtain a general license or permission for the use of 210 such proprietary rights by implementers or users of this 211 specification can be obtained from the IETF on-line IPR repository at 212 http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights that may cover technology that may be required to implement 217 this standard. Please address the information to the IETF at 218 ietf-ipr@ietf.org. 220 Acknowledgment 222 Funding for the RFC Editor function is provided by the IETF 223 Administrative Support Activity (IASA).