idnits 2.17.1 draft-ietf-imapext-regex-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Introduction section. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([IMAP]), 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 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 (March 2000) is 8800 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 section? 'IMAP' on line 56 looks like a reference -- Missing reference section? 'KEYWORDS' on line 187 looks like a reference -- Missing reference section? 'ABNF' on line 180 looks like a reference -- Missing reference section? 'IMAP4' on line 184 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Gellens 3 Document: draft-ietf-imapext-regex-00.txt QUALCOMM 4 Expires: September 2000 March 2000 6 IMAP Regular Expressions SEARCH Extension 8 Status of this Memo: 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 A version of this draft document is intended for submission to the 30 RFC editor as a Proposed Standard for the Internet Community. 31 Discussion and suggestions for improvement are requested. 33 Copyright Notice 35 Copyright (C) The Internet Society 2000. All Rights Reserved. 37 Table of Contents 39 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 40 2. Conventions Used in this Document . . . . . . . . . . . . . . 2 41 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 2 42 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 2 43 5. REGEX Modifier to SEARCH (and UID SEARCH) Criteria . . . . . 3 44 6. Formal Syntax Changes . . . . . . . . . . . . . . . . . . . . 3 45 7. Regular Expression Details . . . . . . . . . . . . . . . . . 3 46 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 10. Security Considerations . . . . . . . . . . . . . . . . . . . 5 49 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 5 50 12. Author's Address . . . . . . . . . . . . . . . . . . . . . . 5 51 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 5 53 1. Abstract 55 This memo describes a regular-expression search facility for the 56 [IMAP] protocol. 58 A server advertises support for this facility by the capability name 59 REGEX. 61 2. Conventions Used in this Document 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 67 3. Comments 69 Public comments can be sent to the IETF IMAP Extensions mailing 70 list, . To subscribe, send a message to 71 with the word SUBSCRIBE as the body. 72 Private comments should be sent to the author. 74 4. Open Issues 76 - Should the regular expression syntax be specified in a simple 77 form, as is done here, or should it be a reference to a published, 78 more complex form, such as POSIX 1003.2? 80 - Should ^ and $ be used for token, line, or a message part (such as 81 a header field)? 82 - Should REGEX come after the search key? 84 - The current Formal Syntax allows for sillyness such as SEARCH 85 REGEXP REGEXP CC "gork" 87 5. REGEX Modifier to SEARCH (and UID SEARCH) Criteria 89 This extension adds an additional optional REGEXP modifier to all 90 SEARCH criteria which take strings. When this modifier is present, 91 the search criteria string is interpreted as a regular expression, 92 as described in section 7. 94 If the string supplied with the search criteria does not contain a 95 valid regular expression, the server MUST return a BAD response. 97 If the search criteria does not take a string, the server MUST 98 return a BAD response. 100 6. Formal Syntax Changes 102 This section described the changes to the Formal Syntax of the IMAP 103 protocol, using [ABNF]: 105 search-key =/ REGEX SP search-key 106 ; modifies existing IMAP search-key so 107 ; that string values in search-key are treated 108 ; as regular expressions for pattern matching 110 7. Regular Expression Details 112 The regular expression syntax described in this section is a subset 113 of that used in many applications and systems. It is however very 114 simple and does not include the logical operators AND and OR. 116 Searches using regular expressions are always substring matches 117 except when the regular expression contains the characters '^' or 118 '$'. 120 Character Function 121 --------- -------- 122 Matches itself 124 . Matches any character 125 a* Matches zero or more 'a's 126 a+ Matches one or more 'a's 127 [ab] Matches 'a' or 'b' 128 [a-c] Matches 'a', 'b' or 'c' 129 [^ab] Matches any character 130 except 'a' or 'b' 131 ^ Matches beginning of 132 a token 133 $ Matches end of a token 134 \ Next character matches 135 itself 137 Examples 138 --------- 140 String Matches Doesn't Match 141 ------- ------- ------------- 142 hello xhelloy heello 143 h.llo hello helio 144 h.*o hello helloa 145 h[a-f]llo hello hgllo 146 ^he.* hello ehello 147 .*lo$ hello helloo 148 hel+o hello helo 150 8. Examples 152 This example finds messages that have "MAKE*MONEY*FAST" in the 153 subject, but not "MAKE!MONEY!FAST": 155 C: Z SEARCH REGEX SUBJECT "MAKE[ _\-\*]+MONEY[ _\-\*]+FAST" 156 S: * SEARCH 2 22 98 2048 157 S: Z OK SEARCH Completed 159 This example uses an invalid regular expression: 161 C: Y SEARCH REGEX TO ".[" 162 S: Y BAD Invalid regular expression syntax 164 This example uses REGEX with a search criteria that does not take a 165 string: 167 C: X SEARCH REGEX LARGER 10000 168 S: X BAD Cannot use regular expressions with the LARGER criteria 170 This example searches for messages without the \ANSWERED flag where 171 the envelope from matches the regular expression "mump.*wump" and 172 the text matches the substring "a[0-9]*" (note that the text 173 criteria is not a regular expression): 175 C: W SEARCH UNANSWERED REGEX FROM "mump.*wump" TEXT "a[0-9]*" 176 S: * SEARCH 3 177 S: W OK SEARCH Completed 178 9. References 180 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 181 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., 182 November 1997. 184 [IMAP4] Crispin, "Internet Message Access Protocol - Version 4rev1", 185 RFC 2060, University of Washington, December 1996. 187 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 188 Requirement Levels", RFC 2119, Harvard University, March 1997. 189 191 10. Security Considerations 193 This extension does not alter the security semantics of IMAP. 195 11. Acknowledgments 197 The table in section 7 is based on the one in RFC 1835. 199 12. Author's Address 201 Randall Gellens +1 858 651 5115 202 QUALCOMM Incorporated randy@qualcomm.com 203 5775 Morehouse Drive 204 San Diego, CA 92121-2779 205 U.S.A. 207 13. Full Copyright Statement 209 Copyright (C) The Internet Society 2000. All Rights Reserved. 211 This document and translations of it may be copied and furnished to 212 others, and derivative works that comment on or otherwise explain it 213 or assist in its implementation may be prepared, copied, published 214 and distributed, in whole or in part, without restriction of any 215 kind, provided that the above copyright notice and this paragraph 216 are included on all such copies and derivative works. However, this 217 document itself may not be modified in any way, such as by removing 218 the copyright notice or references to the Internet Society or other 219 Internet organizations, except as needed for the purpose of 220 developing Internet standards in which case the procedures for 221 copyrights defined in the Internet Standards process must be 222 followed, or as required to translate it into languages other than 223 English. 225 The limited permissions granted above are perpetual and will not be 226 revoked by the Internet Society or its successors or assigns. 228 This document and the information contained herein is provided on an 229 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 230 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 231 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 232 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 233 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.