idnits 2.17.1 draft-ietf-lemonade-search-within-00.txt: -(152): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(153): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(154): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 on line 214. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 204. ** 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 11 instances 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 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 2006) is 6617 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 57, but not defined == Missing Reference: 'RFC 3501' is mentioned on line 121, but not defined ** Obsolete undefined reference: RFC 3501 (Obsoleted by RFC 9051) == Missing Reference: 'P-IMAP' is mentioned on line 151, but not defined == Unused Reference: '1' is defined on line 138, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- No information found for draft-melnikov-imap-ext-abnf-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ABNFEXTEND' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 February 2006 3 Lemonade 4 Internet Draft: WITHIN S. H. Maes 5 Document: draft-ietf-lemonade-search-within-00 R. Cromwell 6 Eds. 8 Expires: August 2006 February 2006 10 WITHIN Search extension to the IMAP Protocol 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 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 WITHIN is an extension to [RFC3501] SEARCH which returns messages 42 whose internal date is on or within a specified interval and differs 43 from SINCE in that an interval in seconds is specified instead of a 44 date. WITHIN is expected to be most useful for persistent searches in 45 combination with mobile devices. 47 Conventions used in this document 49 In examples, "C:" and "S:" indicate lines sent by the client and 50 server respectively. 52 February 2006 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 An implementation is not compliant if it fails to satisfy one or more 59 of the MUST or REQUIRED level requirements for the protocol(s) it 60 implements. An implementation that satisfies all the MUST or REQUIRED 61 level and all the SHOULD level requirements for a protocol is said to 62 be "unconditionally compliant" to that protocol; one that satisfies 63 all the MUST level requirements but not all the SHOULD level 64 requirements is said to be "conditionally compliant." When 65 describing the general syntax, some definitions are omitted as they 66 are defined in [RFC3501]. 68 Table of Contents 70 Status of this Memo...............................................1 71 Copyright Notice..................................................1 72 Abstract..........................................................1 73 Conventions used in this document.................................1 74 Table of Contents.................................................2 75 1. Introduction................................................2 76 2. Formal Syntax...............................................2 77 Security Considerations...........................................3 78 References........................................................3 79 Future Work.......................................................3 80 Version History...................................................3 81 Acknowledgments...................................................4 82 Authors Addresses.................................................4 83 Intellectual Property Statement...................................4 84 Disclaimer of Validity............................................5 85 Copyright Statement...............................................5 87 1. Introduction 89 The WITHIN extension is present in any IMAP4 implementation which 90 returns �WITHIN� as one of the supported capabilities in the 91 CAPABILITY command. 93 2. Formal Syntax 95 The following syntax specification uses the Augmented Backus-Naur 96 Form (ABNF) notation. Elements not defined here can be found in 97 the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND]. 99 February 2006 101 The create ABNF grammar in [RFC3501] is hereby modified to the 102 grammar defined in [ABNFEXTEND], and the ABNF search-key grammar of 103 [ABNFEXTEND] has been extended with a new search key: WITHIN 104 106 search-key /= �WITHIN� nz-number 107 ; defined in [ABNFEXTEND] 109 3. Examples 111 C: a1 SEARCH UNSEEN WITHIN 259200 112 S: a1 * SEARCH 4 8 15 16 23 42 114 Search for all unseen messages within the past 3 days according to 115 the server�s current time. 117 Security Considerations 119 The WITHIN extension does not raise any security considerations which 120 are not present in the base protocol. Considerations are the same as 121 for IMAP [RFC 3501]. 123 References 125 [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications: 126 ABNF�, RFC 2234, November 1997. 127 http://www.ietf.org/rfc/rfc2234 129 [ABNFEXTEND] Melnikov, A., and C. Daboo, "Collected extensions to 130 IMAP4 ABNF", work in progress, draft-melnikov-imap-ext-abnf-XX.txt. 132 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol 133 Version 4 rev1", RFC 3501, March 2003. 134 http://www.ietf.org/rfc/rfc3501 136 Future Work 138 [1] Decide whether seconds is the appropriate unit for specifying the 139 interval. 141 Version History 143 Release 00 144 Initial release, separated from VFOLDER draft 145 February 2006 147 Acknowledgments 149 The authors want to thank all who have contributed key insight and 150 extensively reviewed and discussed the concepts of LPSEARCH and its 151 early introduction P-IMAP [P-IMAP]. In particular, this includes the 152 authors of the P-IMAP draft: Rafiul Ahad � Oracle Corporation, Eugene 153 Chiu � Oracle Corporation, Ray Cromwell � Oracle Corporation, Jia-der 154 Day � Oracle Corporation, Vi Ha � Oracle Corporation, Wook-Hyun Jeong 155 � Samsung Electronics Co. LTF, Chang Kuang � Oracle Corporation, 156 Rodrigo Lima � Oracle Corporation, Stephane H. Maes � Oracle 157 Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini � Symbol 158 Technologies, Sung-Mu Son � LG Electronics, Fan Xiaohui - CHINA 159 MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE 160 COMMUNICATIONS CORPORATION (CMCC). We also want to give a special 161 thanks to A. Melnikov for his review and suggestions. 163 Authors Addresses 165 Stephane H. Maes 166 Oracle Corporation 167 500 Oracle Parkway 168 M/S 4op634 169 Redwood Shores, CA 94065 170 USA 171 Phone: +1-650-607-6296 172 Email: stephane.maes@oracle.com 174 Ray Cromwell 175 Oracle Corporation 176 500 Oracle Parkway 177 Redwood Shores, CA 94065 178 USA 180 Intellectual Property Statement 182 The IETF takes no position regarding the validity or scope of any 183 Intellectual Property Rights or other rights that might be claimed to 184 pertain to the implementation or use of the technology described in 185 this document or the extent to which any license under such rights 186 might or might not be available; nor does it represent that it has 187 made any independent effort to identify any such rights. Information 188 on the procedures with respect to rights in RFC documents can be 189 found in BCP 78 and BCP 79. 191 February 2006 193 Copies of IPR disclosures made to the IETF Secretariat and any 194 assurances of licenses to be made available, or the result of an 195 attempt made to obtain a general license or permission for the use of 196 such proprietary rights by implementers or users of this 197 specification can be obtained from the IETF on-line IPR repository at 198 http://www.ietf.org/ipr. 200 The IETF invites any interested party to bring to its attention any 201 copyrights, patents or patent applications, or other proprietary 202 rights that may cover technology that may be required to implement 203 this standard. Please address the information to the IETF at ietf- 204 ipr@ietf.org. 206 Disclaimer of Validity 208 This document and the information contained herein are provided on an 209 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 210 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 211 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 212 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 213 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 214 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 216 Copyright Statement 218 Copyright (C) The Internet Society (2006). This document is subject 219 to the rights, licenses and restrictions contained in BCP 78, and 220 except as set forth therein, the authors retain all their rights. 222 Acknowledgement 224 Funding for the RFC Editor function is currently provided by the 225 Internet Society.