draft-ietf-extra-imap-fetch-preview-10.txt   rfc8970.txt 
EXTRA M. Slusarz Internet Engineering Task Force (IETF) M. Slusarz
Internet-Draft Open-Xchange Inc. Request for Comments: 8970 Open-Xchange Inc.
Intended status: Standards Track September 30, 2020 Category: Standards Track December 2020
Expires: April 3, 2021 ISSN: 2070-1721
IMAP4 Extension: Message Preview Generation IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-10
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 that allows a client to request a server-generated
abbreviated text representation of message data useful as a abbreviated text representation of message data that is useful as a
contextual preview of the entire message. contextual preview of the entire message.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on April 3, 2021. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8970.
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. Conventions Used In This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document
3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 4 3. FETCH Data Item
3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Command
3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Response
3.3. Preview Text Format . . . . . . . . . . . . . . . . . . . 5 3.3. Preview Text Format
4. LAZY Priority Modifier . . . . . . . . . . . . . . . . . . . 5 4. LAZY Priority Modifier
4.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. LAZY
4.2. Client Implementation Advice . . . . . . . . . . . . . . 6 4.2. Client Implementation Advice
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Examples
6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Formal Syntax
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References
Appendix A. Change History (To be removed by RFC Editor before Acknowledgments
publication) . . . . . . . . . . . . . . . . . . . . 10 Author's Address
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
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.
Generation of a preview on the server has several benefits. First, Generation of a preview on the server has several benefits. First,
it allows consistent representation of previews across all clients. it allows consistent representation of previews across all clients.
This standardized display can reduce user confusion when using While different clients might generate quite different preview text,
multiple clients, as abbreviated message representations in clients having common preview text generated by the server can give a more
will show identical message contents. consistent user experience to those who use multiple clients.
Second, server-side preview generation is more efficient. A client- Second, server-side preview generation is more efficient. A client-
based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE
command in order to determine which MIME [RFC2045] body part(s) command in order to determine which MIME [RFC2045] body part(s)
should be represented in the preview. Subsequently, at least one should be represented in the preview. Subsequently, at least one
FETCH BODY command may be needed to retrieve body data used in FETCH BODY command may be needed to retrieve body data used in
preview generation. These FETCH commands cannot be pipelined since preview generation. These FETCH commands cannot be pipelined since
the BODYSTRUCTURE query must be parsed on the client before the list the BODYSTRUCTURE query must be parsed on the client before the list
of parts to be retrieved via the BODY command(s) can be determined. of parts to be retrieved via the BODY command(s) can be determined.
skipping to change at page 3, line 28 skipping to change at line 113
Finally, server generation allows caching in a centralized location. Finally, server generation allows caching in a centralized location.
Using server-generated previews allows global generation once per Using server-generated previews allows global generation once per
message, and that preview can be cached for the retention period of message, and that preview can be cached for the retention period of
the source message. Retrieval of message data may be expensive the source message. Retrieval of message data may be expensive
within a server, for example, so a server can be configured to reduce within a server, for example, so a server can be configured to reduce
its storage retrieval load by pre-generating preview data. its storage retrieval load by pre-generating preview data.
A server indicates support for this extension via the "PREVIEW" A server indicates support for this extension via the "PREVIEW"
capability name. capability name.
2. Conventions Used In This Document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
"User" is used to refer to a human user, whereas "client" refers to "User" is used to refer to a human user, whereas "client" refers to
the software being run by the user. the software being run by the user.
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. If a single "C:" or "S:" label applies to server, respectively. If a single "C:" or "S:" label applies to
multiple lines, then the line breaks between those lines are for multiple lines, then the line breaks between those lines are for
editorial clarity only and are not part of the actual protocol editorial clarity only and are not part of the actual protocol
exchange. exchange.
As with all IMAP extension documents, the case used in writing IMAP As with all IMAP extension documents, the case used in writing IMAP
protocol elements herein is chosen for editorial clarity, and protocol elements herein is chosen for editorial clarity, and
implementations must pay attention to the numbered rules at the implementations must pay attention to the numbered rules at the
beginning of [RFC3501] Section 9. beginning of Section 9 of [RFC3501].
3. FETCH Data Item 3. FETCH Data Item
3.1. Command 3.1. Command
To retrieve a preview for a message, the "PREVIEW" FETCH attribute is To retrieve a preview for a message, the PREVIEW FETCH attribute is
used when issuing a FETCH command. used when issuing a FETCH command.
3.2. Response 3.2. Response
The server returns a variable-length string that is the generated The server returns a variable-length string that is the generated
preview for that message. This string is intended to be viewed by preview for that message. This string is intended to be viewed by
the user as a contextual preview of the entire message, and is not the user as a contextual preview of the entire message and is not
intended to be interpreted in any way by the client software. intended to be interpreted in any way by the client software.
Example: Retrieving preview information in a SELECTed mailbox Example: Retrieving preview information in a SELECTed mailbox.
C: A1 FETCH 1 (PREVIEW) C: A1 FETCH 1 (PREVIEW)
S: * 1 FETCH (PREVIEW "Preview text!") S: * 1 FETCH (PREVIEW "Preview text!")
S: A1 OK FETCH complete. S: A1 OK FETCH complete.
A server SHOULD strive to generate the same string for a given A server SHOULD strive to generate the same string for a given
message for each request. However, since previews are understood to message for each request. However, since previews are understood to
be an approximation of the message data and not a canonical view of be an approximation of the message data and not a canonical view of
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 the server has determined that no meaningful It is possible that the server has determined that no meaningful
preview text can be generated for a particular message. Examples of preview text can be generated for a particular message. Examples of
this involve encrypted messages, content types the server does not this involve encrypted messages, content types the server does not
support previews of, and other situations where the server is not support previews of, and other situations where the server is not
able to extract information for a preview. In such cases, the server able to extract information for a preview. In such cases, the server
MUST return a zero-length string. Clients SHOULD NOT send another MUST return a zero-length string. Clients SHOULD NOT send another
FETCH for a preview for such messages. (As discussed previously, FETCH for a preview for such messages. (As discussed previously,
preview data is not immutable so there is chance that at some point 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. 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 However, this scenario is expected to be rare, so a client should not
continually send out requests to try to capture this infrequent continually send out requests to try to detect this infrequent
occurrence.) occurrence.)
If the LAZY modifier is used, the server MAY return NIL for the If the LAZY modifier (Section 4.1) is used, the server MAY return NIL
preview response, indicating that preview generation could not be for the preview response, indicating that preview generation could
completed without causing undue delay. A server MUST NOT return NIL not be completed without causing undue delay. A server MUST NOT
to a FETCH PREVIEW request made without the LAZY modifier. return NIL to a FETCH PREVIEW request made without the LAZY modifier.
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.
For purposes of this section, a "preview character" is defined as a For purposes of this section, a "preview character" is defined as a
single UCS character encoded in UTF-8. Note: a single preview single Universal Character Set (UCS) character encoded in UTF-8.
character may compromise multiple octets, so any buffers implemented Note: a single preview character may comprise multiple octets, so any
to conform to the string limitations identified in this document buffers implemented to conform to the string limitations identified
should be sized to prevent possible overflow errors. in this document should be sized to prevent possible overflow errors.
The server SHOULD limit the length of the preview text to 200 preview The server SHOULD limit the length of the preview text to 200 preview
characters. This length should provide sufficient data to generally characters. This length should provide sufficient data to generally
support both various languages (and their different average word support both various languages (and their different average word
lengths) and diverse client display size requirements. lengths) and diverse client display size requirements.
The server MUST NOT output preview text longer than 256 preview The server MUST NOT output preview text longer than 256 preview
characters. characters.
If the preview is not generated based on the body content of the If the preview is not generated based on the body content of the
message, and the LANGUAGE [RFC5255] extension is supported by the message, and the LANGUAGE extension [RFC5255] is supported by the
server, the preview text SHOULD be generated according to the server, the preview text SHOULD be generated according to the
language rules that apply to human-readable text. For example, a language rules that apply to human-readable text. For example, a
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-readable text server; it should thus use the rules defined for human-readable text
described in the LANGUAGE extension (if supported on the server). described in the LANGUAGE extension (if supported on the server).
4. LAZY Priority Modifier 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.
skipping to change at page 6, line 16 skipping to change at line 242
data without undue delay, the server MUST return NIL as the preview data without undue delay, the server MUST return NIL as the preview
response. response.
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.
4.2. Client Implementation Advice 4.2. Client Implementation Advice
Upon opening a mailbox, a client generally performs a FETCH of Upon opening a mailbox, a client generally performs a FETCH of
message details in order to create a listing to present to the user 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 (e.g., ENVELOPE data). Using this extension, a client may want to
additionally display preview information as part of this listing. additionally display preview information as part of this listing.
Quickly providing the base mailbox listing, with basic message Quickly providing the base mailbox listing with basic message details
details, is the primary goal of this command as this is required to is the primary goal of this command as this is required to allow the
allow the user to begin interacting with the mailbox. Preview data user to begin interacting with the mailbox. Preview data is likely
is likely to be of secondary importance; it provides useful context, to be of secondary importance; it provides useful context, but it is
but it is not necessary to perform message actions. A client can not necessary to perform message actions. A client can load
load unavailable previews in the background and display them unavailable previews in the background and display them
asynchronously to the user as the preview data is provided by the asynchronously to the user as the preview data is provided by the
server. server.
In this scenario, the client would add the PREVIEW data item, with 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 the LAZY modifier, to the list of FETCH items needed to generate the
mailbox listing. This allows the server to advantageously return mailbox listing. This allows the server to advantageously return
preview data without blocking the primary goal of quickly returning preview data without blocking the primary goal of quickly returning
the basic message details used to generate the mailbox listing. the basic message details used to generate the mailbox listing.
Once this initial FETCH is complete, the client can then issue FETCH Once this initial FETCH is complete, the client can then issue FETCH
requests, without the LAZY modifier, to load the PREVIEW data item requests, without the LAZY modifier, to load the PREVIEW data item
for the messages in which preview data was not returned. It is for the messages in which preview data was not returned. It is
RECOMMENDED that these FETCH requests be issued in small batches, RECOMMENDED that these FETCH requests be issued in small batches,
e.g., 50 messages per FETCH command, since preview generation may be e.g., 50 messages per FETCH command, since preview generation may be
expensive and a single large request may exceed server resource expensive and a single large request may exceed server resource
limits. limits.
See Example 2 for an implementation of this strategy. See Example 2 in Section 5 for an implementation of this strategy.
A client SHOULD NOT continually issue LAZY PREVIEW FETCH commands in A client SHOULD NOT continually issue FETCH PREVIEW requests with the
a selected mailbox as the server is under no requirement to return LAZY modifier in a selected mailbox as the server is under no
preview information for this command, which could lead to an requirement to return preview information for this command, which
unnecessary waste of system and network resources. could lead to an unnecessary waste of system and network resources.
5. Examples 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:4 (ENVELOPE PREVIEW (LAZY)) C: B1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY))
S: * 1 FETCH (ENVELOPE ("Wed, 23 Sep 2020 15:03:11 +0000" [...]) S: * 1 FETCH (ENVELOPE ("Wed, 23 Sep 2020 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, 24 Sep 2020 12:17:23 +0000" [...])) ("Thu, 24 Sep 2020 12:17:23 +0000" [...]))
S: * 3 FETCH (ENVELOPE ("Fri, 25 Sep 2020 09:13:45 +0000" [...]) S: * 3 FETCH (ENVELOPE ("Fri, 25 Sep 2020 09:13:45 +0000" [...])
PREVIEW NIL) PREVIEW NIL)
S: * 4 FETCH (ENVELOPE ("Sat, 26 Sep 2020 07:11:18 +0000" [...]) S: * 4 FETCH (ENVELOPE ("Sat, 26 Sep 2020 07:11:18 +0000" [...])
PREVIEW NIL) PREVIEW NIL)
S: D1 OK FETCH completed. S: B1 OK FETCH completed.
[...Client has preview for message 1 and knows that message 2 has [...Client has preview for message 1 and knows that message 2 has
a preview that is empty; only need to request preview of a preview that is empty; only need to request preview of
messages 3 & 4 (e.g. in background)...] messages 3 & 4 (e.g., in background)...]
C: D2 FETCH 3:4 (PREVIEW) C: B2 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: * 4 FETCH (PREVIEW "Message 4 preview")
S: D2 OK Fetch completed. S: B2 OK Fetch completed.
Example 3: Retrieve preview information for search results within a Example 3: Requesting preview for search results within a single
single mailbox. Use SEARCHRES [RFC5182] extension to save a round- mailbox. Use the SEARCHRES extension [RFC5182] to save a round-trip.
trip.
C: E1 CAPABILITY C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES S: * CAPABILITY IMAP4rev1 PREVIEW SEARCHRES
S: E1 OK Capability command completed. S: C1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
C: E2 SEARCH RETURN (SAVE) FROM "FOO" C: C2 SEARCH RETURN (SAVE) FROM "FOO"
C: E3 FETCH $ (UID PREVIEW (LAZY)) C: C3 FETCH $ (UID PREVIEW (LAZY))
S: E2 OK SEARCH completed. S: C2 OK SEARCH completed.
S: * 5 FETCH (UID 13 PREVIEW "Preview!") S: * 5 FETCH (UID 13 PREVIEW "Preview!")
S: * 9 FETCH (UID 23 PREVIEW NIL) S: * 9 FETCH (UID 23 PREVIEW NIL)
S: E3 OK FETCH completed. S: C3 OK FETCH completed.
[...Retrieve message 9 preview in background...] [...Retrieve message 9 preview in background...]
C: E4 UID FETCH 23 (PREVIEW) C: C4 UID FETCH 23 (PREVIEW)
S: * 9 FETCH (UID 23 PREVIEW "Another preview!") S: * 9 FETCH (UID 23 PREVIEW "Another preview!")
S: E4 OK FETCH completed. S: C4 OK FETCH completed.
6. Formal Syntax 6. Formal Syntax
The following syntax specification uses the augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (BNF) as described in ABNF [RFC5234]. It includes definitions Form (ABNF) as described in [RFC5234]. It includes definitions from
from IMAP [RFC3501]. IMAP [RFC3501].
capability =/ "PREVIEW" capability =/ "PREVIEW"
fetch-att =/ "PREVIEW" [SP "(" preview-mod *(SP fetch-att =/ "PREVIEW" [SP "(" preview-mod *(SP
preview-mod) ")"] preview-mod) ")"]
msg-att-dynamic =/ "PREVIEW" SP nstring msg-att-dynamic =/ "PREVIEW" SP nstring
preview-mod = "LAZY" preview-mod = "LAZY"
7. IANA Considerations 7. IANA Considerations
IMAP4 [RFC3501] capabilities are registered by publishing a standards IMAP [RFC3501] capabilities are registered by publishing a Standards
track or IESG-approved experimental RFC. The registry is currently Track or IESG-approved Experimental RFC in the "IMAP Capabilities"
located at: registry located at <http://www.iana.org/assignments/imap-
capabilities>.
http://www.iana.org/assignments/imap-capabilities
This document requests that IANA adds the "PREVIEW" capability to the IANA has added the "PREVIEW" capability to this registry.
IMAP4 [RFC3501] capabilities registry.
8. Security Considerations 8. Security Considerations
Implementation of this extension might enable denial-of-service Implementation of this extension might enable denial-of-service
attacks against server resources, due to excessive memory or CPU attacks against server resources, due to excessive memory or CPU
usage during preview generation or increased storage usage if preview usage during preview generation or increased storage usage if preview
results are stored on the server after generation. In order to results are stored on the server after generation. In order to
mitigate such attacks, servers SHOULD log the client authentication mitigate such attacks, servers SHOULD log the client authentication
identity on FETCH PREVIEW operations in order to facilitate tracking identity on FETCH PREVIEW operations in order to facilitate tracking
of abusive clients. of abusive clients.
Servers MAY limit the resources that preview generation uses. Such Servers MAY limit the resources that preview generation uses. Such
resource limitations might, in an extreme example, cause a server to resource limitations might, in an extreme example, cause a server to
return a preview that is the empty string for a message that return a preview that is the empty string for a message that
otherwise would have had a non-empty preview. However, it is otherwise would have had a non-empty preview. However, it is
recommended that at least some preview text be provided in this recommended that at least some preview text be provided in this
situation, even if the quality of the preview is degraded. situation, even if the quality of the preview is degraded.
Just as the messages they summarize, preview data may contain Just as the messages they summarize, preview data may contain
sensitive information. If generated preview data is stored on the sensitive information. If generated preview data is stored on the
server, e.g. for caching purposes, these previews MUST be protected server, e.g., for caching purposes, these previews MUST be protected
with equivalent authorization and confidentiality controls as the with equivalent authorization and confidentiality controls as the
source message. source message.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
skipping to change at page 10, line 34 skipping to change at line 431
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, DOI 10.17487/RFC2854, June 2000, Type", RFC 2854, DOI 10.17487/RFC2854, June 2000,
<https://www.rfc-editor.org/info/rfc2854>. <https://www.rfc-editor.org/info/rfc2854>.
[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last [RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last
SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
2008, <https://www.rfc-editor.org/info/rfc5182>. 2008, <https://www.rfc-editor.org/info/rfc5182>.
Appendix A. Change History (To be removed by RFC Editor before
publication)
Changes from draft-slusarz-imap-fetch-snippet-00:
o Added standardized language to Section 2 regarding IMAP ABNF
conventions
o Changed draft name to draft-ietf-extra-imap-fetch-snippet-##
Changes from draft-ietf-extra-imap-fetch-snippet-00:
o Changed nomenclature from "snippet" to "preview"
o Changed draft name to draft-ietf-extra-imap-fetch-preview-##
o Update to RFC 8174 boilerplate
o Updated length requirements for PREVIEW=FUZZY
o Added preview-atom ABNF to limit use of "=" character
o UTF-8 is a normative reference
o Clarify that characters for purpose of length limitations are
defined as UCS characters as encoded by UTF-8
o Fix some incorrect literal lengths in examples
Changes from draft-ietf-extra-imap-fetch-preview-00:
o Updated postal address
o Added example to FETCH response section
o Added example on how LANGUAGE extension may influence preview
generation
o Added recommendation that only one LAZY FETCH be executed for a
message per mailbox
o Added request to create algorithm and modifier registries
o Added requirement that algorithm and modifier names conform to RFC
6648
o Added DoS attack info to security considerations
o Distinguish between NIL response and zero-length string
o Don't use deprecated "X-" convention in example
o Spelling and nits
Changes from draft-ietf-extra-imap-fetch-preview-01:
o Fix capability ABNF
o Removed CAPABILITY string for examples where it did not add
valuable context
o Altered preview data in examples to cover a variety of potential
server return scenarios
o Added "SHOULD be registered" language to algorithm names and
priority modifiers
Changes from draft-ietf-extra-imap-fetch-preview-02:
o Move Acknowledgments to un-numbered appendix
o Improved abstract text
o Consistently use "priority modifiers" instead of "modifiers"
o Update example to conform with RFC 3501 UID FETCH requirements
Changes from draft-ietf-extra-imap-fetch-preview-03:
o Remove preview modifier registry request
o Improve instructions for registration of algorithms
o Add storage information to security considerations
o Clarify parsing of algorithm list in FETCH command
o Clarify difference between NIL response and zero-length string
o Add normative reference for text/plain
o Add warning regarding buffers and multiple octet preview
characters
o Clarify how to handle preview data return when using an explicit
algorithm list
o Various editorial fixes
Changes from draft-ietf-extra-imap-fetch-preview-04:
o Make clear that preview caching is tied to retention period of the
source message
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
Changes from draft-ietf-extra-imap-fetch-preview-07:
o Remove algorithm selection; PREVIEW always returns text in format
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
Changes from draft-ietf-extra-imap-fetch-preview-09:
o Clarified that string response is to be interpreted by user, not
the client
o Give example behavior of resource limitation
o Various editorial fixes
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 United States of America
Email: michael.slusarz@open-xchange.com Email: michael.slusarz@open-xchange.com
 End of changes. 45 change blocks. 
254 lines changed or deleted 99 lines changed or added

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