idnits 2.17.1 draft-melnikov-imapext-filters-08.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 464. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 488. 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 (December 11, 2008) is 5613 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) == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-16 ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4646 (Obsoleted by RFC 5646) -- Possible downref: Non-RFC (?) normative reference: ref. 'Unicode' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft C. King 4 Intended status: Standards Track Isode Ltd 5 Expires: June 14, 2009 December 11, 2008 7 IMAP4 extension for named searches (filters) 8 draft-melnikov-imapext-filters-08.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 June 14, 2009. 35 Abstract 37 The document defines a way to persistently store named IMAP (RFC 38 3501) searches on the server. Such named searches can be 39 subsequently referenced in a SEARCH or any other command that accepts 40 a search criterion as a parameter. 42 Table of Contents 44 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 45 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 46 3. IMAP Protocol Changes . . . . . . . . . . . . . . . . . . . . 4 47 3.1. FILTER SEARCH criterion . . . . . . . . . . . . . . . . . 4 48 3.2. Managing filters using SETMETADATA/GETMETADATA commands . 5 49 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 50 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 51 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 52 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 53 8. Normative References . . . . . . . . . . . . . . . . . . . . . 10 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 55 Intellectual Property and Copyright Statements . . . . . . . . . . 12 57 1. Conventions Used in this Document 59 In examples, "C:" and "S:" indicate lines sent by the client and 60 server respectively. If a single "C:" or "S:" label applies to 61 multiple lines, then the line breaks between those lines are for 62 editorial clarity only and are not part of the actual protocol 63 exchange. 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 Basic familiarity with the METADATA-SERVER extension [METADATA] and 70 terms defined therein is required to understand this document. 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 "X-DRAFT-I06-FILTERS" IMAP extension [[anchor4: Note to RFC 81 editor: change upon publication to FILTERS]] adds a new FILTER search 82 criterion for referencing persistent named searches (a.k.a. 83 "filters"), as well as reuses GETMETADATA/SETMETADATA commands 84 [METADATA] for listing/creating/updating/deleting such filters. 86 A filter can be private (only accessible to the logged in user) or 87 public (accessible to all logged in users). Both a private and a 88 public filter with the same name can exist at the same time. If both 89 filter types with the same name exist, the FILTER SEARCH criterion 90 (see Section 3.1) MUST use the value of the private filter, otherwise 91 it MUST use the value of the filter that exists. 93 Let us call a pair of filter name and filter type a "typed filter". 94 Each typed filter can have a value (which is a valid IMAP SEARCH 95 criteria conforming to ABNF for the "search-criteria" non-terminal) 96 and an optional human readable description. The SETMETADATA command 97 creates or updates the value and/or the description of a typed 98 filter. 100 Values of all search keys stored in a filter MUST be encoded in 101 UTF-8. 103 3. IMAP Protocol Changes 105 The IMAP extension for persistent named searches is present in any 106 IMAP4 implementation which advertises "X-DRAFT-I06-FILTERS" 107 [[anchor6: Note to RFC editor: change upon publication to FILTERS]] 108 as one of the supported capabilities in the CAPABILITY response or 109 response code. 111 3.1. FILTER SEARCH criterion 113 The FILTER criterion for the SEARCH command allows a client to 114 reference by name a filter stored on the server. Such filter was 115 created by setting the server annotation named "/private/filters/ 116 values/" (or the server annotation "/public/filters/ 117 values/", if "/private/filters/values/" 118 doesn't exist) using the SETMETADATA command as described in 119 Section 3.2. 121 Syntax: FILTER 123 When the named filter exist, its search criterion (i.e. the 124 associated entry value) is inserted verbatum instead of the FILTER 125 search-key. For example, the following SEARCH command 127 C: a SEARCH UID 300:900 FILTER on-the-road SINCE "3-Dec-2002" 129 would be equivalent to the following 131 C: a SEARCH UID 300:900 OR SMALLER 5000 FROM "boss@example.com" 132 SINCE "3-Dec-2002" 134 assuming the filter "on-the-road" exists and contains the value 'OR 135 SMALLER 5000 FROM "boss@example.com"'. 137 A reference to a non-existent or unaccessible (e.g. due to access 138 control restrictions) filter MUST cause failure of the SEARCH command 139 with the tagged NO response, that includes the UNDEFINED-FILTER 140 response code followed by the name of the non-existent/unaccessible 141 filter. 143 Note the server SHOULD verify that each search criterion referenced 144 by the FILTER search key is a full and correct search criterion. For 145 example, the server should fail the SEARCH command if its SEARCH 146 criterion references a filter containing "OR SMALLER" search 147 criterion, because this value is lacking one parameter and thus is 148 not a fully specified search criterion. 150 Note that a named filter itself can reference another filter using 151 the FILTER search-key. Implementations MUST be able to perform at 152 least 3 substitution passes on the SEARCH command criterion. If an 153 implementation allows for more passes, it MUST implement some kind of 154 loop detection. If an implementation detects a loop or still sees a 155 FILTER search-key after performing at least 3 substitutions, it MUST 156 behave as if the specified filter doesn't exist (as described above). 158 Note that use of the FILTER search key implies the CHARSET "UTF-8" 159 parameter to the SEARCH/UID SEARCH command. If the SEARCH/UID SEARCH 160 command includes the explicit CHARSET parameter with the value other 161 than "UTF-8" or "US-ASCII" then such command MUST result in the 162 tagged BAD response from the server. Such tagged response MUST 163 contain the BADCHARSET response code (see [RFC3501]). 165 3.2. Managing filters using SETMETADATA/GETMETADATA commands 167 Any server compliant with this document MUST either implement the 168 METADATA-SERVER (or METADATA) [METADATA] extension, or implement 169 SETMETADATA/GETMETADATA commands described in [METADATA] so that they 170 work for the case of empty mailbox name (i.e. for managing server 171 annotations) and entries specified in this section. 173 This document reserves hierarchy of per-server entries under the 174 "/private/filters/values" and "/public/filters/values" roots (see 175 [METADATA]) for storing filter values. The value of a "/private/ 176 filters/values/" or a "/public/filters/values/ 177 " server annotation is an IMAP SEARCH criteria, 178 conforming to ABNF for the "search-criteria" non-terminal. A name of 179 a filter is governed by the ABNF for the "filter-name" non-terminal. 181 Note that values of all search keys stored in these entries MUST be 182 encoded in UTF-8. 184 A new filter named "" can be created (or an existing 185 filter can be modified) by storing a non NIL value in the "/private/ 186 filters/values/" server entry (or in the "/public/ 187 filters/values/") using the SETMETADATA [METADATA] 188 command. The server SHOULD verify that each search criterion stored 189 in such server entry is a full and correct search criterion. 191 A filter can be deleted by storing the NIL value in both the 192 "/private/filters/values/" and the "/public/filters/ 193 values/" entries. 195 A filter can be renamed by first creating a filter with the new name 196 (that has the same value as the old one) and then deleting filter 197 with the old one. 199 If both "/private/filters/values/" and "/public/filters/ 200 values/" server annotations exist, then the value of the 201 "/private/filters/values/" is used when evaluating the 202 corresponding FILTER SEARCH key (see Section 3.1). Otherwise the 203 non-NIL (existent) value is used. 205 If the server is unable to create a new typed filter because the 206 maximum number of allowed filters has already been reached, the 207 server MUST return a tagged NO response with a "[METADATA TOOMANY]" 208 response code, as defined in [METADATA]. 210 C: a007 SETMETADATA "" ("/private/filters/values/on-the-road" 211 "OR SMALLER 5000 FROM \"boss@example.com\"") 212 S: a007 OK SETMETADATA complete 214 Client implementation note: As multiple client might read and write 215 filter values, it is possible that one client will use a SEARCH key 216 that might not be recognized by another client that tries to present 217 a UI for editing a filter value. In order to help other clients to 218 [partially] parse filter values for editing purposes, a client 219 storing a filter value SHOULD use () around any SEARCH key not 220 defined in [RFC3501] For example, if there is an IMAP extension that 221 defines a new x-dsfa SEARCH key that takes 2 parameters, then the 222 following SEARCH criterion 'from "@example.com>" x-dsfa from 5' 223 should be stored as 'from "@example.com>" (x-dsfa from 5)'. 225 Note that filter names are restricted to a subset of US-ASCII, as 226 described in Section 4. So they might not always be meaningful to 227 users and thus not necessarily suitable for display purposes. In 228 order to help with storing human readable descriptions of filters, 229 this document also reserves hierarchy of server entries under the 230 "/private/filters/descriptions" and "/public/filters/descriptions" 231 roots. The value of a "/private/filters/descriptions/" 232 or a "/public/filters/descriptions/" server annotation 233 is a human readable description for the filter, encoded 234 in UTF-8 [UTF-8]. If the "/private/filters/descriptions/ 235 " server annotation exists, its value is used by the 236 client as the filter description. Otherwise the value of the 237 "/public/filters/descriptions/" server annotation is 238 used as the filter description. In the absence of both the 239 "/private/filters/descriptions/" and the "/public/ 240 filters/descriptions/" entry the client MAY display the 241 name of the filter as its description. 243 The description string SHOULD be annotated with one or more language 244 tags [RFC4646] as specified in Chapter 16.9 of [Unicode]. In the 245 absence of any language tag, the "i-default" [RFC2277] language 246 SHOULD be assumed. Description in multiple languages MAY be present 247 in a single description string. This is done by concatenating 248 descriptions in multiple languages into a single string, each 249 description prefixed with its language tag, for example 250 "<...description in Russian...><...description in 251 French...>". Note that here is a language tag consisting of 3 252 Unicode characters: , , ; and is a 253 language tag consisting of 6 Unicode characters: , 254 , , . 256 4. Formal Syntax 258 The following syntax specification uses the Augmented Backus-Naur 259 Form (ABNF) notation as specified in [ABNF]. 261 Non-terminals referenced but not defined below are as defined by 262 [RFC3501] or [IMAPABNF]. 264 Except as noted otherwise, all alphabetic characters are case- 265 insensitive. The use of upper or lower case characters to define 266 token strings is for editorial clarity only. Implementations MUST 267 accept these strings in a case-insensitive fashion. 269 capability =/ "X-DRAFT-I06-FILTERS" 270 ;; [[Note to RFC Editor: change the capability 271 ;; name before publication]] 273 search-criteria = search-key *(SP search-key) 275 search-key =/ "FILTER" SP filter-name 276 ;; New SEARCH criterion for referencing filters 278 filter-name = 1* 279 ;; Note that filter-name disallows UTF-8 or 280 ;; the following characters: "(", ")", "{", 281 ;; " ", "%", "*", "]". See definition of 282 ;; ATOM-CHAR [RFC3501]. 284 resp-text-code =/ "UNDEFINED-FILTER" SP filter-name 286 5. Security Considerations 288 General issues relevant to [RFC3501] (in particular to the SEARCH 289 command) and METADATA-SERVER extension [METADATA] are also relevant 290 to this document. 292 Note that excessive use of filters can potentially simplify deny-of- 293 service attacks, especially if combined with poor implementations and 294 lack of loop detection (i.e. detection of filters referencing each 295 other to create a loop). Servers that allow for anonymous access 296 SHOULD NOT allow anonymous users to create/edit/delete filters. 298 Also note that stored filters can potentially dislose personal 299 information about users. When confidentiality of such information is 300 important, clients MUST use TLS and/or SASL security layer (or 301 similar) as recommended in [RFC3501]. Also clients should use 302 private filters instead of public, unless they desire to share such 303 information with other users. 305 As always, it is important to thoroughly test clients and servers 306 when implementing this extension. 308 6. IANA Considerations 310 IMAP4 capabilities are registered by publishing a standards track or 311 IESG approved experimental RFC. The registry is currently located 312 at: 314 http://www.iana.org/assignments/imap4-capabilities 316 This document defines the X-DRAFT-I06-FILTERS [[anchor9: Note to RFC 317 Editor: change before publication to FILTERS]] IMAP capability. IANA 318 is requested to add it to the registry. 320 IANA is also requested to add the following 4 entries to the 321 [METADATA] registry: 323 To: iana@iana.org 325 Subject: IMAP METADATA Entry Registration 327 Type: Server 329 Name: /private/filters/values/ 331 Description: Contains an IMAP SEARCH criteria. Defined in RFC XXXX. 333 Content-type: text/plain; charset=utf-8 335 Contact person: Alexey Melnikov 336 Email: alexey.melnikov@isode.com 338 To: iana@iana.org 340 Subject: IMAP METADATA Entry Registration 342 Type: Server 344 Name: /public/filters/values/ 346 Description: Contains an IMAP SEARCH criterion. Defined in RFC 347 XXXX. 349 Content-type: text/plain; charset=utf-8 351 Contact person: Alexey Melnikov 353 Email: alexey.melnikov@isode.com 355 To: iana@iana.org 357 Subject: IMAP METADATA Entry Registration 359 Type: Server 361 Name: /private/filters/descriptions/ 363 Description: Contains a user specific human readable description of 364 a named SEARCH criterion stored in the /private/filters/values/ 365 or /public/filters/values/ annotation. 366 The value is in UTF-8. Defined in RFC XXXX. 368 Content-type: text/plain; charset=utf-8 370 Contact person: Alexey Melnikov 372 Email: alexey.melnikov@isode.com 374 To: iana@iana.org 376 Subject: IMAP METADATA Entry Registration 378 Type: Server 380 Name: /public/filters/descriptions/ 381 Description: Contains a global (shared among all users) human 382 readable description of a named SEARCH criterion stored in the 383 /private/filters/values/ or /public/filters/values/ 384 annotation. The value is in UTF-8. Defined in RFC 385 XXXX. 387 Content-type: text/plain; charset=utf-8 389 Contact person: Alexey Melnikov 391 Email: alexey.melnikov@isode.com 393 7. Acknowledgments 395 Thanks to David Cridland and Arnt Gulbrandsen for comments and 396 suggestions on this document. Special thank you to Brian E. 397 Carpenter for the GenArt review. 399 8. Normative References 401 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 402 Syntax Specifications: ABNF", RFC 5234, January 2008. 404 [IMAPABNF] 405 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 406 ABNF", RFC 4466, April 2006. 408 [METADATA] 409 Daboo, C., "IMAP METADATA Extension", 410 draft-daboo-imap-annotatemore-16 (work in progress), 411 November 2008. 413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 414 Requirement Levels", BCP 14, RFC 2119, March 1997. 416 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 417 Languages", RFC 2277, January 1998. 419 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 420 4rev1", RFC 3501, March 2003. 422 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 423 Languages", RFC 4646, September 2006. 425 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 426 10646", RFC 3629, November 2003. 428 [Unicode] "The Unicode Standard 5.0", Unicode 5.0, 2007. 430 Authors' Addresses 432 Alexey Melnikov 433 Isode Ltd 434 5 Castle Business Village 435 36 Station Road 436 Hampton, Middlesex TW12 2BX 437 UK 439 Email: Alexey.Melnikov@isode.com 441 Curtis King 442 Isode Ltd 443 5 Castle Business Village 444 36 Station Road 445 Hampton, Middlesex TW12 2BX 446 UK 448 Email: Curtis.King@isode.com 450 Full Copyright Statement 452 Copyright (C) The IETF Trust (2008). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 This document and the information contained herein are provided on an 459 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 460 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 461 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 462 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 463 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 464 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 466 Intellectual Property 468 The IETF takes no position regarding the validity or scope of any 469 Intellectual Property Rights or other rights that might be claimed to 470 pertain to the implementation or use of the technology described in 471 this document or the extent to which any license under such rights 472 might or might not be available; nor does it represent that it has 473 made any independent effort to identify any such rights. Information 474 on the procedures with respect to rights in RFC documents can be 475 found in BCP 78 and BCP 79. 477 Copies of IPR disclosures made to the IETF Secretariat and any 478 assurances of licenses to be made available, or the result of an 479 attempt made to obtain a general license or permission for the use of 480 such proprietary rights by implementers or users of this 481 specification can be obtained from the IETF on-line IPR repository at 482 http://www.ietf.org/ipr. 484 The IETF invites any interested party to bring to its attention any 485 copyrights, patents or patent applications, or other proprietary 486 rights that may cover technology that may be required to implement 487 this standard. Please address the information to the IETF at 488 ietf-ipr@ietf.org.