idnits 2.17.1 draft-melnikov-imapext-filters-01.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 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 374. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 380. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 14, 2007) is 6189 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 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-09 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. King 3 Internet-Draft A. Melnikov 4 Intended status: Standards Track Isode Ltd 5 Expires: November 15, 2007 May 14, 2007 7 IMAP4 extension for named searches (filters) 8 draft-melnikov-imapext-filters-01.txt 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 November 15, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 The document defines a way to persistently store named IMAP (RFC 42 3501) searches on the server. Such named searches can be 43 subsequently referenced in a SEARCH command. 45 Table of Contents 47 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 48 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 49 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 3 50 3.1. Registration of a new server entries . . . . . . . . . . . 3 51 3.2. FILTER SEARCH criterion . . . . . . . . . . . . . . . . . 4 52 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 54 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 56 8. Normative References . . . . . . . . . . . . . . . . . . . . . 8 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 58 Intellectual Property and Copyright Statements . . . . . . . . . . 10 60 1. Conventions Used in this Document 62 In examples, "C:" and "S:" indicate lines sent by the client and 63 server respectively. If a single "C:" or "S:" label applies to 64 multiple lines, then the line breaks between those lines are for 65 editorial clarity only and are not part of the actual protocol 66 exchange. 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 [[anchor2: Editorial comments and questions are marked like this.]] 74 2. Introduction and Overview 76 Persistent named searches described in this document allow clients to 77 save favourite searches on the server. Such saved searches can save 78 bandwidth for clients that need to regularly repeat them. 80 The IMAP extension for persistent named searches is present in any 81 IMAP4 implementation which advertises "X-DRAFT-I01-FILTERS" 82 [[anchor4: Change upon publication]] as one of the supported 83 capabilities in the CAPABILITY command response. 85 3. IMAP Protocol Changes 87 3.1. Registration of a new server entries 89 This document reserves hierarchy of entries under the "/filters" root 90 for storing named searches (a.k.a. "filters"). The "value" 91 ("value.priv" or "value.shared") attribute of a "/filters/ 92 " server annotation is an IMAP SEARCH criteria, 93 conforming to ABNF for the "search-criteria" non-terminal. A name of 94 a filter is governed by ABNF for the "filter-name" non-terminal. 96 Note that values of all search keys stored in this annotation MUST be 97 encoded in UTF-8. 99 A new filter named "" can be created (or an existing 100 filter can be modified) by storing a non NIL value in the 101 "value.priv" or "value.shared" attribute of a "/filters/ 102 " entry using the SETMETADATA [METADATA] command. A 103 filter can be deleted by storing the NIL value in the 104 "value.priv"/"value.shared" attribute of the "/filters/" 105 entry. A filter can be renamed by first creating a filter with the 106 new name and then deleting filter with the old one. 108 If both "value.priv" and "value.shared" attributes exist for a 109 "/filters/" server annotation, then the "value.priv" is 110 used when evaluating the corresponding FILTER SEARCH key (see 111 Section 3.2). Otherwise the non-NIL value is used. 113 C: a SETMETADATA "" "/filters/on-the-road" 114 (value.priv "OR SMALLER 5000 115 FROM \"boss@example.com\"") 116 S: a OK SETMETADATA complete 118 Implementation note: As multiple client might read and write filter 119 values, it is possible that one client will use a SEARCH key that 120 might not be recognized by another client that tries to present a UI 121 for editing a filter value. In order to allow clients for partial 122 parsing of filter values for editing purposes, a client storing a 123 filter value SHOULD use () around any SEARCH key not defined in 124 [RFC3501] For example, if there is an IMAP extension that defines a 125 new x-dsfa SEARCH key that takes 2 parameters, then the following 126 SEARCH criteria 'from "@isode.com>" x-dsfa from 5' should be stored 127 as 'from "@isode.com>" (x-dsfa from 5)'. 129 Note that filter names are restricted to a subset of US-ASCII, as 130 described in Section 4. So they might not always be meaningful to 131 users and thus not necessarily suitable for display purposes. In 132 order to help with storing human readable descriptions of filters, 133 this document also reserves hierarchy of entries under the "/filter- 134 descriptions" root. The "value" attribute of a "/filter- 135 descriptions/" server annotation is a human readable 136 description for the filter, encoded in UTF-8 [UTF-8]. 137 In the absence of "/filter-descriptions/" the client MAY 138 display the name of the filter as its description. 140 3.2. FILTER SEARCH criterion 142 The FILTER criterion for the SEARCH command allows a client to 143 reference a filter stored on the server by name. A filter called 144 "" is stored in the server annotation named "/filters/ 145 " as described in Section 3.1. 147 Syntax: FILTER 149 When the named filter exist, its search criteria (i.e. the associated 150 "value" attribute) is inserted verbatum instead of the FILTER search- 151 key. For example, the following SEARCH command 152 C: a SEARCH UID 300:900 FILTER on-the-road SINCE " 3-Dec-2002" 154 would be equivalent to the following 156 C: a SEARCH UID 300:900 SMALLER 5000 FROM "boss@example.com" 157 SINCE " 3-Dec-2002" 159 assuming the filter "on-the-road" is as defined in example from 160 Section 3.1. 162 A reference to a non-existent or unaccessible (e.g. due to access 163 control restrictions) filter MUST cause failure of the SEARCH command 164 with the tagged NO response, that includes the UNDEFINED-FILTER 165 response code followed by the name of the non-existent/unaccessible 166 filter. 168 Note the server SHOULD verify that each search criteria referenced by 169 the FILTER search key is a full and correct search criteria. For 170 example, the server should fail the SEARCH command if its SEARCH 171 criteria references a filter containing "OR SMALLER" search criteria. 173 Note that a named filter itself can reference another filter using 174 the FILTER search-key. Implementations MUST be able to perform at 175 least 3 substitution passes on the SEARCH criteria. If an 176 implementation allows for more passes, it MUST implement some kind of 177 loop detection. If an implementation detects a loop or still sees a 178 FILTER search-key after performing at least 3 substitutions, it MUST 179 behave as if the specified filter doesn't exist (as described above). 181 Note that use of the FILTER search key implies the CHARSET "UTF-8" 182 parameter to the SEARCH/UID SEARCH command. If the SEARCH/UID SEARCH 183 command includes the explicit CHARSET parameter with the value other 184 than "UTF-8" or "US-ASCII" then such command MUST result in the 185 tagged BAD response from the server. 187 4. Formal Syntax 189 The following syntax specification uses the Augmented Backus-Naur 190 Form (ABNF) notation as specified in [ABNF]. 192 Non-terminals referenced but not defined below are as defined by 193 [RFC3501] or [IMAPABNF]. 195 Except as noted otherwise, all alphabetic characters are case- 196 insensitive. The use of upper or lower case characters to define 197 token strings is for editorial clarity only. Implementations MUST 198 accept these strings in a case-insensitive fashion. 200 capability =/ "X-DRAFT-I01-FILTERS" 201 ;; [[Note to RFC Editor: change the capability 202 ;; name before publication]] 204 [[anchor6: IMAPABNF only defines "search- 205 program", which includes the charset]] 207 search-criteria = search-key *(SP search-key) 209 search-key =/ "FILTER" SP filter-name 210 ;; New SEARCH criterion for referencing filters 212 filter-name = 1* 213 ;; Note that filter-name disallows UTF-8 or 214 ;; the following characters: "(", ")", "{", 215 ;; " ", "%", "*", "]". See definition of 216 ;; ATOM-CHAR [RFC3501]. 218 resp-text-code =/ "UNDEFINED-FILTER" SP filter-name 220 5. Security Considerations 222 General issues relevant to [RFC3501] (in particular to the SEARCH 223 command) and [METADATA] are also relevant to this document. 225 Note that excessive use of filters can potentially simplify DoS 226 attacks, especially if combined with poor implementations and lack of 227 loop detection (i.e. detection of filters referencing each other to 228 create a loop). Servers that allow for anonymous access SHOULD NOT 229 allow anonymous users to create/edit/delete filters. 231 Also note that stored filters can potentially dislose personal 232 information about users. When confidentiality of such information is 233 important, clients should use TLS and/or SASL security layer (or 234 similar) as recommended in [RFC3501]. 236 As always, it is important to thoroughly test clients and servers 237 when implementing this extension. 239 6. IANA Considerations 241 IMAP4 capabilities are registered by publishing a standards track or 242 IESG approved experimental RFC. The registry is currently located 243 at: 245 http://www.iana.org/assignments/imap4-capabilities 247 This document defines the X-DRAFT-I01-FILTERS [[anchor9: Note to RFC 248 Editor: fix before publication]] IMAP capability. IANA is requested 249 to add it to the registry. 251 IANA is also requested to add the following 2 entries to the 252 [METADATA] registry: 254 To: iana@iana.org 256 Subject: IMAP METADATA Registration 258 Please register the following IMAP METADATA item: 260 [x] Entry [ ] Attribute 262 [ ] Mailbox [x] Server 264 Name: /filters/ 266 Description: Contains an IMAP SEARCH criteria. Defined in RFC XXXX. 268 Content-type: text/plain; charset=utf-8 270 Contact person: Alexey Melnikov 272 Email: alexey.melnikov@isode.com 274 To: iana@iana.org 276 Subject: IMAP METADATA Registration 278 Please register the following IMAP METADATA item: 280 [x] Entry [ ] Attribute 282 [ ] Mailbox [x] Server 284 Name: /filter-descriptions/ 286 Description: Contains a human readable description of a named SEARCH 287 criteria stored in the /filters/ annotation. The 288 value is in UTF-8. Defined in RFC XXXX. 290 Content-type: text/plain; charset=utf-8 291 Contact person: Alexey Melnikov 293 Email: alexey.melnikov@isode.com 295 7. Acknowledgments 297 Thanks to David Cridland and Arnt Gulbrandsen for comments and 298 suggestions on this document. 300 8. Normative References 302 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 303 Syntax Specifications: ABNF", RFC 4234, October 2005. 305 [IMAPABNF] 306 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 307 ABNF", RFC 4466, April 2006. 309 [METADATA] 310 Daboo, C., "IMAP ANNOTATEMORE Extension", 311 draft-daboo-imap-annotatemore-09 (work in progress), 312 March 2006. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 318 4rev1", RFC 3501, March 2003. 320 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 321 10646", RFC 3629, November 2003. 323 Authors' Addresses 325 Curtis King 326 Isode Ltd 327 5 Castle Business Village 328 36 Station Road 329 Hampton, Middlesex TW12 2BX 330 UK 332 Email: Curtis.King@isode.com 333 Alexey Melnikov 334 Isode Ltd 335 5 Castle Business Village 336 36 Station Road 337 Hampton, Middlesex TW12 2BX 338 UK 340 Email: Alexey.Melnikov@isode.com 342 Full Copyright Statement 344 Copyright (C) The IETF Trust (2007). 346 This document is subject to the rights, licenses and restrictions 347 contained in BCP 78, and except as set forth therein, the authors 348 retain all their rights. 350 This document and the information contained herein are provided on an 351 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 352 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 353 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 354 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 355 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 356 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 358 Intellectual Property 360 The IETF takes no position regarding the validity or scope of any 361 Intellectual Property Rights or other rights that might be claimed to 362 pertain to the implementation or use of the technology described in 363 this document or the extent to which any license under such rights 364 might or might not be available; nor does it represent that it has 365 made any independent effort to identify any such rights. Information 366 on the procedures with respect to rights in RFC documents can be 367 found in BCP 78 and BCP 79. 369 Copies of IPR disclosures made to the IETF Secretariat and any 370 assurances of licenses to be made available, or the result of an 371 attempt made to obtain a general license or permission for the use of 372 such proprietary rights by implementers or users of this 373 specification can be obtained from the IETF on-line IPR repository at 374 http://www.ietf.org/ipr. 376 The IETF invites any interested party to bring to its attention any 377 copyrights, patents or patent applications, or other proprietary 378 rights that may cover technology that may be required to implement 379 this standard. Please address the information to the IETF at 380 ietf-ipr@ietf.org. 382 Acknowledgment 384 Funding for the RFC Editor function is provided by the IETF 385 Administrative Support Activity (IASA).