idnits 2.17.1 draft-ietf-lemonade-search-within-02.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 on line 216. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The abstract seems to contain references ([RFC3501]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 6525 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) == Missing Reference: 'RFC2119' is mentioned on line 49, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 108, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Unused Reference: '1' is defined on line 134, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- No information found for draft-maes-lemonade-p-imap-xx - is the name correct? Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Lemonade 2 Internet Draft: WITHIN S. H. Maes 3 Document: draft-ietf-lemonade-search-within-02 R. Cromwell 4 Eds. 6 Expires: December 2006 June 2006 8 WITHIN Search extension to the IMAP Protocol 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 Abstract 35 WITHIN is an extension to [RFC3501] SEARCH which returns messages 36 whose internal date is within or outside a specified interval and 37 differs from SINCE in that an interval in days is specified instead 38 of a date. WITHIN is expected to be most useful for persistent 39 searches in combination with mobile devices. 41 Conventions used in this document 43 In examples, "C:" and "S:" indicate lines sent by the client and 44 server respectively. 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 48 document are to be interpreted as described in [RFC2119]. 50 When describing the general syntax, some definitions are omitted as 51 they are defined in [RFC3501]. 53 Table of Contents 55 Status of this Memo...............................................1 56 Abstract..........................................................1 57 Conventions used in this document.................................1 58 Table of Contents.................................................2 59 1. Introduction................................................2 60 2. Formal Syntax...............................................2 61 3. Examples....................................................3 62 4. Security Considerations.....................................3 63 Normative References..............................................3 64 Informative References............................................3 65 Future Work.......................................................3 66 Version History...................................................3 67 Acknowledgments...................................................4 68 Authors Addresses.................................................4 69 Intellectual Property Statement...................................4 70 Full Copyright Statement..........................................5 72 1. Introduction 74 The WITHIN extension is present in any IMAP4 implementation which 75 returns "WITHIN" as one of the supported capabilities in the 76 CAPABILITY command. 78 The extension exposes two new search keys, YOUNGER and OLDER, each of 79 which take a non-zero integer argument corresponding to an interval 80 in hours. YOUNGER returns messages deposited in the mailbox after 81 the date calculated by subtracting the interval number of hours from 82 the server's current date. OLDER returns messages deposited before 83 the date calculated as described above. 85 2. Formal Syntax 87 The following syntax specification uses the Augmented Backus-Naur 88 Form (ABNF) notation. Elements not defined here can be found in 89 the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND]. 91 The ABNF grammar in [RFC3501] is hereby modified with two new search 92 keys: OLDER and YOUNGER 93 search-key /= "OLDER" SP nz-number / "YOUNGER" SP nz-number 94 ; search-key defined in [RFC3501] 96 3. Examples 98 C: a1 SEARCH UNSEEN YOUNGER 72 99 S: a1 * SEARCH 4 8 15 16 23 42 101 Search for all unseen messages within the past 3 days (72 hours) 102 according to the server�s current time. 104 4. Security Considerations 106 The WITHIN extension does not raise any security considerations which 107 are not present in the base protocol. Considerations are the same as 108 for IMAP [RFC 3501]. 110 Normative References 112 [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: 113 ABNF", RFC 2234, November 1997. 114 http://www.ietf.org/rfc/rfc2234 116 [ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to 117 IMAP4 ABNF", RFC 4466, April 2006. 119 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 120 Version 4 rev1", RFC 3501, March 2003. 121 http://www.ietf.org/rfc/rfc3501 123 Informative References 125 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and 126 Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S- 127 M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol 128 (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). 130 Future Work 132 [Note to RFC editor: please delete this section before publication] 134 [1] Decide whether other interval units are necessary. 136 Version History 138 [Note to RFC editor: please delete this section before publication] 140 Release 00 141 Initial release, separated from VFOLDER draft 143 Release 01 144 Incorporate feedback and suggestions received from Arnt 145 Gulbrandsen. 147 Release 02 148 Interval now defined as hours instead of days as per interim 149 meeting consensus. 151 Acknowledgments 153 The authors want to thank all who have contributed key insight and 154 extensively reviewed and discussed the concepts of LPSEARCH and the 155 authors of its early introduction P-IMAP [P-IMAP]. 157 We also want to give a special thanks to A. Melnikov and A. 158 Gulbrandsen for their review and suggestions. 160 Authors Addresses 162 Stephane H. Maes 163 Oracle Corporation 164 500 Oracle Parkway 165 M/S 4op634 166 Redwood Shores, CA 94065 167 USA 168 Phone: +1-650-607-6296 169 Email: stephane.maes@oracle.com 171 Ray Cromwell 172 Oracle Corporation 173 500 Oracle Parkway 174 Redwood Shores, CA 94065 175 USA 177 Intellectual Property Statement 179 The IETF takes no position regarding the validity or scope of any 180 intellectual property or other rights that might be claimed to 181 pertain to the implementation or use of the technology described in 182 this document or the extent to which any license under such rights 183 might or might not be available; neither does it represent that it 184 has made any effort to identify any such rights. Information on the 185 IETF's procedures with respect to rights in standards-track and 186 standards-related documentation can be found in BCP-11. Copies of 187 claims of rights made available for publication and any assurances of 188 licenses to be made available, or the result of an attempt made to 189 obtain a general license or permission for the use of such 190 proprietary rights by implementers or users of this specification can 191 be obtained from the IETF Secretariat. 193 The IETF invites any interested party to bring to its attention any 194 copyrights, patents or patent applications, or other proprietary 195 rights, which may cover technology that may be required to practice 196 this standard. Please address the information to the IETF Executive 197 Director. 199 Acknowledgement 201 Funding for the RFC Editor function is currently provided by the 202 Internet Society. 204 Full Copyright Statement 206 Copyright (C) The Internet Society (2006). This document is subject 207 to the rights, licenses and restrictions contained in BCP 78, and 208 except as set forth therein, the authors retain all their rights. 210 This document and the information contained herein are provided on an 211 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 212 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 213 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 214 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 215 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 216 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 218 This document and translations of it may be copied and furnished to 219 others, and derivative works that comment on or otherwise explain it 220 or assist in its implementation may be prepared, copied, published 221 and distributed, in whole or in part, without restriction of any 222 kind, provided that the above copyright notice and this paragraph are 223 included on all such copies and derivative works. However, this 224 document itself may not be modified in any way, such as by removing 225 the copyright notice or references to the Internet Society or other 226 Internet organizations, except as needed for the purpose of 227 developing Internet standards in which case the procedures for 228 copyrights defined in the Internet Standards process must be 229 followed, or as required to translate it into languages other than 230 English. 232 The limited permissions granted above are perpetual and will not be 233 revoked by the Internet Society or its successors or assigns.