Diff: draft-ietf-extra-imap-fetch-preview-06.txt - draft-ietf-extra-imap-fetch-preview-07.txt

	< draft-ietf-extra-imap-fetch-preview-06.txt	draft-ietf-extra-imap-fetch-preview-07.txt >

	EXTRA M. Slusarz	EXTRA M. Slusarz
	Internet-Draft Open-Xchange Inc.	Internet-Draft Open-Xchange Inc.

	Intended status: Standards Track July 1, 2019	Intended status: Standards Track December 10, 2019
	Expires: January 2, 2020	Expires: June 12, 2020

	IMAP4 Extension: Message Preview Generation	IMAP4 Extension: Message Preview Generation

	draft-ietf-extra-imap-fetch-preview-06	draft-ietf-extra-imap-fetch-preview-07

	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 representation of message data useful as a contextual
	preview of the entire message.	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, 2020.	This Internet-Draft will expire on June 12, 2020.

	Copyright Notice	Copyright Notice

	Copyright (c) 2019 IETF Trust and the persons identified as the	Copyright (c) 2019 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

	skipping to change at page 2, line 13 ¶	skipping to change at page 2, line 13 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4	3.1. Command . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4	3.2. Response . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. PREVIEW Algorithms . . . . . . . . . . . . . . . . . . . . . 5	4. PREVIEW Algorithms . . . . . . . . . . . . . . . . . . . . . 5

	4.1. FUZZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5	4.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5
	5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 6	4.2. text/imap-fetch-preview . . . . . . . . . . . . . . . . . 6
	5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 6	5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 7
		5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7	6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9	7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10	9. Security Considerations . . . . . . . . . . . . . . . . . . . 10

	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 10	10.1. Normative References . . . . . . . . . . . . . . . . . . 11
	10.2. Informative 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) . . . . . . . . . . . . . . . . . . . . 12

	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14	Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15

	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 previews of
	messages.	messages.


	skipping to change at page 3, line 25 ¶	skipping to change at page 3, line 25 ¶
	sufficient data from a previous partial FETCH to display an adequate	sufficient data from a previous partial FETCH to display an adequate
	representation of the preview.	representation of the preview.

	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 then cached for the retention period of the source	message, and then cached for the retention period of the source
	message. Retrieval of message data may be expensive within a server,	message. Retrieval of message data may be expensive within a server,
	for example, so a server can be configured to reduce its storage	for example, so a server can be configured to reduce its storage
	retrieval load by pre-generating preview data.	retrieval load by pre-generating preview data.


	A server indicates support for this extension by listing one or more	A server indicates support for this extension via the "PREVIEW"
	capability names consisting of "PREVIEW=" followed by a supported	capability name.
	preview algorithm name. This format provides for future upwards-
	compatible extensions and/or the ability to use locally-defined
	preview algorithms.

	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 BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all	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

	skipping to change at page 4, line 12 ¶	skipping to change at page 4, line 12 ¶
	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 decides which of its	If no algorithm list is provided, the server MUST return data using
	built-in algorithms to use to generate the preview text.	the text/imap-fetch-preview algorithm.

	The client may explicitly indicate which algorithm(s) should be used	The client may explicitly indicate which algorithm(s) should be used
	to generate the preview list via a parenthesized list of algorithm	to generate the preview list via a parenthesized list of algorithm
	names output after the PREVIEW attribute. Unsupported algorithms in	names output after the PREVIEW attribute. Unsupported algorithms in
	the list MUST be ignored. If the list contains no supported	the list MUST be ignored. If the list contains no supported
	algorithms, the server MUST return a tagged BAD response to the FETCH	algorithms, the server MUST return a tagged BAD response to the FETCH
	command.	command.

	The order of the algorithms in the parenthesized list (from left to	The order of the algorithms in the parenthesized list (from left to
	right) defines the client's priority decision. Duplicate algorithms	right) defines the client's priority decision. Duplicate algorithms

	skipping to change at page 4, line 45 ¶	skipping to change at page 4, line 45 ¶

	The algorithm used by the server to generate the preview is returned	The algorithm used by the server to generate the preview is returned
	preceding the preview string.	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 (FUZZY "Preview text!"))	S: * 1 FETCH (PREVIEW (text/imap-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 a representation 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.

	skipping to change at page 5, line 33 ¶	skipping to change at page 5, line 33 ¶
	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.

	4. PREVIEW Algorithms	4. PREVIEW Algorithms


	4.1. FUZZY	4.1. Description


	The FUZZY algorithm directs the server to use any internal algorithm	Algorithms MUST be named in media type [RFC6838] format.
	it desires, subject to the below limitations, to generate a textual
	preview for a message.


	The FUZZY algorithm MUST be implemented by any server that supports	This document defines an extension specific algorithm, text/imap-
	the PREVIEW extension.	fetch-preview, that outlines precise semantics regarding the
		generated preview data. Future documents may define additional
		PREVIEW specific algorithms.


	The preview text MUST be treated as text/plain [RFC2046] media type	In the absence of a PREVIEW specific algorithm definition, preview
	data by the client.	generation semantics are server-dependent. If a server supports an
		algorithm it MUST return preview data in the media type format
		requested by the client. A client MUST NOT assume that a server
		supports a preview algorithm not specifically defined in this
		document.

		4.2. text/imap-fetch-preview

		The text/imap-fetch-preview algorithm directs the server to use any
		internal algorithm it desires, subject to the below limitations, to
		generate a textual preview for a message.

		The text/imap-fetch-preview algorithm MUST be implemented by any
		server that supports the PREVIEW extension.

		The generated preview text MUST be treated as text/plain [RFC2046]
		media type data by the client.

	The generated string MUST NOT be content transfer encoded and MUST be	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 what other 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 different 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 FUZZY algorithm generates a preview that is not based on the
	body content of the message and the LANGUAGE [RFC5255] extension is	body content of the message and the LANGUAGE [RFC5255] extension is
	supported by the server, the preview text SHOULD be generated	supported by the server, the preview text SHOULD be generated
	according to the language rules that apply to human-readable text.	according to the language rules that apply to human-readable text.
	For example, a message that consists of a single image MIME part has	For example, a message that consists of a single image MIME part has
	no human-readable text from which to generate preview information.	no human-readable text from which to generate preview information.

	skipping to change at page 6, line 38 ¶	skipping to change at page 7, line 13 ¶
	the server).	the server).

	5. PREVIEW Priority Modifiers	5. PREVIEW Priority Modifiers

	5.1. LAZY	5.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

	skipping to change at page 7, line 21 ¶	skipping to change at page 8, line 4 ¶
	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 4 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	6. Examples


	Example 1: Requesting FETCH without explicit algorithm selection.	Example 1: Requesting FETCH without explicit algorithm selection.

	C: A1 CAPABILITY	C: A1 CAPABILITY

	S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY	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 (FUZZY {200}	S: * 1 FETCH (RFC822.SIZE 5647 PREVIEW
		(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 FETCH with explicit algorithm selection.


	C: B1 FETCH 1 (RFC822.SIZE PREVIEW (FUZZY))	C: B1 FETCH 1 (RFC822.SIZE PREVIEW (text/imap-fetch-preview))
	S: * 1 FETCH (RFC822.SIZE 91377 PREVIEW (FUZZY {53}	S: * 1 FETCH (RFC822.SIZE 91377 PREVIEW
		(text/imap-fetch-preview {53}
	S: Preview text generated from message body text data.	S: Preview text generated from message body text data.
	S: ))	S: ))
	S: B1 OK FETCH complete.	S: B1 OK FETCH complete.


	Example 3: Requesting FETCH with invalid explicit algorithm	Example 3: Requesting FETCH with unknown explicit algorithm
	selection.	selection.

	C: C1 CAPABILITY	C: C1 CAPABILITY

	S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY	S: * CAPABILITY IMAP4rev1 PREVIEW
	S: C1 OK Capability command completed.	S: C1 OK Capability command completed.
	[...a mailbox is SELECTed...]	[...a mailbox is SELECTed...]

	C: C2 FETCH 1 (RFC822.SIZE PREVIEW (UNKNOWN-PREVIEW-ALGO))	C: C2 FETCH 1 (RFC822.SIZE PREVIEW (example/unknown))
	S: C2 BAD FETCH contains invalid preview algorithm name.	S: C2 BAD FETCH contains unknown preview algorithm name.

	Example 4: Use explicit algorithm priority selection, with LAZY	Example 4: Use explicit algorithm priority selection, with LAZY
	modifier, to obtain previews during initial mailbox listing if	modifier, to obtain previews during initial mailbox listing if
	readily available; otherwise, load previews in background.	readily available; otherwise, load previews in background.


	C: D1 FETCH 1:3 (ENVELOPE PREVIEW (LAZY=FUZZY))	C: D1 FETCH 1:3 (ENVELOPE PREVIEW (LAZY))
	S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...])	S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...])

	PREVIEW (FUZZY "Preview text for message 1."))	PREVIEW (text/imap-fetch-preview "Preview text for message 1."))
	S: * 2 FETCH (PREVIEW (FUZZY "") ENVELOPE	S: * 2 FETCH (PREVIEW (text/imap-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 (FUZZY NIL))	PREVIEW (text/imap-fetch-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 (FUZZY))	C: D2 FETCH 3 (PREVIEW (text/imap-fetch-preview))
	S: * 3 FETCH (PREVIEW (FUZZY {30}	S: * 3 FETCH (PREVIEW (text/imap-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 5: 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=FUZZY 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=FUZZY))	C: E3 FETCH $ (UID PREVIEW (LAZY=text/imap-fetch-preview))
	S: E2 OK SEARCH completed.	S: E2 OK SEARCH completed.

	S: * 5 FETCH (UID 13 PREVIEW (FUZZY "Preview!"))	S: * 5 FETCH (UID 13 PREVIEW (text/imap-fetch-preview "Preview!"))
	S: * 9 FETCH (UID 23 PREVIEW (FUZZY NIL))	S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-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 (FUZZY))	C: E4 UID FETCH 23 (PREVIEW (text/imap-fetch-preview))
	S: * 9 FETCH (UID 23 PREVIEW (FUZZY "Another preview!"))	S: * 9 FETCH (UID 23 PREVIEW (text/imap-fetch-preview
		"Another preview!"))
	S: E4 OK FETCH completed.	S: E4 OK FETCH completed.

	7. Formal Syntax	7. 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=" preview-alg	capability =/ "PREVIEW"

	fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP	fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP
	preview-alg-fetch) ")"]	preview-alg-fetch) ")"]

	msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")"	msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")"


	preview-alg = "FUZZY" / preview-alg-ext	preview-alg = "text/imap-fetch-preview" / preview-alg-ext

	preview-alg-ext = preview-atom ; New algorithm names SHOULD be	preview-alg-ext = preview-atom ; New algorithm names SHOULD be
	; registered with IANA and MUST	; registered with IANA and MUST

	; conform with the	; conform with the media type
	; recommendations described in	; format described in [RFC6838]
	; [RFC6648], Section 3


	preview-alg-fetch = preview-alg / preview-mod "=" preview-alg	preview-alg-fetch = preview-alg / preview-mod ["=" preview-alg]

	preview-atom = 1*<any ATOM-CHAR except "=">	preview-atom = 1*<any ATOM-CHAR except "=">

	preview-mod = "LAZY"	preview-mod = "LAZY"

	8. IANA Considerations	8. 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	This document requests that IANA adds the "PREVIEW" capability to the
	the IMAP4 [RFC3501] capabilities registry.	IMAP4 [RFC3501] capabilities registry.

	This document requests that IANA create a new "IMAP FETCH PREVIEW	This document requests that IANA create a new "IMAP FETCH PREVIEW
	Algorithms" registry, which registers preview algorithms by IETF	Algorithms" registry, which registers preview algorithms by IETF
	Review [RFC8126]. An assignment consists of the algorithm name (as	Review [RFC8126]. An assignment consists of the algorithm name (as
	defined by the preview-alg-ext ABNF entry) and the document that	defined by the preview-alg-ext ABNF entry) and the document that
	defines the algorithm. This document constitutes registration of the	defines the algorithm. This document constitutes registration of the

	FUZZY algorithm in that registry.	text/imap-fetch-preview algorithm in that registry.

	9. Security Considerations	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

	skipping to change at page 11, line 23 ¶	skipping to change at page 11, line 43 ¶
	[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>.


	[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,	[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
	"Deprecating the "X-" Prefix and Similar Constructs in	Specifications and Registration Procedures", BCP 13,
	Application Protocols", BCP 178, RFC 6648,	RFC 6838, DOI 10.17487/RFC6838, January 2013,
	DOI 10.17487/RFC6648, June 2012,	<https://www.rfc-editor.org/info/rfc6838>.
	<https://www.rfc-editor.org/info/rfc6648>.

	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,	Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,	RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.	<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>.


	skipping to change at page 14, line 22 ¶	skipping to change at page 14, line 41 ¶
	Changes from draft-ietf-extra-imap-fetch-preview-05:	Changes from draft-ietf-extra-imap-fetch-preview-05:

	o Clarify "zero-length string" preview data vs. NIL preview data	o Clarify "zero-length string" preview data vs. NIL preview data

	o MIME data -> media type	o MIME data -> media type

	o Capability registration should not include the algorithm name	o Capability registration should not include the algorithm name

	o Give example of how PREVIEW data might change over time	o Give example of how PREVIEW data might change over time


		Changes from draft-ietf-extra-imap-fetch-preview-06:

		o Change algorithm names to media types

		o FUZZY algorithm changed to text/imap-fetch-preview

		o Remove server broadcast of PREVIEW algorithm extensions from
		capability

		o Default, fallback algorithm in absence of client selection now
		MUST be text/imap-fetch-preview

		o LAZY modifier should work on default algorithm if no specific
		algorithm is provided as an argument

	Acknowledgments	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, Steffen Lehmann, Barry Leiba, Alexey	Gondwana, Teemu Huovila, Neil Jenkins, Steffen Lehmann, Barry Leiba,
	Melnikov, Chris Newman, Jeff Sipek, Timo Sirainen, Steffen Templin,	Alexey Melnikov, Chris Newman, Pete Resnick, Jeff Sipek, Timo
	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. 39 change blocks.
	67 lines changed or deleted	101 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/