draft-ietf-extra-imap-fetch-preview-08.txt   draft-ietf-extra-imap-fetch-preview-09.txt 
EXTRA M. Slusarz EXTRA M. Slusarz
Internet-Draft Open-Xchange Inc. Internet-Draft Open-Xchange Inc.
Intended status: Standards Track July 1, 2020 Intended status: Standards Track July 29, 2020
Expires: January 2, 2021 Expires: January 30, 2021
IMAP4 Extension: Message Preview Generation IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-08 draft-ietf-extra-imap-fetch-preview-09
Abstract Abstract
This document specifies an Internet Message Access Protocol (IMAP) This document specifies an Internet Message Access Protocol (IMAP)
protocol extension allowing a client to request a server-generated protocol extension allowing a client to request a server-generated
abbreviated text representation of message data useful as a abbreviated text representation of message data useful as a
contextual preview of the entire message. contextual preview of the entire message.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2021. This Internet-Draft will expire on January 30, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Conventions Used In This Document . . . . . . . . . . . . . . 3
3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 3 3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3. Preview Text Format . . . . . . . . . . . . . . . . . . . 5 3.3. Preview Text Format . . . . . . . . . . . . . . . . . . . 5
4. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 5 4. LAZY Priority Modifier . . . . . . . . . . . . . . . . . . . 5
4.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Client Implementation Advice . . . . . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 9 publication) . . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Many modern mail clients display small extracts of the body text as 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 an aid to allow a user to quickly decide whether they are interested
in viewing the full message contents. Mail clients implementing the in viewing the full message contents. Mail clients implementing the
Internet Message Access Protocol [RFC3501] would benefit from a Internet Message Access Protocol [RFC3501] would benefit from a
standardized, consistent way to generate these brief textual previews standardized, consistent way to generate these brief textual previews
of messages. of messages.
skipping to change at page 4, line 33 skipping to change at page 4, line 36
its contents, a client MUST NOT assume that a message preview is its contents, a client MUST NOT assume that a message preview is
immutable for a given message. This relaxed requirement permits a immutable for a given message. This relaxed requirement permits a
server to offer previews as an option without requiring potentially server to offer previews as an option without requiring potentially
burdensome storage and/or processing requirements to guarantee burdensome storage and/or processing requirements to guarantee
immutability for a use case that does not require this strictness. immutability for a use case that does not require this strictness.
For example, the underlying IMAP server may change due to a system For example, the underlying IMAP server may change due to a system
software upgrade; an account's state information may be retained in software upgrade; an account's state information may be retained in
the migration but the new server may generate different PREVIEW text the migration but the new server may generate different PREVIEW text
than the old server. than the old server.
It is possible that preview text is not available now, but might be It is possible that the server has determined that no meaningful
available later -- perhaps the server's preview-generating resources preview text can be generated for a particular message, and that
are overloaded, there is a server-imposed timeout during preview decision won't change later. Examples of this involve encrypted
generation, or there is some transient issue with fetching the messages, content types the server does not support previews of, and
message body. In such cases, the server will return NIL as the other situations where the server is not able to extract information
preview response, and the client can try to retrieve the preview for a preview. In such cases, the server MUST return a zero-length
later. string. Clients SHOULD NOT send another FETCH for a preview for such
messages. (As discussed previously, preview data is not immutable so
there is chance that at some point in the future the server would be
able to generate meaningful text. However, this scenario is expected
to be rare so a client should not continually send out requests to
try to capture this infrequent occurrence.)
On the other hand, it is possible that the server has determined that If the LAZY modifier is used, the server MAY return NIL for the
no meaningful preview text can be generated for a particular message, preview response, indicating that preview generation could not be
and that decision won't change later. Examples of this involve completed without causing undue delay. A server MUST NOT return NIL
encrypted messages, content types the server does not support to a FETCH PREVIEW request made without the LAZY modifier.
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. (As discussed previously, preview
data is not immutable so there is chance that at some point in the
future the server would be able to generate meaningful text.
However, this scenario is expected to be rare so a client should not
continually send out requests to try to capture this infrequent
occurrence.
3.3. Preview Text Format 3.3. Preview Text Format
The generated preview text MUST be treated as text/plain [RFC2046] The generated preview text MUST be treated as text/plain [RFC2046]
media type data by the client. media type data by the client.
The generated string MUST NOT be content transfer encoded and MUST be The generated string MUST NOT be content transfer encoded and MUST be
encoded in UTF-8 [RFC3629]. The server SHOULD remove any formatting encoded in UTF-8 [RFC3629]. The server SHOULD remove any formatting
markup and do whatever processing might be useful in rendering the markup and do whatever processing might be useful in rendering the
preview as plain text. preview as plain text.
skipping to change at page 5, line 45 skipping to change at page 5, line 43
message that consists of a single image MIME part has no human- message that consists of a single image MIME part has no human-
readable text from which to generate preview information. Instead, readable text from which to generate preview information. Instead,
the server may wish to output a description that the message contains the server may wish to output a description that the message contains
an image and describe some attributes of the image, such as image an image and describe some attributes of the image, such as image
format, size, and filename. This descriptive text is not a product format, size, and filename. This descriptive text is not a product
of the message body itself but is rather auto-generated data by the of the message body itself but is rather auto-generated data by the
server, and should thus use the rules defined for human-generated server, and should thus use the rules defined for human-generated
text described in the LANGUAGE extension (if supported on the text described in the LANGUAGE extension (if supported on the
server). server).
4. PREVIEW Priority Modifiers 4. LAZY Priority Modifier
4.1. LAZY 4.1. LAZY
The LAZY modifier directs the server to return the preview The LAZY modifier directs the server to return the preview
representation only if that data can be returned without undue delay representation only if that data can be returned without undue delay
to the client. to the client.
This modifier allows a client to inform the server that preview data If this modifier is used, and the server is unable to return preview
is nice-to-have, but the server SHOULD NOT block the return of other data without undue delay, the server MUST return NIL as the preview
FETCH information at the expense of generating the preview data. response.
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
send the LAZY modifier directing the server to only return pre-
generated preview data so that retrieval of the other FETCH
information is not blocked by possibly expensive preview generation.
Generally, the LAZY modifier will only be used once per mailbox load
during the initial listing. If preview information is not available
during this initial FETCH, the expectation is that a second non-LAZY
FETCH will take place after mailbox listing activities are complete.
Thus, a maximum of 2 PREVIEW FETCH queries should occur for any
message in a selected mailbox. A client SHOULD NOT continually issue
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 2 in the Examples section for how this can be
implemented.
The LAZY modifier MUST be implemented by any server that supports the The LAZY modifier MUST be implemented by any server that supports the
PREVIEW extension. PREVIEW extension.
5. Examples 4.2. Client Implementation Advice
Upon opening a mailbox, a client generally performs a FETCH of
message details in order to create a listing to present to the user
(e.g. ENVELOPE data). Using this extension, a client may want to
additional display preview information as part of this listing.
Quickly providing the base mailbox listing, with basic message
details, is the primary goal of this command as this is required to
allow the user to begin interacting with the mailbox. Preview data
is likely to be of secondary importance; it provides useful context,
but it is not necessary to perform message actions. A client can
load unavailable previews in the background and display them
asynchronously to the user as the preview data is provided by the
server.
In this scenario, the client would add the PREVIEW data item, with
the LAZY modifier, to the list of FETCH items needed to generate the
mailbox listing. This allows the server to advantageously return
preview data without blocking the primary goal of quickly returning
the basic message details used to generate the mailbox listing.
Once this initial FETCH is complete, the client can then issue FETCH
requests, without the LAZY modifier, to load the preview data for the
messages in which preview data was not returned. It is RECOMMENDED
that these FETCH requests be issued in small batches, e.g. 50
messages per FETCH command, since preview generation may be expensive
and a single large request may exceed server resource limits.
See Example 2 for an implementation of this strategy.
A client SHOULD NOT continually issue 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.
5. Examples
Example 1: Requesting PREVIEW without LAZY modifier. Example 1: Requesting PREVIEW without LAZY modifier.
C: A1 CAPABILITY C: A1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW S: * CAPABILITY IMAP4rev1 PREVIEW
S: A1 OK Capability command completed. S: A1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
C: A2 FETCH 1 (RFC822.SIZE PREVIEW) C: A2 FETCH 1 (RFC822.SIZE PREVIEW)
S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW {200} S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW {200}
S: Lorem ipsum dolor sit amet, consectetur adipiscing elit. S: Lorem ipsum dolor sit amet, consectetur adipiscing elit.
S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue. S: Curabitur aliquam turpis et ante dictum, et pulvinar dui congue.
S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla S: Maecenas hendrerit, lorem non imperdiet pellentesque, nulla
S: ligula nullam S: ligula nullam
S: ) S: )
S: A2 OK FETCH complete. S: A2 OK FETCH complete.
Example 2: Requesting PREVIEW with LAZY modifier, to obtain previews Example 2: Requesting PREVIEW with LAZY modifier, to obtain previews
during initial mailbox listing if readily available; otherwise, load during initial mailbox listing if readily available; otherwise, load
previews in background. previews in background.
C: D1 FETCH 1:3 (ENVELOPE PREVIEW (LAZY)) C: D1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY))
S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...]) S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...])
PREVIEW "Preview text for message 1.") PREVIEW "Preview text for message 1.")
S: * 2 FETCH (PREVIEW "" ENVELOPE S: * 2 FETCH (PREVIEW "" ENVELOPE
("Thu, 26 Oct 2017 12:17:23 +0000" [...])) ("Thu, 26 Oct 2017 12:17:23 +0000" [...]))
S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...]) S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...])
PREVIEW NIL) PREVIEW NIL)
S: * 4 FETCH (ENVELOPE ("Sat, 28 Oct 2017 07:11:18 +0000" [...])
PREVIEW NIL)
S: D1 OK FETCH completed. S: D1 OK FETCH completed.
[...Client knows that message 2 has a preview that is empty; [...Client has preview for message 1 and knows that message 2 has
therefore, client only needs to request message 3 preview again a preview that is empty; only need to request preview of
(e.g. in background)...] messages 3 & 4 (e.g. in background)...]
C: D2 FETCH 3 (PREVIEW) C: D2 FETCH 3:4 (PREVIEW)
S: * 3 FETCH (PREVIEW {30} S: * 3 FETCH (PREVIEW {30}
S: Message data from message 3. S: Message data from message 3.
S: ) S: )
S: * 4 FETCH (PREVIEW "Message 4 preview")
S: D2 OK Fetch completed. S: D2 OK Fetch completed.
Example 3: Retrieve preview information for search results within a Example 3: Retrieve preview information for search results within a
single mailbox. Use SEARCHRES [RFC5182] extension to save a round- single mailbox. Use SEARCHRES [RFC5182] extension to save a round-
trip. trip.
C: E1 CAPABILITY C: E1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES
S: E1 OK Capability command completed. S: E1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
skipping to change at page 12, line 38 skipping to change at page 13, line 13
MUST be text/imap-fetch-preview MUST be text/imap-fetch-preview
o LAZY modifier should work on default algorithm if no specific o LAZY modifier should work on default algorithm if no specific
algorithm is provided as an argument algorithm is provided as an argument
Changes from draft-ietf-extra-imap-fetch-preview-07: Changes from draft-ietf-extra-imap-fetch-preview-07:
o Remove algorithm selection; PREVIEW always returns text in format o Remove algorithm selection; PREVIEW always returns text in format
defined in Section 3.3 defined in Section 3.3
Changes from draft-ietf-extra-imap-fetch-preview-08:
o FETCH PREVIEW without LAZY modifier MUST NOT return NIL
o Improve client implementation advice for LAZY modifier
Acknowledgments Acknowledgments
The author would like to thank the following people for their The author would like to thank the following people for their
comments and contributions to this document: Stephan Bosch, Bron comments and contributions to this document: Stephan Bosch, Bron
Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba, Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba,
Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo
Sirainen, Steffen Templin, and Aki Tuomi. Sirainen, Steffen Templin, and Aki Tuomi.
Author's Address Author's Address
Michael M. Slusarz Michael M. Slusarz
Open-Xchange Inc. Open-Xchange Inc.
530 Lytton Avenue 530 Lytton Avenue
Palo Alto, California 94301 Palo Alto, California 94301
US US
Email: michael.slusarz@open-xchange.com Email: michael.slusarz@open-xchange.com
 End of changes. 21 change blocks. 
66 lines changed or deleted 85 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/