idnits 2.17.1 draft-ietf-lemonade-search-within-03.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 185. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 198. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 2006) is 6519 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Lemonade S. Maes 3 Internet-Draft R. Cromwell 4 Intended status: Standards Track Oracle Corporation 5 Expires: December 3, 2006 June 2006 7 WITHIN Search extension to the IMAP Protocol 8 draft-ietf-lemonade-search-within-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 3, 2006. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2006). 39 Abstract 41 This document describes the WITHIN extension to IMAP SEARCH. IMAP 42 SEARCH returns messages whose internal date is within or outside a 43 specified interval. The mechanism described here, OLDER and YOUNGER, 44 differs from SINCE in that the client specifies an interval, rather 45 than a date. We expect WITHIN to be most useful for persistent 46 searches from mobile devices. 48 Conventions Used in this Document 50 In examples, "C:" and "S:" indicate lines sent by the client and 51 server respectively. 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [1]. 57 When describing the general syntax, we omit some definitions as RFC 58 3501 [2] defines them. 60 1. Introduction 62 This extension exposes two new search keys, OLDER and YOUNGER, each 63 of which takes a non-zero integer argument corresponding to a time 64 interval. The server calculates the time of interest by subtracting 65 the time interval presented by the client, and either returning 66 messages older or younger than the resultant time and date. 68 2. Protocol Operation 70 An IMAP4 server that supports the capability described here MUST 71 return "WITHIN" as one of the server supported capabilities in the 72 CAPABILITY command. 74 For both of the OLDER and YOUNGER search keys, the server calculates 75 a date and time by subtracting the interval on the current date and 76 time of the server. Servers MUST maintain at least a precision of an 77 hour in this calculation. 79 The interval specification is in seconds. The server honors the 80 interval request if it has the precision to do so. If the server 81 does not have the precision to honor the interval request, the server 82 MUST select the closest precision possible. For example, if the 83 client requests messages that are younger than 4020 (67 minutes), but 84 the server only performs searches with hourly accuracy (as mandated 85 above), the server performs the search as if the client requested a 86 60-minute interval. 88 The server then compares the resultant date and time against the 89 INTERNALDATE of the message set in question, as specified in IMAP 90 [2]). For OLDER, messages match if the date and time is less recent 91 then the INTERNALDATE. For YOUNGER, messages match if the date and 92 time is more recent then the INTERNALDATE. If the date and time 93 matches the INTERNALDATE precisely, both OLDER and YOUNGER will match 94 the message. 96 3. Formal Syntax 98 The following syntax specification uses the Augmented Backus-Naur 99 Form (ABNF) notation. Elements not defined here can be found in the 100 formal syntax of ABNF [1], IMAP [2], and IMAP Extended ABNF [3] 102 This document extends RFC 3501 [2] with two new search keys: OLDER 103 and YOUNGER . 104 search-key /= ( "OLDER" | "YOUNGER" ) SP nz-number 105 ; search-key defined in RFC 3501 107 4. Example 108 C: a1 SEARCH UNSEEN YOUNGER 259200 109 S: a1 * SEARCH 4 8 15 16 23 42 111 Search for all unseen messages within the past 3 days (72 hours) 112 according to the server's current time. 114 5. Security Considerations 116 The WITHIN extension does not raise any security considerations which 117 are not present in the base protocol. Considerations are the same as 118 for IMAP [2]. 120 6. Normative References 122 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 123 Levels", RFC 2119, BCP 14, March 1997. 125 [2] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 126 RFC 3501, March 2003. 128 [3] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", 129 RFC 4466, April 2006. 131 Appendix A. Acknowledgements 133 The authors want to thank all who have contributed key insight and 134 extensively reviewed and discussed the concepts of LPSEARCH and the 135 authors of its early introduction in P-IMAP. 137 We also want to give a special thanks to Alexey Melnikov, Arnt 138 Gilbrandsen, Zoltan Ordogh, and Dave Cridland for their review and 139 suggestions, as well as thanks to Eric Burger for reformatting and 140 editing the document to meet IETF publication standards. 142 Authors' Addresses 144 Stephane H. Maes 145 Oracle Corporation 146 500 Oracle Parkway, M/S 4op634 147 Redwood Shores, CA 94065 148 USA 150 Email: stephane.maes@oracle.com 152 Ray Cromwell 153 Oracle Corporation 154 500 Oracle Parkway 155 Redwood Shores, CA 94065 156 USA 158 Email: ray.cromwell@oracle.com 160 Full Copyright Statement 162 Copyright (C) The IETF Trust (2006). 164 This document is subject to the rights, licenses and restrictions 165 contained in BCP 78, and except as set forth therein, the authors 166 retain all their rights. 168 This document and the information contained herein are provided on an 169 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 170 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 171 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 172 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 173 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 174 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 176 Intellectual Property 178 The IETF takes no position regarding the validity or scope of any 179 Intellectual Property Rights or other rights that might be claimed to 180 pertain to the implementation or use of the technology described in 181 this document or the extent to which any license under such rights 182 might or might not be available; nor does it represent that it has 183 made any independent effort to identify any such rights. Information 184 on the procedures with respect to rights in RFC documents can be 185 found in BCP 78 and BCP 79. 187 Copies of IPR disclosures made to the IETF Secretariat and any 188 assurances of licenses to be made available, or the result of an 189 attempt made to obtain a general license or permission for the use of 190 such proprietary rights by implementers or users of this 191 specification can be obtained from the IETF on-line IPR repository at 192 http://www.ietf.org/ipr. 194 The IETF invites any interested party to bring to its attention any 195 copyrights, patents or patent applications, or other proprietary 196 rights that may cover technology that may be required to implement 197 this standard. Please address the information to the IETF at 198 ietf-ipr@ietf.org. 200 Acknowledgment 202 Funding for the RFC Editor function is provided by the IETF 203 Administrative Support Activity (IASA).