idnits 2.17.1 draft-slusarz-imap-fetch-snippet-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year -- The document date (April 16, 2018) is 2199 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 3501 (Obsoleted by RFC 9051) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Slusarz 3 Internet-Draft Open-Xchange Inc. 4 Intended status: Standards Track April 16, 2018 5 Expires: October 18, 2018 7 IMAP4 Extension: Message Snippet Generation 8 draft-slusarz-imap-fetch-snippet-00 10 Abstract 12 This document specifies an IMAP protocol extension which allows a 13 client to request that a server provide an abbreviated representation 14 of a message (a snippet of text) that can be used by a client to 15 provide a useful contextual preview of the message contents. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on October 18, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 53 3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. SNIPPET Algorithms . . . . . . . . . . . . . . . . . . . . . 4 57 4.1. FUZZY . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 5. SNIPPET Priority Modifiers . . . . . . . . . . . . . . . . . 5 59 5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 11.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Appendix A. Change History (To be removed by RFC Editor before 69 publication) . . . . . . . . . . . . . . . . . . . . 10 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 Many modern mail clients display small extracts of the body text as 75 an aid to allow a user to quickly decide whether they are interested 76 in viewing the full message contents. Mail clients implementing the 77 Internet Message Access Protocol (IMAP; RFC 3501 [RFC3501]) would 78 benefit from a standardized, consistent way to generate these brief 79 previews of messages (a "snippet"). 81 Generation of snippets on the server has several benefits. First, it 82 allows consistent representation of snippets across all clients. 83 This standardized display can reduce user confusion when using 84 multiple clients, as abbreviated message representations in clients 85 will show identical message details. 87 Second, server-side snippet generation is more efficient. A client- 88 based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE 89 command in order to determine which MIME [RFC2045] body part(s) 90 should be represented in the snippet. Subsequently, at least one 91 FETCH BODY command may be needed to retrieve body data used in 92 snippet generation. These FETCH commands cannot be pipelined since 93 the BODYSTRUCTURE query must be parsed on the client before the list 94 of parts to be retrieved via the BODY command(s) can be determined. 96 Additionally, it may be difficult to predict the amount of body data 97 that must be retrieved to adequately represent the part via a 98 snippet, therefore requiring inefficient fetching of excessive data 99 in order to account for this uncertainty. For example, a snippet 100 algorithm to display data contained in a text/html [RFC2854] part 101 will likely strip the markup tags to obtain textual content. 102 However, without fetching the entire content of the part, there is no 103 way to guarantee that sufficient non-tag content will exist unless 104 either 1) the entire part is retrieved or 2) an additional partial 105 FETCH is executed when the client determines that it does not possess 106 sufficient data from a previous partial FETCH to display an adequate 107 representation of the snippet. 109 Finally, server generation allows caching in a centralized location. 110 Using server generated snippets allows snippets to be generated 111 globally once per message, and then cached indefinitely. Retrieval 112 of message data may be expensive within a server, for example, so a 113 server can be configured to reduce its storage retrieval load by pre- 114 generating snippet data. 116 A server that supports the SNIPPET extension indicates this with one 117 or more capability names consisting of "SNIPPET=" followed by a 118 supported snippet algorithm name. This format provides for future 119 upwards-compatible extensions and/or the ability to use locally- 120 defined snippet algorithms. 122 2. Conventions Used In This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [RFC2119]. 128 "User" is used to refer to a human user, whereas "client" refers to 129 the software being run by the user. 131 In examples, "C:" and "S:" indicate lines sent by the client and 132 server respectively. If a single "C:" or "S:" label applies to 133 multiple lines, then the line breaks between those lines are for 134 editorial clarity only and are not part of the actual protocol 135 exchange. 137 3. FETCH Data Item 139 3.1. Command 141 To retrieve a snippet for a message, the "SNIPPET" FETCH attribute is 142 used when issuing a FETCH command. 144 If no algorithm identifier is provided, the server decides which of 145 its built-in algorithms to use to generate the snippet text. 147 Alternately, the client may explicitly indicate which algorithm(s) 148 should be used in a parenthesized list after the SNIPPET attribute 149 containing the name of the algorithm. These algorithms MUST be one 150 of the algorithms identified as supported in the SNIPPET capability 151 responses. If a client requests an algorithm that is unsupported, 152 the server MUST return a tagged BAD response. 154 The order of the algorithms in the parenthesized list (from left to 155 right) defines the client's priority decision. Duplicate algorithms 156 in the list SHOULD be ignored. For purposes of duplicate detection, 157 priority modifiers (Section 5) should be ignored. A server MUST 158 honor a client's algorithm priority decision. 160 3.2. Response 162 The algorithm used by the server to generate the snippet is returned 163 preceding the snippet string. 165 The server returns a variable-length string that is the generated 166 snippet for that message. 168 A server SHOULD strive to generate the same string for a given 169 message for each request. However, since snippets are understood to 170 be a representation of the message data and not a canonical view of 171 its contents, a client MUST NOT assume that a message snippet is 172 immutable for a given message. This relaxed requirement permits a 173 server to offer snippets as an option without requiring potentially 174 burdensome storage and/or processing requirements to guarantee 175 immutability for a use case that does not require this strictness. 177 If the snippet is not available, the server MUST return NIL as the 178 SNIPPET response. A NIL response indicates to the client that 179 snippet information MAY become available in a future SNIPPET FETCH 180 request. 182 4. SNIPPET Algorithms 184 4.1. FUZZY 186 The FUZZY algorithm directs the server to use any internal algorithm 187 it desires, subject to the below limitations, to generate a textual 188 snippet for a message. 190 The FUZZY algorithm MUST be implemented by any server that supports 191 the SNIPPET extension. 193 The generated string MUST NOT be content transfer encoded and MUST be 194 encoded in UTF-8 [RFC3629]. 196 The snippet text MUST be treated as text/plain MIME data by the 197 client. 199 The server SHOULD limit the length of the snippet text to 100 200 characters. The server MUST NOT output snippet text longer than 200 201 characters. 203 The server SHOULD remove any formatting markup that exists in the 204 original text. 206 If the FUZZY algorithm generates a snippet that is not based on the 207 body content of the message and the LANGUAGE [RFC5255] extension is 208 supported by the server, the snippet text SHOULD be generated 209 according to the the language rules that apply to human-readable 210 text. 212 5. SNIPPET Priority Modifiers 214 5.1. LAZY 216 The LAZY modifier directs the server to return the snippet 217 representation only if that data can be returned without undue delay 218 to the client. 220 This modifier allows a client to inform the server that snippet data 221 is nice-to-have, but the server SHOULD NOT block the return of other 222 FETCH information at the expense of generating the snippet data. 224 For example, a client displaying the initial mailbox listing to a 225 user may want to display snippet information associated with messages 226 in that listing. However, this information is secondary to providing 227 the mailbox listing, with message details, and the client is willing 228 to load any unavailable snippets in the background and display them 229 as they are provided by the server. In this case, the client would 230 use the LAZY modifier to the desired algorithm(s) to direct the 231 server to only return pre-generated snippet data so that retrieval of 232 the other FETCH information is not blocked by possibly expensive 233 snippet generation. 235 The LAZY modifier MUST be implemented by any server that supports the 236 SNIPPET extension. 238 6. Examples 240 Example 1: Requesting FETCH without explicit algorithm selection 242 C: A1 CAPABILITY 243 S: * CAPABILITY IMAP4rev1 SNIPPET=FUZZY 244 S: A1 OK Capability command completed. 245 [...a mailbox is SELECTed...] 246 C: A2 FETCH 1 (RFC822.SIZE SNIPPET) 247 S: * 1 FETCH (RFC822.SIZE 20000 SNIPPET (FUZZY {61} 248 S: This is the first line of text from the first text part. 249 S: )) 250 S: A2 OK FETCH complete. 252 Example 2: Requesting FETCH with explicit algorithm selection 254 C: B1 CAPABILITY 255 S: * CAPABILITY IMAP4rev1 SNIPPET=FUZZY 256 S: B1 OK Capability command completed. 257 [...a mailbox is SELECTed...] 258 C: B2 FETCH 1 (RFC822.SIZE SNIPPET (FUZZY)) 259 S: * 1 FETCH (RFC822.SIZE 20000 SNIPPET (FUZZY {61} 260 S: This is the first line of text from the first text part. 261 S: )) 262 S: B2 OK FETCH complete. 264 Example 3: Requesting FETCH with invalid explicit algorithm selection 266 C: C1 CAPABILITY 267 S: * CAPABILITY IMAP4rev1 SNIPPET=FUZZY 268 S: C1 OK Capability command completed. 269 [...a mailbox is SELECTed...] 270 C: C2 FETCH 1 (RFC822.SIZE SNIPPET (X-SNIPPET-ALGO)) 271 S: C2 BAD FETCH contains invalid snippet algorithm name. 273 Example 4: Use explicit algorithm priority selection, with LAZY 274 modifier, to obtain snippets during initial mailbox listing if 275 readily available; otherwise, load snippets in background 277 C: D1 CAPABILITY 278 S: * CAPABILITY IMAP4rev1 SNIPPET=FUZZY 279 S: D1 OK Capability command completed. 280 [...a mailbox is SELECTed...] 281 C: D2 FETCH 1:3 (ENVELOPE SNIPPET (LAZY=FUZZY)) 282 S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...]) 283 SNIPPET (FUZZY {61} 284 S: This is the first line of text from the first text part. 285 S: )) 286 S: * 2 FETCH (SNIPPET (FUZZY "") ENVELOPE 287 ("Thu, 26 Oct 2017 12:17:23 +0000" [...])) 288 S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...]) 289 SNIPPET (FUZZY NIL)) 290 S: D2 OK FETCH completed. 291 [...Client knows that message 2 has a snippet that is empty; 292 therefore, client only needs to request message 3 snippet again 293 (e.g. in background)...] 294 C: D3 FETCH 3 (SNIPPET (FUZZY)) 295 S: * 3 FETCH (SNIPPET (FUZZY {25} 296 S: First sentence of mail 3. 297 S: )) 298 S: D3 OK Fetch completed. 300 Example 5: Retrieve snippet information for search results within a 301 single mailbox. Use SEARCHRES [RFC5182] extension to save a round- 302 trip. 304 C: E1 CAPABILITY 305 S: * CAPABILITY IMAP4rev1 SNIPPET=FUZZY SEARCHRES 306 S: E1 OK Capability command completed. 307 [...a mailbox is SELECTed...] 308 C: E2 SEARCH RETURN (SAVE) FROM "FOO" 309 C: E3 FETCH $ (UID SNIPPET (LAZY=FUZZY)) 310 S: E2 OK SEARCH completed. 311 S: * 5 FETCH (UID 13 SNIPPET (FUZZY {9} 312 S: Snippet! 313 S: )) 314 S: * 9 FETCH (UID 23 SNIPPET (FUZZY NIL)) 315 S: E3 OK FETCH completed. 316 [...Retrieve message 9 snippet in background...] 317 C: E4 UID FETCH 23 (SNIPPET (FUZZY)) 318 S: * 9 FETCH (SNIPPET (FUZZY {17} 319 S: Another snippet! 320 S: )) 321 S: E4 OK FETCH completed. 323 7. Formal Syntax 325 The following syntax specification uses the augmented Backus-Naur 326 Form (BNF) as described in ABNF [RFC5234]. It includes definitions 327 from IMAP [RFC3501]. 329 capability =/ "SNIPPET=FUZZY" 331 fetch-att =/ "SNIPPET" [SP "(" snippet-alg-fetch *(SP 332 snippet-alg-fetch) ")"] 334 msg-att-dynamic =/ "SNIPPET" SP "(" snippet-alg SP nstring ")" 336 snippet-alg = "FUZZY" / snippet-alg-ext 338 snippet-alg-ext = atom ; New algorithms MUST be registered with 339 ; IANA 341 snippet-alg-fetch = snippet-alg / snippet-mod "=" snippet-alg 343 snippet-mod = "LAZY" / snippet-mod-ext 345 snippet-mod-ext = atom ; New priority modifiers MUST be 346 ; registered with IANA 348 8. Acknowledgements 350 The author would like to thank the following people for their 351 comments and contributions to this document: Stephan Bosch, Teemu 352 Huovila, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi. 354 9. IANA Considerations 356 IMAP4 [RFC3501] capabilities are registered by publishing a standards 357 track or IESG-approved experimental RFC. The registry is currently 358 located at: 360 http://www.iana.org/assignments/imap-capabilities 362 This document requests that IANA adds the "SNIPPET=FUZZY" capability 363 to the IMAP4 [RFC3501] capabilities registry. 365 10. Security Considerations 367 There are no known additional security issues with this extension 368 beyond those described in the base protocol described in IMAP4 369 [RFC3501]. 371 11. References 373 11.1. Normative References 375 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 376 Requirement Levels", BCP 14, RFC 2119, 377 DOI 10.17487/RFC2119, March 1997, 378 . 380 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 381 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 382 . 384 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 385 Specifications: ABNF", STD 68, RFC 5234, 386 DOI 10.17487/RFC5234, January 2008, 387 . 389 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 390 Message Access Protocol Internationalization", RFC 5255, 391 DOI 10.17487/RFC5255, June 2008, 392 . 394 11.2. Informative References 396 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 397 Extensions (MIME) Part One: Format of Internet Message 398 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 399 . 401 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 402 Type", RFC 2854, DOI 10.17487/RFC2854, June 2000, 403 . 405 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 406 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 407 2003, . 409 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last 410 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 411 2008, . 413 Appendix A. Change History (To be removed by RFC Editor before 414 publication) 416 Changes from draft-slusarz-imap-fetch-snippet-00: 418 o TODO 420 Author's Address 422 Michael Slusarz 423 Open-Xchange Inc. 424 Denver, Colorado 425 US 427 Email: michael.slusarz@open-xchange.com