< draft-ietf-extra-imap-fetch-preview-07.txt   draft-ietf-extra-imap-fetch-preview-08.txt >
EXTRA M. Slusarz EXTRA M. Slusarz
Internet-Draft Open-Xchange Inc. Internet-Draft Open-Xchange Inc.
Intended status: Standards Track December 10, 2019 Intended status: Standards Track July 1, 2020
Expires: June 12, 2020 Expires: January 2, 2021
IMAP4 Extension: Message Preview Generation IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-07 draft-ietf-extra-imap-fetch-preview-08
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 representation of message data useful as a contextual abbreviated text representation of message data useful as a
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 12, 2020. This Internet-Draft will expire on January 2, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 4 3. FETCH Data Item . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4
4. PREVIEW Algorithms . . . . . . . . . . . . . . . . . . . . . 5 3.3. Preview Text Format . . . . . . . . . . . . . . . . . . . 5
4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 4. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 5
4.2. text/imap-fetch-preview . . . . . . . . . . . . . . . . . 6 4.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 7 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 12 publication) . . . . . . . . . . . . . . . . . . . . 9
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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 previews of standardized, consistent way to generate these brief textual previews
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 This standardized display can reduce user confusion when using
multiple clients, as abbreviated message representations in clients multiple clients, as abbreviated message representations in clients
will show identical message contents. will show identical message contents.
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)
skipping to change at page 4, line 6 skipping to change at page 4, line 4
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 [RFC3501] Section 9.
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.
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
in the list SHOULD be ignored. For purposes of duplicate detection,
priority modifiers (Section 5) should be ignored. A server MUST
honor a client's algorithm priority decision.
A server should return preview data for the first algorithm that
returns non-empty preview text. Empty preview text is defined as
either the NIL response or an empty (zero length) string. If no
algorithm produces non-empty preview text, the server should respond
with the preview data generated by the final algorithm in the list.
3.2. Response 3.2. Response
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 The server returns a variable-length string that is the generated
preview for that message. preview for that message.
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 (text/imap-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 a representation 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 for an account due For example, the underlying IMAP server may change due to a system
to a software upgrade; account state information may be retained in software upgrade; an account's state information may be retained in
the migration, but the new server may support a different PREVIEW the migration but the new server may generate different PREVIEW text
generation algorithm. Thus, message state may remain the same but than the old server.
the FETCH PREVIEW response may change, if that data was not part of
the data migration.
It is possible that preview text is not available now, but might be It is possible that preview text is not available now, but might be
available later -- perhaps the server's preview-generating resources available later -- perhaps the server's preview-generating resources
are overloaded, there is a server-imposed timeout during preview are overloaded, there is a server-imposed timeout during preview
generation, or there is some transient issue with fetching the generation, or there is some transient issue with fetching the
message body. In such cases, the server will return NIL as the message body. In such cases, the server will return NIL as the
preview response, and the client can try to retrieve the preview preview response, and the client can try to retrieve the preview
later. later.
On the other hand, it is possible that the server has determined that On the other hand, it is possible that the server has determined that
no meaningful preview text can be generated for a particular message, no meaningful preview text can be generated for a particular message,
and that decision won't change later. Examples of this involve and that decision won't change later. Examples of this involve
encrypted messages, content types the server does not support encrypted messages, content types the server does not support
previews of, and other situations where the server is not able to previews of, and other situations where the server is not able to
extract information for a preview. In such cases, the server will extract information for a preview. In such cases, the server will
return a zero-length string. Clients should not send another FETCH return a zero-length string. Clients SHOULD NOT send another FETCH
for a preview for such messages. for a preview for such messages. (As discussed previously, preview
data is not immutable so there is chance that at some point in the
4. PREVIEW Algorithms future the server would be able to generate meaningful text.
However, this scenario is expected to be rare so a client should not
4.1. Description continually send out requests to try to capture this infrequent
occurrence.
Algorithms MUST be named in media type [RFC6838] format.
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.
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 3.3. Preview Text Format
server that supports the PREVIEW extension.
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 what other 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 UCS character encoded in UTF-8. Note: a single preview
character may compromise multiple octets, so any buffers implemented character may compromise multiple octets, so any buffers implemented
to conform to the string limitations identified in this document to conform to the string limitations identified in this document
should be sized to prevent possible overflow errors. 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 FUZZY algorithm generates a preview that is not based on the If the preview is not generated based on the body content of the
body content of the message and the LANGUAGE [RFC5255] extension is message, and the LANGUAGE [RFC5255] extension is supported by the
supported by the server, the preview text SHOULD be generated server, the preview text SHOULD be generated according to the
according to the language rules that apply to human-readable text. language rules that apply to human-readable text. For example, a
For example, a message that consists of a single image MIME part has message that consists of a single image MIME part has no human-
no human-readable text from which to generate preview information. readable text from which to generate preview information. Instead,
Instead, the server may wish to output a description that the message the server may wish to output a description that the message contains
contains an image and describe some attributes of the image, such as an image and describe some attributes of the image, such as image
image format, size, and filename. This descriptive text is not a format, size, and filename. This descriptive text is not a product
product of the message body itself but is rather auto-generated data of the message body itself but is rather auto-generated data by the
by the server, and should thus use the rules defined for human- server, and should thus use the rules defined for human-generated
generated text described in the LANGUAGE extension (if supported on text described in the LANGUAGE extension (if supported on the
the server). server).
5. PREVIEW Priority Modifiers 4. PREVIEW Priority Modifiers
5.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.
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 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 is nice-to-have, but the server SHOULD NOT block the return of other
FETCH information at the expense of generating the preview data. FETCH information at the expense of generating the preview data.
For example, a client displaying the initial mailbox listing to a For example, a client displaying the initial mailbox listing to a
user may want to display preview information associated with messages user may want to display preview information associated with messages
in that listing. However, this information is secondary to providing in that listing. However, this information is secondary to providing
the mailbox listing, with message details, and the client is willing the mailbox listing, with message details, and the client is willing
to load any unavailable previews in the background and display them to load any unavailable previews in the background and display them
as they are provided by the server. In this case, the client would as they are provided by the server. In this case, the client would
apply the LAZY modifier to the desired algorithm(s) to direct the send the LAZY modifier directing the server to only return pre-
server to only return pre-generated preview data so that retrieval of generated preview data so that retrieval of the other FETCH
the other FETCH information is not blocked by possibly expensive information is not blocked by possibly expensive preview generation.
preview generation.
Generally, the LAZY modifier will only be used once per mailbox load Generally, the LAZY modifier will only be used once per mailbox load
during the initial listing. If preview information is not available during the initial listing. If preview information is not available
during this initial FETCH, the expectation is that a second non-LAZY during this initial FETCH, the expectation is that a second non-LAZY
FETCH will take place after mailbox listing activities are complete. FETCH will take place after mailbox listing activities are complete.
Thus, a maximum of 2 PREVIEW FETCH queries should occur for any Thus, a maximum of 2 PREVIEW FETCH queries should occur for any
message in a selected mailbox. A client SHOULD NOT continually issue message in a selected mailbox. A client SHOULD NOT continually issue
LAZY PREVIEW FETCH commands in a selected mailbox as the server is LAZY PREVIEW FETCH commands in a selected mailbox as the server is
under no requirement to return preview information for this command, under no requirement to return preview information for this command,
which could lead to an unnecessary waste of system and network which could lead to an unnecessary waste of system and network
resources. See Example 4 in the Examples section for how this can be resources. See Example 2 in the Examples section for how this can be
implemented. 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.
6. Examples 5. Examples
Example 1: Requesting FETCH without explicit algorithm selection.
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 S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW {200}
(text/imap-fetch-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 FETCH with explicit algorithm selection. Example 2: Requesting PREVIEW with LAZY modifier, to obtain previews
during initial mailbox listing if readily available; otherwise, load
C: B1 FETCH 1 (RFC822.SIZE PREVIEW (text/imap-fetch-preview)) previews in background.
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 unknown explicit algorithm
selection.
C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW
S: C1 OK Capability command completed.
[...a mailbox is SELECTed...]
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)) C: D1 FETCH 1:3 (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 (text/imap-fetch-preview "Preview text for message 1.")) PREVIEW "Preview text for message 1.")
S: * 2 FETCH (PREVIEW (text/imap-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 (text/imap-fetch-preview NIL)) PREVIEW NIL)
S: D1 OK FETCH completed. S: D1 OK FETCH completed.
[...Client knows that message 2 has a preview that is empty; [...Client knows that message 2 has a preview that is empty;
therefore, client only needs to request message 3 preview again therefore, client only needs to request message 3 preview again
(e.g. in background)...] (e.g. in background)...]
C: D2 FETCH 3 (PREVIEW (text/imap-fetch-preview)) C: D2 FETCH 3 (PREVIEW)
S: * 3 FETCH (PREVIEW (text/imap-fetch-preview {30} S: * 3 FETCH (PREVIEW {30}
S: Message data from message 3. S: Message data from message 3.
S: )) S: )
S: D2 OK Fetch completed. S: D2 OK Fetch completed.
Example 5: 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...]
C: E2 SEARCH RETURN (SAVE) FROM "FOO" C: E2 SEARCH RETURN (SAVE) FROM "FOO"
C: E3 FETCH $ (UID PREVIEW (LAZY=text/imap-fetch-preview)) C: E3 FETCH $ (UID PREVIEW (LAZY))
S: E2 OK SEARCH completed. S: E2 OK SEARCH completed.
S: * 5 FETCH (UID 13 PREVIEW (text/imap-fetch-preview "Preview!")) S: * 5 FETCH (UID 13 PREVIEW "Preview!")
S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview NIL)) S: * 9 FETCH (UID 23 PREVIEW NIL)
S: E3 OK FETCH completed. S: E3 OK FETCH completed.
[...Retrieve message 9 preview in background...] [...Retrieve message 9 preview in background...]
C: E4 UID FETCH 23 (PREVIEW (text/imap-fetch-preview)) C: E4 UID FETCH 23 (PREVIEW)
S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview S: * 9 FETCH (UID 23 PREVIEW "Another preview!")
"Another preview!"))
S: E4 OK FETCH completed. S: E4 OK FETCH completed.
7. 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 (BNF) as described in ABNF [RFC5234]. It includes definitions
from IMAP [RFC3501]. from IMAP [RFC3501].
capability =/ "PREVIEW" capability =/ "PREVIEW"
fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP fetch-att =/ "PREVIEW" [SP "(" preview-mod *(SP
preview-alg-fetch) ")"] preview-mod) ")"]
msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")"
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 media type
; format described in [RFC6838]
preview-alg-fetch = preview-alg / preview-mod ["=" preview-alg]
preview-atom = 1*<any ATOM-CHAR except "="> msg-att-dynamic =/ "PREVIEW" SP nstring
preview-mod = "LAZY" preview-mod = "LAZY"
8. IANA Considerations 7. IANA Considerations
IMAP4 [RFC3501] capabilities are registered by publishing a standards IMAP4 [RFC3501] capabilities are registered by publishing a standards
track or IESG-approved experimental RFC. The registry is currently track or IESG-approved experimental RFC. The registry is currently
located at: 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 This document requests that IANA adds the "PREVIEW" capability to the
IMAP4 [RFC3501] capabilities registry. IMAP4 [RFC3501] capabilities registry.
This document requests that IANA create a new "IMAP FETCH PREVIEW 8. Security Considerations
Algorithms" registry, which registers preview algorithms by IETF
Review [RFC8126]. An assignment consists of the algorithm name (as
defined by the preview-alg-ext ABNF entry) and the document that
defines the algorithm. This document constitutes registration of the
text/imap-fetch-preview algorithm in that registry.
9. 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. Servers MAY limit results are stored on the server after generation. Servers MAY limit
the resources that preview generation uses. In order to mitigate the resources that preview generation uses. In order to mitigate
such attacks, servers SHOULD log the client authentication identity such attacks, servers SHOULD log the client authentication identity
on FETCH PREVIEW operations in order to facilitate tracking of on FETCH PREVIEW operations in order to facilitate tracking of
abusive clients. abusive clients.
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.
10. References 9. References
10.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,
<https://www.rfc-editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 11, line 43 skipping to change at page 9, line 28
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255, Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008, DOI 10.17487/RFC5255, June 2008,
<https://www.rfc-editor.org/info/rfc5255>. <https://www.rfc-editor.org/info/rfc5255>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References 9.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<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>.
skipping to change at page 15, line 8 skipping to change at page 12, line 33
o Remove server broadcast of PREVIEW algorithm extensions from o Remove server broadcast of PREVIEW algorithm extensions from
capability capability
o Default, fallback algorithm in absence of client selection now o Default, fallback algorithm in absence of client selection now
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:
o Remove algorithm selection; PREVIEW always returns text in format
defined in Section 3.3
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. 47 change blocks. 
191 lines changed or deleted 91 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/