--- 1/draft-ietf-extra-imap-fetch-preview-06.txt 2019-12-10 17:13:11.948587437 -0800 +++ 2/draft-ietf-extra-imap-fetch-preview-07.txt 2019-12-10 17:13:11.980588255 -0800 @@ -1,18 +1,18 @@ EXTRA M. Slusarz Internet-Draft Open-Xchange Inc. -Intended status: Standards Track July 1, 2019 -Expires: January 2, 2020 +Intended status: Standards Track December 10, 2019 +Expires: June 12, 2020 IMAP4 Extension: Message Preview Generation - draft-ietf-extra-imap-fetch-preview-06 + draft-ietf-extra-imap-fetch-preview-07 Abstract This document specifies an Internet Message Access Protocol (IMAP) protocol extension allowing a client to request a server-generated abbreviated representation of message data useful as a contextual preview of the entire message. Status of This Memo @@ -22,21 +22,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 2, 2020. + This Internet-Draft will expire on June 12, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -47,34 +47,35 @@ described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used In This Document . . . . . . . . . . . . . . 3 3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 4. PREVIEW Algorithms . . . . . . . . . . . . . . . . . . . . . 5 - 4.1. FUZZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 6 - 5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 + 4.2. text/imap-fetch-preview . . . . . . . . . . . . . . . . . 6 + 5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 7 + 5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 - 10.2. Informative References . . . . . . . . . . . . . . . . . 11 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Change History (To be removed by RFC Editor before publication) . . . . . . . . . . . . . . . . . . . . 12 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Many modern mail clients display small extracts of the body text as an aid to allow a user to quickly decide whether they are interested in viewing the full message contents. Mail clients implementing the Internet Message Access Protocol [RFC3501] would benefit from a standardized, consistent way to generate these brief previews of messages. @@ -106,25 +107,22 @@ sufficient data from a previous partial FETCH to display an adequate representation of the preview. Finally, server generation allows caching in a centralized location. Using server-generated previews allows global generation once per message, and then cached for the retention period of the source message. Retrieval of message data may be expensive within a server, for example, so a server can be configured to reduce its storage retrieval load by pre-generating preview data. - A server indicates support for this extension by listing one or more - capability names consisting of "PREVIEW=" followed by a supported - preview algorithm name. This format provides for future upwards- - compatible extensions and/or the ability to use locally-defined - preview algorithms. + A server indicates support for this extension via the "PREVIEW" + capability name. 2. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. "User" is used to refer to a human user, whereas "client" refers to @@ -141,22 +139,22 @@ implementations must pay attention to the numbered rules at the beginning of [RFC3501] Section 9. 3. FETCH Data Item 3.1. Command To retrieve a preview for a message, the "PREVIEW" FETCH attribute is used when issuing a FETCH command. - If no algorithm list is provided, the server decides which of its - built-in algorithms to use to generate the preview text. + If no algorithm list is provided, the server MUST return data using + the text/imap-fetch-preview algorithm. The client may explicitly indicate which algorithm(s) should be used to generate the preview list via a parenthesized list of algorithm names output after the PREVIEW attribute. Unsupported algorithms in the list MUST be ignored. If the list contains no supported algorithms, the server MUST return a tagged BAD response to the FETCH command. The order of the algorithms in the parenthesized list (from left to right) defines the client's priority decision. Duplicate algorithms @@ -174,21 +172,21 @@ The algorithm used by the server to generate the preview is returned preceding the preview string. The server returns a variable-length string that is the generated preview for that message. Example: Retrieving preview information in a SELECTed mailbox C: A1 FETCH 1 (PREVIEW) - S: * 1 FETCH (PREVIEW (FUZZY "Preview text!")) + S: * 1 FETCH (PREVIEW (text/imap-fetch-preview "Preview text!")) S: A1 OK FETCH complete. A server SHOULD strive to generate the same string for a given message for each request. However, since previews are understood to be a representation of the message data and not a canonical view of its contents, a client MUST NOT assume that a message preview is immutable for a given message. This relaxed requirement permits a server to offer previews as an option without requiring potentially burdensome storage and/or processing requirements to guarantee immutability for a use case that does not require this strictness. @@ -211,47 +209,63 @@ no meaningful preview text can be generated for a particular message, and that decision won't change later. Examples of this involve encrypted messages, content types the server does not support previews of, and other situations where the server is not able to extract information for a preview. In such cases, the server will return a zero-length string. Clients should not send another FETCH for a preview for such messages. 4. PREVIEW Algorithms -4.1. FUZZY +4.1. Description - The FUZZY algorithm directs the server to use any internal algorithm - it desires, subject to the below limitations, to generate a textual - preview for a message. + Algorithms MUST be named in media type [RFC6838] format. - The FUZZY algorithm MUST be implemented by any server that supports - the PREVIEW extension. + This document defines an extension specific algorithm, text/imap- + fetch-preview, that outlines precise semantics regarding the + generated preview data. Future documents may define additional + PREVIEW specific algorithms. - The preview text MUST be treated as text/plain [RFC2046] media type - data by the client. + In the absence of a PREVIEW specific algorithm definition, preview + generation semantics are server-dependent. If a server supports an + algorithm it MUST return preview data in the media type format + requested by the client. A client MUST NOT assume that a server + supports a preview algorithm not specifically defined in this + document. + +4.2. text/imap-fetch-preview + + The text/imap-fetch-preview algorithm directs the server to use any + internal algorithm it desires, subject to the below limitations, to + generate a textual preview for a message. + + The text/imap-fetch-preview algorithm MUST be implemented by any + server that supports the PREVIEW extension. + + The generated preview text MUST be treated as text/plain [RFC2046] + media type data by the client. The generated string MUST NOT be content transfer encoded and MUST be encoded in UTF-8 [RFC3629]. The server SHOULD remove any formatting markup and do what other processing might be useful in rendering the preview as plain text. For purposes of this section, a "preview character" is defined as a single UCS character encoded in UTF-8. Note: a single preview character may compromise multiple octets, so any buffers implemented to conform to the string limitations identified in this document should be sized to prevent possible overflow errors. The server SHOULD limit the length of the preview text to 200 preview characters. This length should provide sufficient data to generally support both various languages (and their different average word - lengths) and different client display size requirements. + lengths) and diverse client display size requirements. The server MUST NOT output preview text longer than 256 preview characters. If the FUZZY algorithm generates a preview that is not based on the body content of the message and the LANGUAGE [RFC5255] extension is supported by the server, the preview text SHOULD be generated according to the language rules that apply to human-readable text. For example, a message that consists of a single image MIME part has no human-readable text from which to generate preview information. @@ -264,20 +278,25 @@ the server). 5. PREVIEW Priority Modifiers 5.1. LAZY The LAZY modifier directs the server to return the preview representation only if that data can be returned without undue delay to the client. + The LAZY modifier alters preview generation semantics of the specific + algorithm it is applied to. If no algorithm is provided as an + argument, the LAZY modifier applies to the text/imap-fetch-preview + algorithm. + This modifier allows a client to inform the server that preview data is nice-to-have, but the server SHOULD NOT block the return of other FETCH information at the expense of generating the preview data. For example, a client displaying the initial mailbox listing to a user may want to display preview information associated with messages in that listing. However, this information is secondary to providing the mailbox listing, with message details, and the client is willing to load any unavailable previews in the background and display them as they are provided by the server. In this case, the client would @@ -295,138 +314,139 @@ LAZY PREVIEW FETCH commands in a selected mailbox as the server is under no requirement to return preview information for this command, which could lead to an unnecessary waste of system and network resources. See Example 4 in the Examples section for how this can be implemented. The LAZY modifier MUST be implemented by any server that supports the PREVIEW extension. 6. Examples - Example 1: Requesting FETCH without explicit algorithm selection. C: A1 CAPABILITY - S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY + S: * CAPABILITY IMAP4rev1 PREVIEW S: A1 OK Capability command completed. [...a mailbox is SELECTed...] C: A2 FETCH 1 (RFC822.SIZE PREVIEW) - S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW (FUZZY {200} + S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW + (text/imap-fetch-preview {200} S: Lorem ipsum dolor sit amet, consectetur adipiscing elit. S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue. S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla S: ligula nullam S: )) S: A2 OK FETCH complete. Example 2: Requesting FETCH with explicit algorithm selection. - C: B1 FETCH 1 (RFC822.SIZE PREVIEW (FUZZY)) - S: * 1 FETCH (RFC822.SIZE 91377 PREVIEW (FUZZY {53} + C: B1 FETCH 1 (RFC822.SIZE PREVIEW (text/imap-fetch-preview)) + S: * 1 FETCH (RFC822.SIZE 91377 PREVIEW + (text/imap-fetch-preview {53} S: Preview text generated from message body text data. S: )) S: B1 OK FETCH complete. - Example 3: Requesting FETCH with invalid explicit algorithm + Example 3: Requesting FETCH with unknown explicit algorithm selection. C: C1 CAPABILITY - S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY + S: * CAPABILITY IMAP4rev1 PREVIEW S: C1 OK Capability command completed. [...a mailbox is SELECTed...] - C: C2 FETCH 1 (RFC822.SIZE PREVIEW (UNKNOWN-PREVIEW-ALGO)) - S: C2 BAD FETCH contains invalid preview algorithm name. + C: C2 FETCH 1 (RFC822.SIZE PREVIEW (example/unknown)) + S: C2 BAD FETCH contains unknown preview algorithm name. Example 4: Use explicit algorithm priority selection, with LAZY modifier, to obtain previews during initial mailbox listing if readily available; otherwise, load previews in background. - C: D1 FETCH 1:3 (ENVELOPE PREVIEW (LAZY=FUZZY)) + C: D1 FETCH 1:3 (ENVELOPE PREVIEW (LAZY)) S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...]) - PREVIEW (FUZZY "Preview text for message 1.")) - S: * 2 FETCH (PREVIEW (FUZZY "") ENVELOPE + PREVIEW (text/imap-fetch-preview "Preview text for message 1.")) + S: * 2 FETCH (PREVIEW (text/imap-fetch-preview "") ENVELOPE ("Thu, 26 Oct 2017 12:17:23 +0000" [...])) S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...]) - PREVIEW (FUZZY NIL)) + PREVIEW (text/imap-fetch-preview NIL)) S: D1 OK FETCH completed. [...Client knows that message 2 has a preview that is empty; therefore, client only needs to request message 3 preview again (e.g. in background)...] - C: D2 FETCH 3 (PREVIEW (FUZZY)) - S: * 3 FETCH (PREVIEW (FUZZY {30} + C: D2 FETCH 3 (PREVIEW (text/imap-fetch-preview)) + S: * 3 FETCH (PREVIEW (text/imap-fetch-preview {30} S: Message data from message 3. S: )) S: D2 OK Fetch completed. Example 5: Retrieve preview information for search results within a single mailbox. Use SEARCHRES [RFC5182] extension to save a round- trip. C: E1 CAPABILITY - S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY SEARCHRES + S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES S: E1 OK Capability command completed. [...a mailbox is SELECTed...] C: E2 SEARCH RETURN (SAVE) FROM "FOO" - C: E3 FETCH $ (UID PREVIEW (LAZY=FUZZY)) + C: E3 FETCH $ (UID PREVIEW (LAZY=text/imap-fetch-preview)) S: E2 OK SEARCH completed. - S: * 5 FETCH (UID 13 PREVIEW (FUZZY "Preview!")) - S: * 9 FETCH (UID 23 PREVIEW (FUZZY NIL)) + S: * 5 FETCH (UID 13 PREVIEW (text/imap-fetch-preview "Preview!")) + S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview NIL)) S: E3 OK FETCH completed. [...Retrieve message 9 preview in background...] - C: E4 UID FETCH 23 (PREVIEW (FUZZY)) - S: * 9 FETCH (UID 23 PREVIEW (FUZZY "Another preview!")) + C: E4 UID FETCH 23 (PREVIEW (text/imap-fetch-preview)) + S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview + "Another preview!")) S: E4 OK FETCH completed. 7. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in ABNF [RFC5234]. It includes definitions from IMAP [RFC3501]. - capability =/ "PREVIEW=" preview-alg + capability =/ "PREVIEW" fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP preview-alg-fetch) ")"] msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")" - preview-alg = "FUZZY" / preview-alg-ext + preview-alg = "text/imap-fetch-preview" / preview-alg-ext preview-alg-ext = preview-atom ; New algorithm names SHOULD be ; registered with IANA and MUST - ; conform with the - ; recommendations described in - ; [RFC6648], Section 3 + ; conform with the media type + ; format described in [RFC6838] - preview-alg-fetch = preview-alg / preview-mod "=" preview-alg + preview-alg-fetch = preview-alg / preview-mod ["=" preview-alg] preview-atom = 1*. [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, DOI 10.17487/RFC5255, June 2008, . - [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, - "Deprecating the "X-" Prefix and Similar Constructs in - Application Protocols", BCP 178, RFC 6648, - DOI 10.17487/RFC6648, June 2012, - . + [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type + Specifications and Registration Procedures", BCP 13, + RFC 6838, DOI 10.17487/RFC6838, January 2013, + . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . @@ -606,27 +624,42 @@ Changes from draft-ietf-extra-imap-fetch-preview-05: o Clarify "zero-length string" preview data vs. NIL preview data o MIME data -> media type o Capability registration should not include the algorithm name o Give example of how PREVIEW data might change over time + Changes from draft-ietf-extra-imap-fetch-preview-06: + + o Change algorithm names to media types + + o FUZZY algorithm changed to text/imap-fetch-preview + + o Remove server broadcast of PREVIEW algorithm extensions from + capability + + o Default, fallback algorithm in absence of client selection now + MUST be text/imap-fetch-preview + + o LAZY modifier should work on default algorithm if no specific + algorithm is provided as an argument + Acknowledgments The author would like to thank the following people for their comments and contributions to this document: Stephan Bosch, Bron - Gondwana, Teemu Huovila, Steffen Lehmann, Barry Leiba, Alexey - Melnikov, Chris Newman, Jeff Sipek, Timo Sirainen, Steffen Templin, - and Aki Tuomi. + Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba, + Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo + Sirainen, Steffen Templin, and Aki Tuomi. Author's Address Michael M. Slusarz Open-Xchange Inc. 530 Lytton Avenue Palo Alto, California 94301 US Email: michael.slusarz@open-xchange.com