idnits 2.17.1 draft-ietf-extra-imap-fetch-preview-07.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 (December 10, 2019) is 1597 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 EXTRA M. Slusarz 3 Internet-Draft Open-Xchange Inc. 4 Intended status: Standards Track December 10, 2019 5 Expires: June 12, 2020 7 IMAP4 Extension: Message Preview Generation 8 draft-ietf-extra-imap-fetch-preview-07 10 Abstract 12 This document specifies an Internet Message Access Protocol (IMAP) 13 protocol extension allowing a client to request a server-generated 14 abbreviated representation of message data useful as a contextual 15 preview of the entire message. 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 June 12, 2020. 34 Copyright Notice 36 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. PREVIEW Algorithms . . . . . . . . . . . . . . . . . . . . . 5 57 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. text/imap-fetch-preview . . . . . . . . . . . . . . . . . 6 59 5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 7 60 5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 67 10.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Appendix A. Change History (To be removed by RFC Editor before 69 publication) . . . . . . . . . . . . . . . . . . . . 12 70 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 Many modern mail clients display small extracts of the body text as 76 an aid to allow a user to quickly decide whether they are interested 77 in viewing the full message contents. Mail clients implementing the 78 Internet Message Access Protocol [RFC3501] would benefit from a 79 standardized, consistent way to generate these brief previews of 80 messages. 82 Generation of a preview on the server has several benefits. First, 83 it allows consistent representation of previews across all clients. 84 This standardized display can reduce user confusion when using 85 multiple clients, as abbreviated message representations in clients 86 will show identical message contents. 88 Second, server-side preview generation is more efficient. A client- 89 based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE 90 command in order to determine which MIME [RFC2045] body part(s) 91 should be represented in the preview. Subsequently, at least one 92 FETCH BODY command may be needed to retrieve body data used in 93 preview generation. These FETCH commands cannot be pipelined since 94 the BODYSTRUCTURE query must be parsed on the client before the list 95 of parts to be retrieved via the BODY command(s) can be determined. 97 Additionally, it may be difficult to predict the amount of body data 98 that must be retrieved to adequately represent the part via a 99 preview, therefore requiring inefficient fetching of excessive data 100 in order to account for this uncertainty. For example, a preview 101 algorithm to display data contained in a text/html [RFC2854] part 102 will likely strip the markup tags to obtain textual content. 103 However, without fetching the entire content of the part, there is no 104 way to guarantee that sufficient non-tag content will exist unless 105 either 1) the entire part is retrieved or 2) an additional partial 106 FETCH is executed when the client determines that it does not possess 107 sufficient data from a previous partial FETCH to display an adequate 108 representation of the preview. 110 Finally, server generation allows caching in a centralized location. 111 Using server-generated previews allows global generation once per 112 message, and then cached for the retention period of the source 113 message. Retrieval of message data may be expensive within a server, 114 for example, so a server can be configured to reduce its storage 115 retrieval load by pre-generating preview data. 117 A server indicates support for this extension via the "PREVIEW" 118 capability name. 120 2. Conventions Used In This Document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 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 As with all IMAP extension documents, the case used in writing IMAP 138 protocol elements herein is chosen for editorial clarity, and 139 implementations must pay attention to the numbered rules at the 140 beginning of [RFC3501] Section 9. 142 3. FETCH Data Item 144 3.1. Command 146 To retrieve a preview for a message, the "PREVIEW" FETCH attribute is 147 used when issuing a FETCH command. 149 If no algorithm list is provided, the server MUST return data using 150 the text/imap-fetch-preview algorithm. 152 The client may explicitly indicate which algorithm(s) should be used 153 to generate the preview list via a parenthesized list of algorithm 154 names output after the PREVIEW attribute. Unsupported algorithms in 155 the list MUST be ignored. If the list contains no supported 156 algorithms, the server MUST return a tagged BAD response to the FETCH 157 command. 159 The order of the algorithms in the parenthesized list (from left to 160 right) defines the client's priority decision. Duplicate algorithms 161 in the list SHOULD be ignored. For purposes of duplicate detection, 162 priority modifiers (Section 5) should be ignored. A server MUST 163 honor a client's algorithm priority decision. 165 A server should return preview data for the first algorithm that 166 returns non-empty preview text. Empty preview text is defined as 167 either the NIL response or an empty (zero length) string. If no 168 algorithm produces non-empty preview text, the server should respond 169 with the preview data generated by the final algorithm in the list. 171 3.2. Response 173 The algorithm used by the server to generate the preview is returned 174 preceding the preview string. 176 The server returns a variable-length string that is the generated 177 preview for that message. 179 Example: Retrieving preview information in a SELECTed mailbox 181 C: A1 FETCH 1 (PREVIEW) 182 S: * 1 FETCH (PREVIEW (text/imap-fetch-preview "Preview text!")) 183 S: A1 OK FETCH complete. 185 A server SHOULD strive to generate the same string for a given 186 message for each request. However, since previews are understood to 187 be a representation of the message data and not a canonical view of 188 its contents, a client MUST NOT assume that a message preview is 189 immutable for a given message. This relaxed requirement permits a 190 server to offer previews as an option without requiring potentially 191 burdensome storage and/or processing requirements to guarantee 192 immutability for a use case that does not require this strictness. 193 For example, the underlying IMAP server may change for an account due 194 to a software upgrade; account state information may be retained in 195 the migration, but the new server may support a different PREVIEW 196 generation algorithm. Thus, message state may remain the same but 197 the FETCH PREVIEW response may change, if that data was not part of 198 the data migration. 200 It is possible that preview text is not available now, but might be 201 available later -- perhaps the server's preview-generating resources 202 are overloaded, there is a server-imposed timeout during preview 203 generation, or there is some transient issue with fetching the 204 message body. In such cases, the server will return NIL as the 205 preview response, and the client can try to retrieve the preview 206 later. 208 On the other hand, it is possible that the server has determined that 209 no meaningful preview text can be generated for a particular message, 210 and that decision won't change later. Examples of this involve 211 encrypted messages, content types the server does not support 212 previews of, and other situations where the server is not able to 213 extract information for a preview. In such cases, the server will 214 return a zero-length string. Clients should not send another FETCH 215 for a preview for such messages. 217 4. PREVIEW Algorithms 219 4.1. Description 221 Algorithms MUST be named in media type [RFC6838] format. 223 This document defines an extension specific algorithm, text/imap- 224 fetch-preview, that outlines precise semantics regarding the 225 generated preview data. Future documents may define additional 226 PREVIEW specific algorithms. 228 In the absence of a PREVIEW specific algorithm definition, preview 229 generation semantics are server-dependent. If a server supports an 230 algorithm it MUST return preview data in the media type format 231 requested by the client. A client MUST NOT assume that a server 232 supports a preview algorithm not specifically defined in this 233 document. 235 4.2. text/imap-fetch-preview 237 The text/imap-fetch-preview algorithm directs the server to use any 238 internal algorithm it desires, subject to the below limitations, to 239 generate a textual preview for a message. 241 The text/imap-fetch-preview algorithm MUST be implemented by any 242 server that supports the PREVIEW extension. 244 The generated preview text MUST be treated as text/plain [RFC2046] 245 media type data by the client. 247 The generated string MUST NOT be content transfer encoded and MUST be 248 encoded in UTF-8 [RFC3629]. The server SHOULD remove any formatting 249 markup and do what other processing might be useful in rendering the 250 preview as plain text. 252 For purposes of this section, a "preview character" is defined as a 253 single UCS character encoded in UTF-8. Note: a single preview 254 character may compromise multiple octets, so any buffers implemented 255 to conform to the string limitations identified in this document 256 should be sized to prevent possible overflow errors. 258 The server SHOULD limit the length of the preview text to 200 preview 259 characters. This length should provide sufficient data to generally 260 support both various languages (and their different average word 261 lengths) and diverse client display size requirements. 263 The server MUST NOT output preview text longer than 256 preview 264 characters. 266 If the FUZZY algorithm generates a preview that is not based on the 267 body content of the message and the LANGUAGE [RFC5255] extension is 268 supported by the server, the preview text SHOULD be generated 269 according to the language rules that apply to human-readable text. 270 For example, a message that consists of a single image MIME part has 271 no human-readable text from which to generate preview information. 272 Instead, the server may wish to output a description that the message 273 contains an image and describe some attributes of the image, such as 274 image format, size, and filename. This descriptive text is not a 275 product of the message body itself but is rather auto-generated data 276 by the server, and should thus use the rules defined for human- 277 generated text described in the LANGUAGE extension (if supported on 278 the server). 280 5. PREVIEW Priority Modifiers 282 5.1. LAZY 284 The LAZY modifier directs the server to return the preview 285 representation only if that data can be returned without undue delay 286 to the client. 288 The LAZY modifier alters preview generation semantics of the specific 289 algorithm it is applied to. If no algorithm is provided as an 290 argument, the LAZY modifier applies to the text/imap-fetch-preview 291 algorithm. 293 This modifier allows a client to inform the server that preview data 294 is nice-to-have, but the server SHOULD NOT block the return of other 295 FETCH information at the expense of generating the preview data. 297 For example, a client displaying the initial mailbox listing to a 298 user may want to display preview information associated with messages 299 in that listing. However, this information is secondary to providing 300 the mailbox listing, with message details, and the client is willing 301 to load any unavailable previews in the background and display them 302 as they are provided by the server. In this case, the client would 303 apply the LAZY modifier to the desired algorithm(s) to direct the 304 server to only return pre-generated preview data so that retrieval of 305 the other FETCH information is not blocked by possibly expensive 306 preview generation. 308 Generally, the LAZY modifier will only be used once per mailbox load 309 during the initial listing. If preview information is not available 310 during this initial FETCH, the expectation is that a second non-LAZY 311 FETCH will take place after mailbox listing activities are complete. 312 Thus, a maximum of 2 PREVIEW FETCH queries should occur for any 313 message in a selected mailbox. A client SHOULD NOT continually issue 314 LAZY PREVIEW FETCH commands in a selected mailbox as the server is 315 under no requirement to return preview information for this command, 316 which could lead to an unnecessary waste of system and network 317 resources. See Example 4 in the Examples section for how this can be 318 implemented. 320 The LAZY modifier MUST be implemented by any server that supports the 321 PREVIEW extension. 323 6. Examples 324 Example 1: Requesting FETCH without explicit algorithm selection. 326 C: A1 CAPABILITY 327 S: * CAPABILITY IMAP4rev1 PREVIEW 328 S: A1 OK Capability command completed. 329 [...a mailbox is SELECTed...] 330 C: A2 FETCH 1 (RFC822.SIZE PREVIEW) 331 S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW 332 (text/imap-fetch-preview {200} 333 S: Lorem ipsum dolor sit amet, consectetur adipiscing elit. 334 S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue. 335 S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla 336 S: ligula nullam 337 S: )) 338 S: A2 OK FETCH complete. 340 Example 2: Requesting FETCH with explicit algorithm selection. 342 C: B1 FETCH 1 (RFC822.SIZE PREVIEW (text/imap-fetch-preview)) 343 S: * 1 FETCH (RFC822.SIZE 91377 PREVIEW 344 (text/imap-fetch-preview {53} 345 S: Preview text generated from message body text data. 346 S: )) 347 S: B1 OK FETCH complete. 349 Example 3: Requesting FETCH with unknown explicit algorithm 350 selection. 352 C: C1 CAPABILITY 353 S: * CAPABILITY IMAP4rev1 PREVIEW 354 S: C1 OK Capability command completed. 355 [...a mailbox is SELECTed...] 356 C: C2 FETCH 1 (RFC822.SIZE PREVIEW (example/unknown)) 357 S: C2 BAD FETCH contains unknown preview algorithm name. 359 Example 4: Use explicit algorithm priority selection, with LAZY 360 modifier, to obtain previews during initial mailbox listing if 361 readily available; otherwise, load previews in background. 363 C: D1 FETCH 1:3 (ENVELOPE PREVIEW (LAZY)) 364 S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...]) 365 PREVIEW (text/imap-fetch-preview "Preview text for message 1.")) 366 S: * 2 FETCH (PREVIEW (text/imap-fetch-preview "") ENVELOPE 367 ("Thu, 26 Oct 2017 12:17:23 +0000" [...])) 368 S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...]) 369 PREVIEW (text/imap-fetch-preview NIL)) 370 S: D1 OK FETCH completed. 371 [...Client knows that message 2 has a preview that is empty; 372 therefore, client only needs to request message 3 preview again 373 (e.g. in background)...] 374 C: D2 FETCH 3 (PREVIEW (text/imap-fetch-preview)) 375 S: * 3 FETCH (PREVIEW (text/imap-fetch-preview {30} 376 S: Message data from message 3. 377 S: )) 378 S: D2 OK Fetch completed. 380 Example 5: Retrieve preview information for search results within a 381 single mailbox. Use SEARCHRES [RFC5182] extension to save a round- 382 trip. 384 C: E1 CAPABILITY 385 S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES 386 S: E1 OK Capability command completed. 387 [...a mailbox is SELECTed...] 388 C: E2 SEARCH RETURN (SAVE) FROM "FOO" 389 C: E3 FETCH $ (UID PREVIEW (LAZY=text/imap-fetch-preview)) 390 S: E2 OK SEARCH completed. 391 S: * 5 FETCH (UID 13 PREVIEW (text/imap-fetch-preview "Preview!")) 392 S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview NIL)) 393 S: E3 OK FETCH completed. 394 [...Retrieve message 9 preview in background...] 395 C: E4 UID FETCH 23 (PREVIEW (text/imap-fetch-preview)) 396 S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview 397 "Another preview!")) 398 S: E4 OK FETCH completed. 400 7. Formal Syntax 402 The following syntax specification uses the augmented Backus-Naur 403 Form (BNF) as described in ABNF [RFC5234]. It includes definitions 404 from IMAP [RFC3501]. 406 capability =/ "PREVIEW" 408 fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP 409 preview-alg-fetch) ")"] 411 msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")" 413 preview-alg = "text/imap-fetch-preview" / preview-alg-ext 415 preview-alg-ext = preview-atom ; New algorithm names SHOULD be 416 ; registered with IANA and MUST 417 ; conform with the media type 418 ; format described in [RFC6838] 420 preview-alg-fetch = preview-alg / preview-mod ["=" preview-alg] 422 preview-atom = 1*. 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, 472 DOI 10.17487/RFC2119, March 1997, 473 . 475 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 476 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 477 . 479 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 480 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 481 2003, . 483 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 484 Specifications: ABNF", STD 68, RFC 5234, 485 DOI 10.17487/RFC5234, January 2008, 486 . 488 [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 489 Message Access Protocol Internationalization", RFC 5255, 490 DOI 10.17487/RFC5255, June 2008, 491 . 493 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 494 Specifications and Registration Procedures", BCP 13, 495 RFC 6838, DOI 10.17487/RFC6838, January 2013, 496 . 498 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 499 Writing an IANA Considerations Section in RFCs", BCP 26, 500 RFC 8126, DOI 10.17487/RFC8126, June 2017, 501 . 503 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 504 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 505 May 2017, . 507 10.2. Informative References 509 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 510 Extensions (MIME) Part One: Format of Internet Message 511 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 512 . 514 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 515 Type", RFC 2854, DOI 10.17487/RFC2854, June 2000, 516 . 518 [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last 519 SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March 520 2008, . 522 Appendix A. Change History (To be removed by RFC Editor before 523 publication) 525 Changes from draft-slusarz-imap-fetch-snippet-00: 527 o Added standardized language to Section 2 regarding IMAP ABNF 528 conventions 530 o Changed draft name to draft-ietf-extra-imap-fetch-snippet-## 532 Changes from draft-ietf-extra-imap-fetch-snippet-00: 534 o Changed nomenclature from "snippet" to "preview" 536 o Changed draft name to draft-ietf-extra-imap-fetch-preview-## 538 o Update to RFC 8174 boilerplate 540 o Updated length requirements for PREVIEW=FUZZY 542 o Added preview-atom ABNF to limit use of "=" character 544 o UTF-8 is a normative reference 546 o Clarify that characters for purpose of length limitations are 547 defined as UCS characters as encoded by UTF-8 549 o Fix some incorrect literal lengths in examples 550 Changes from draft-ietf-extra-imap-fetch-preview-00: 552 o Updated postal address 554 o Added example to FETCH response section 556 o Added example on how LANGUAGE extension may influence preview 557 generation 559 o Added recommendation that only one LAZY FETCH be executed for a 560 message per mailbox 562 o Added request to create algorithm and modifier registries 564 o Added requirement that algorithm and modifier names conform to RFC 565 6648 567 o Added DoS attack info to security considerations 569 o Distinguish between NIL response and zero-length string 571 o Don't use deprecated "X-" convention in example 573 o Spelling and nits 575 Changes from draft-ietf-extra-imap-fetch-preview-01: 577 o Fix capability ABNF 579 o Removed CAPABILITY string for examples where it did not add 580 valuable context 582 o Altered preview data in examples to cover a variety of potential 583 server return scenarios 585 o Added "SHOULD be registered" language to algorithm names and 586 priority modifiers 588 Changes from draft-ietf-extra-imap-fetch-preview-02: 590 o Move Acknowledgments to un-numbered appendix 592 o Improved abstract text 594 o Consistently use "priority modifiers" instead of "modifiers" 596 o Update example to conform with RFC 3501 UID FETCH requirements 597 Changes from draft-ietf-extra-imap-fetch-preview-03: 599 o Remove preview modifier registry request 601 o Improve instructions for registration of algorithms 603 o Add storage information to security considerations 605 o Clarify parsing of algorithm list in FETCH command 607 o Clarify difference between NIL response and zero-length string 609 o Add normative reference for text/plain 611 o Add warning regarding buffers and multiple octet preview 612 characters 614 o Clarify how to handle preview data return when using an explicit 615 algorithm list 617 o Various editorial fixes 619 Changes from draft-ietf-extra-imap-fetch-preview-04: 621 o Make clear that preview caching is tied to retention period of the 622 source message 624 Changes from draft-ietf-extra-imap-fetch-preview-05: 626 o Clarify "zero-length string" preview data vs. NIL preview data 628 o MIME data -> media type 630 o Capability registration should not include the algorithm name 632 o Give example of how PREVIEW data might change over time 634 Changes from draft-ietf-extra-imap-fetch-preview-06: 636 o Change algorithm names to media types 638 o FUZZY algorithm changed to text/imap-fetch-preview 640 o Remove server broadcast of PREVIEW algorithm extensions from 641 capability 643 o Default, fallback algorithm in absence of client selection now 644 MUST be text/imap-fetch-preview 646 o LAZY modifier should work on default algorithm if no specific 647 algorithm is provided as an argument 649 Acknowledgments 651 The author would like to thank the following people for their 652 comments and contributions to this document: Stephan Bosch, Bron 653 Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba, 654 Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo 655 Sirainen, Steffen Templin, and Aki Tuomi. 657 Author's Address 659 Michael M. Slusarz 660 Open-Xchange Inc. 661 530 Lytton Avenue 662 Palo Alto, California 94301 663 US 665 Email: michael.slusarz@open-xchange.com