idnits 2.17.1 draft-ietf-lemonade-search-within-05.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 192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 203. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 216. 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 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3501, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3501, updated by this document, for RFC5378 checks: 1997-09-12) -- 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 1, 2007) is 6145 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) == Outdated reference: A later version (-05) exists of draft-cridland-imap-context-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 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 Updates: RFC 3501 June 1, 2007 5 (if approved) 6 Intended status: Standards Track 7 Expires: December 3, 2007 9 WITHIN Search extension to the IMAP Protocol 10 draft-ietf-lemonade-search-within-05 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 December 3, 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. WITHIN is useful for persistent 48 searches where either the device does not have the capacity to 49 perform the search at regular intervals or the network is of limited 50 bandwidth and thus there is a desire to reduce network traffic from 51 sending repeated requests and redundant responses. 53 Conventions Used in this Document 55 In examples, "C:" and "S:" indicate lines sent by the client and 56 server respectively. 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC 2119 [1]. 62 When describing the general syntax, we omit some definitions as RFC 63 3501 [2] defines them. 65 1. Introduction 67 This extension exposes two new search keys, OLDER and YOUNGER, each 68 of which takes a non-zero integer argument corresponding to a time 69 interval in seconds. The server calculates the time of interest by 70 subtracting the time interval the client presents. The server then 71 either returnings messages older or younger than the resultant time 72 and date, depending on the search key used. 74 2. Protocol Operation 76 An IMAP4 server that supports the capability described here MUST 77 return "WITHIN" as one of the server supported capabilities in the 78 CAPABILITY command. 80 For both the OLDER and YOUNGER search keys, the server calculates a 81 target date and time by subtracting the interval, specified in 82 seconds, from the current date and time of the server. The server 83 then compares the target time with the INTERNALDATE of the message, 84 as specified in IMAP [2]. For OLDER, messages match if the 85 INTERNALDATE is less recent than or equal to the target time. For 86 YOUNGER, messages match if the INTERNALDATE is more recent than, or 87 equal to, the target time. 89 Both OLDER and YOUNGER searches always result in exact matching, to 90 the resolution of a second. However, if one is doing a dynamic 91 evaluation, for example, in a context [4], one needs to be aware the 92 server might perform the evaluation periodically. Thus, the server 93 may delay the updates. Clients MUST be aware that dynamic search 94 results may not reflect the current state of the mailbox. If the 95 client needs a search result that reflects the current state of the 96 mailbox, we RECOMMEND the client issues a new search. 98 3. Formal Syntax 100 The following syntax specification uses the Augmented Backus-Naur 101 Form (ABNF) notation. Elements not defined here can be found in the 102 formal syntax of ABNF [1], IMAP [2], and IMAP Extended ABNF [3] 104 This document extends RFC 3501 [2] with two new search keys: OLDER 105 and YOUNGER . 106 search-key =/ ( "OLDER" / "YOUNGER" ) SP nz-number 107 ; search-key defined in RFC 3501 109 4. Example 110 C: a1 SEARCH UNSEEN YOUNGER 259200 111 S: a1 * SEARCH 4 8 15 16 23 42 113 Search for all unseen messages within the past 3 days, or 259200 114 seconds, according to the server's current time. 116 5. Security Considerations 118 The WITHIN extension does not raise any security considerations which 119 are not present in the base protocol. Considerations are the same as 120 for IMAP [2]. 122 6. IANA Considerations 124 Per the IMAP RFC [2], registration of a new IMAP capablity in the 125 IMAP Capability registry requires the publication of a standards 126 track RFC or an IESG approved experimental RFC. The registry is 127 currently located at 128 . This standards 129 track document defines the WITHIN IMAP capability. We request IANA 130 to add this extension to the IANA IMAP Capability registry. 132 7. References 134 7.1. Normative References 136 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 137 Levels", RFC 2119, BCP 14, March 1997. 139 [2] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 140 RFC 3501, March 2003. 142 [3] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", 143 RFC 4466, April 2006. 145 7.2. Informative References 147 [4] Melnikov, D. and C. Daboo, "Contexts for IMAP4", 148 draft-cridland-imap-context-02 (work in progress), May 2006. 150 Appendix A. Contributors 152 Stephane Maes and Ray Cromwell wrote the original version of this 153 document as part of P-IMAP as well as the first drafts for the IETF. 154 From an attribution perspective, they are clearly authors. 156 Appendix B. Acknowledgements 158 The authors want to thank all who have contributed key insight and 159 extensively reviewed and discussed the concepts of LPSEARCH and the 160 authors of its early introduction in P-IMAP. 162 We also want to give a special thanks to Arnt Gilbrandsen, Ken 163 Murchison, Zoltan Ordogh, and most especially Dave Cridland for their 164 review and suggestions. A special thank you goes to Alexey Melnikov 165 for his choice submission of text. 167 Author's Address 169 Eric W. Burger (editor) 170 BEA Systems, Inc. 171 USA 173 Phone: 174 Fax: 175 Email: eric.burger@bea.com 176 URI: http://www.standardstrack.com 178 Full Copyright Statement 180 Copyright (C) The IETF Trust (2007). 182 This document is subject to the rights, licenses and restrictions 183 contained in BCP 78, and except as set forth therein, the authors 184 retain all their rights. 186 This document and the information contained herein are provided on an 187 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 188 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 189 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 190 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 191 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 192 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 194 Intellectual Property 196 The IETF takes no position regarding the validity or scope of any 197 Intellectual Property Rights or other rights that might be claimed to 198 pertain to the implementation or use of the technology described in 199 this document or the extent to which any license under such rights 200 might or might not be available; nor does it represent that it has 201 made any independent effort to identify any such rights. Information 202 on the procedures with respect to rights in RFC documents can be 203 found in BCP 78 and BCP 79. 205 Copies of IPR disclosures made to the IETF Secretariat and any 206 assurances of licenses to be made available, or the result of an 207 attempt made to obtain a general license or permission for the use of 208 such proprietary rights by implementers or users of this 209 specification can be obtained from the IETF on-line IPR repository at 210 http://www.ietf.org/ipr. 212 The IETF invites any interested party to bring to its attention any 213 copyrights, patents or patent applications, or other proprietary 214 rights that may cover technology that may be required to implement 215 this standard. Please address the information to the IETF at 216 ietf-ipr@ietf.org. 218 Acknowledgment 220 Funding for the RFC Editor function is provided by the IETF 221 Administrative Support Activity (IASA).