idnits 2.17.1 draft-melnikov-imapext-filters-07.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 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 474. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 481. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 487. 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 2, 2008) is 5621 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 5, 2009 December 2, 2008 7 IMAP4 extension for named searches (filters) 8 draft-melnikov-imapext-filters-07.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 5, 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 type with the same exist, the FILTER SEARCH criterion (see 90 Section 3.1) is going to use the value of the private filter, 91 otherwise it will 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 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. 190 A filter can be deleted by storing the NIL value in both the 191 "/private/filters/values/" and the "/public/filters/ 192 values/" entries. 194 A filter can be renamed by first creating a filter with the new name 195 (that has the same value as the old one) and then deleting filter 196 with the old one. 198 If both "/private/filters/values/" and "/public/filters/ 199 values/" server annotations exist, then the value of the 200 "/private/filters/values/" is used when evaluating the 201 corresponding FILTER SEARCH key (see Section 3.1). Otherwise the 202 non-NIL (existent) value is used. 204 If the server is unable to create a new typed filter because the 205 maximum number of allowed filters has already been reached, the 206 server MUST return a tagged NO response with a "[METADATA TOOMANY]" 207 response code, as defined in [METADATA]. 209 C: a007 SETMETADATA "" ("/private/filters/values/on-the-road" 210 "OR SMALLER 5000 FROM \"boss@example.com\"") 211 S: a007 OK SETMETADATA complete 213 Client implementation note: As multiple client might read and write 214 filter values, it is possible that one client will use a SEARCH key 215 that might not be recognized by another client that tries to present 216 a UI for editing a filter value. In order to help other clients to 217 [partially] parse filter values for editing purposes, a client 218 storing a filter value SHOULD use () around any SEARCH key not 219 defined in [RFC3501] For example, if there is an IMAP extension that 220 defines a new x-dsfa SEARCH key that takes 2 parameters, then the 221 following SEARCH criterion 'from "@example.com>" x-dsfa from 5' 222 should be stored as 'from "@example.com>" (x-dsfa from 5)'. 224 Note that filter names are restricted to a subset of US-ASCII, as 225 described in Section 4. So they might not always be meaningful to 226 users and thus not necessarily suitable for display purposes. In 227 order to help with storing human readable descriptions of filters, 228 this document also reserves hierarchy of server entries under the 229 "/private/filters/descriptions" and "/public/filters/descriptions" 230 roots. The value of a "/private/filters/descriptions/" 231 or a "/public/filters/descriptions/" server annotation 232 is a human readable description for the filter, encoded 233 in UTF-8 [UTF-8]. If the "/private/filters/descriptions/ 234 " server annotation exists, its value is used by the 235 client as the filter description. Otherwise the value of the 236 "/public/filters/descriptions/" server annotation is 237 used as the filter description. In the absence of both the 238 "/private/filters/descriptions/" and the "/public/ 239 filters/descriptions/" entry the client MAY display the 240 name of the filter as its description. 242 The description string SHOULD be annotated with one or more language 243 tags [RFC4646] as specified in Chapter 16.9 of [Unicode]. In the 244 absence of any language tag, the "i-default" [RFC2277] language 245 SHOULD be assumed. Description in multiple languages MAY be present 246 in a single description string. This is done by concatenating 247 descriptions in multiple languages into a single string, each 248 description prefixed with its language tag, for example 249 "<...description in Russian...><...description in 250 French...>". Note that here is a language tag consisting of 3 251 Unicode characters: , , ; and is a 252 language tag consisting of 6 Unicode characters: , 253 , , . 255 4. Formal Syntax 257 The following syntax specification uses the Augmented Backus-Naur 258 Form (ABNF) notation as specified in [ABNF]. 260 Non-terminals referenced but not defined below are as defined by 261 [RFC3501] or [IMAPABNF]. 263 Except as noted otherwise, all alphabetic characters are case- 264 insensitive. The use of upper or lower case characters to define 265 token strings is for editorial clarity only. Implementations MUST 266 accept these strings in a case-insensitive fashion. 268 capability =/ "X-DRAFT-I06-FILTERS" 269 ;; [[Note to RFC Editor: change the capability 270 ;; name before publication]] 272 search-criteria = search-key *(SP search-key) 274 search-key =/ "FILTER" SP filter-name 275 ;; New SEARCH criterion for referencing filters 277 filter-name = 1* 278 ;; Note that filter-name disallows UTF-8 or 279 ;; the following characters: "(", ")", "{", 280 ;; " ", "%", "*", "]". See definition of 281 ;; ATOM-CHAR [RFC3501]. 283 resp-text-code =/ "UNDEFINED-FILTER" SP filter-name 285 5. Security Considerations 287 General issues relevant to [RFC3501] (in particular to the SEARCH 288 command) and METADATA-SERVER extension [METADATA] are also relevant 289 to this document. 291 Note that excessive use of filters can potentially simplify deny-of- 292 service attacks, especially if combined with poor implementations and 293 lack of loop detection (i.e. detection of filters referencing each 294 other to create a loop). Servers that allow for anonymous access 295 SHOULD NOT allow anonymous users to create/edit/delete filters. 297 Also note that stored filters can potentially dislose personal 298 information about users. When confidentiality of such information is 299 important, clients MUST use TLS and/or SASL security layer (or 300 similar) as recommended in [RFC3501]. Also clients should use 301 private filters instead of public, unless they desire to share such 302 information with other users. 304 As always, it is important to thoroughly test clients and servers 305 when implementing this extension. 307 6. IANA Considerations 309 IMAP4 capabilities are registered by publishing a standards track or 310 IESG approved experimental RFC. The registry is currently located 311 at: 313 http://www.iana.org/assignments/imap4-capabilities 315 This document defines the X-DRAFT-I06-FILTERS [[anchor9: Note to RFC 316 Editor: change before publication to FILTERS]] IMAP capability. IANA 317 is requested to add it to the registry. 319 IANA is also requested to add the following 4 entries to the 320 [METADATA] registry: 322 To: iana@iana.org 324 Subject: IMAP METADATA Entry Registration 326 Type: Server 328 Name: /private/filters/values/ 330 Description: Contains an IMAP SEARCH criteria. Defined in RFC XXXX. 332 Content-type: text/plain; charset=utf-8 334 Contact person: Alexey Melnikov 335 Email: alexey.melnikov@isode.com 337 To: iana@iana.org 339 Subject: IMAP METADATA Entry Registration 341 Type: Server 343 Name: /public/filters/values/ 345 Description: Contains an IMAP SEARCH criterion. Defined in RFC 346 XXXX. 348 Content-type: text/plain; charset=utf-8 350 Contact person: Alexey Melnikov 352 Email: alexey.melnikov@isode.com 354 To: iana@iana.org 356 Subject: IMAP METADATA Entry Registration 358 Type: Server 360 Name: /private/filters/descriptions/ 362 Description: Contains a user specific human readable description of 363 a named SEARCH criterion stored in the /private/filters/values/ 364 or /public/filters/values/ annotation. 365 The value is in UTF-8. Defined in RFC XXXX. 367 Content-type: text/plain; charset=utf-8 369 Contact person: Alexey Melnikov 371 Email: alexey.melnikov@isode.com 373 To: iana@iana.org 375 Subject: IMAP METADATA Entry Registration 377 Type: Server 379 Name: /public/filters/descriptions/ 380 Description: Contains a global (shared among all users) human 381 readable description of a named SEARCH criterion stored in the 382 /private/filters/values/ or /public/filters/values/ 383 annotation. The value is in UTF-8. Defined in RFC 384 XXXX. 386 Content-type: text/plain; charset=utf-8 388 Contact person: Alexey Melnikov 390 Email: alexey.melnikov@isode.com 392 7. Acknowledgments 394 Thanks to David Cridland and Arnt Gulbrandsen for comments and 395 suggestions on this document. Special thank you to Brian E. 396 Carpenter for the GenArt review. 398 8. Normative References 400 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 401 Syntax Specifications: ABNF", RFC 5234, January 2008. 403 [IMAPABNF] 404 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 405 ABNF", RFC 4466, April 2006. 407 [METADATA] 408 Daboo, C., "IMAP METADATA Extension", 409 draft-daboo-imap-annotatemore-16 (work in progress), 410 November 2008. 412 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 413 Requirement Levels", BCP 14, RFC 2119, March 1997. 415 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 416 Languages", RFC 2277, January 1998. 418 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 419 4rev1", RFC 3501, March 2003. 421 [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying 422 Languages", RFC 4646, September 2006. 424 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 425 10646", RFC 3629, November 2003. 427 [Unicode] "The Unicode Standard 5.0", Unicode 5.0, 2007. 429 Authors' Addresses 431 Alexey Melnikov 432 Isode Ltd 433 5 Castle Business Village 434 36 Station Road 435 Hampton, Middlesex TW12 2BX 436 UK 438 Email: Alexey.Melnikov@isode.com 440 Curtis King 441 Isode Ltd 442 5 Castle Business Village 443 36 Station Road 444 Hampton, Middlesex TW12 2BX 445 UK 447 Email: Curtis.King@isode.com 449 Full Copyright Statement 451 Copyright (C) The IETF Trust (2008). 453 This document is subject to the rights, licenses and restrictions 454 contained in BCP 78, and except as set forth therein, the authors 455 retain all their rights. 457 This document and the information contained herein are provided on an 458 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 459 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 460 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 461 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 462 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 463 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 465 Intellectual Property 467 The IETF takes no position regarding the validity or scope of any 468 Intellectual Property Rights or other rights that might be claimed to 469 pertain to the implementation or use of the technology described in 470 this document or the extent to which any license under such rights 471 might or might not be available; nor does it represent that it has 472 made any independent effort to identify any such rights. Information 473 on the procedures with respect to rights in RFC documents can be 474 found in BCP 78 and BCP 79. 476 Copies of IPR disclosures made to the IETF Secretariat and any 477 assurances of licenses to be made available, or the result of an 478 attempt made to obtain a general license or permission for the use of 479 such proprietary rights by implementers or users of this 480 specification can be obtained from the IETF on-line IPR repository at 481 http://www.ietf.org/ipr. 483 The IETF invites any interested party to bring to its attention any 484 copyrights, patents or patent applications, or other proprietary 485 rights that may cover technology that may be required to implement 486 this standard. Please address the information to the IETF at 487 ietf-ipr@ietf.org.