draft-ietf-extra-imap-fetch-preview-09.txt		draft-ietf-extra-imap-fetch-preview-10.txt
	EXTRA M. Slusarz		EXTRA M. Slusarz
	Internet-Draft Open-Xchange Inc.		Internet-Draft Open-Xchange Inc.
	Intended status: Standards Track July 29, 2020		Intended status: Standards Track September 30, 2020
	Expires: January 30, 2021		Expires: April 3, 2021
	IMAP4 Extension: Message Preview Generation		IMAP4 Extension: Message Preview Generation
	draft-ietf-extra-imap-fetch-preview-09		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 allowing a client to request a server-generated
	abbreviated text representation of message data useful as a		abbreviated text representation of message data useful as a
	contextual preview of the entire message.		contextual preview of the entire message.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 33 ¶		skipping to change at page 1, line 33 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on January 30, 2021.		This Internet-Draft will expire on April 3, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 20 ¶		skipping to change at page 3, line 20 ¶
	will likely strip the markup tags to obtain textual content.		will likely strip the markup tags to obtain textual content.
	However, without fetching the entire content of the part, there is no		However, without fetching the entire content of the part, there is no
	way to guarantee that sufficient non-tag content will exist unless		way to guarantee that sufficient non-tag content will exist unless
	either 1) the entire part is retrieved or 2) an additional partial		either 1) the entire part is retrieved or 2) an additional partial
	FETCH is executed when the client determines that it does not possess		FETCH is executed when the client determines that it does not possess
	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 that preview can be cached for the retention period of
	message. Retrieval of message data may be expensive within a server,		the source message. Retrieval of message data may be expensive
	for example, so a server can be configured to reduce its storage		within a server, for example, so a server can be configured to reduce
	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 BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	skipping to change at page 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	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.		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
			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
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 39 ¶
	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, and that		preview text can be generated for a particular message. Examples of
	decision won't change later. Examples of this involve encrypted		this involve encrypted messages, content types the server does not
	messages, content types the server does not support previews of, and		support previews of, and other situations where the server is not
	other situations where the server is not able to extract information		able to extract information for a preview. In such cases, the server
	for a preview. In such cases, the server MUST return a zero-length		MUST return a zero-length string. Clients SHOULD NOT send another
	string. Clients SHOULD NOT send another FETCH for a preview for such		FETCH for a preview for such messages. (As discussed previously,
	messages. (As discussed previously, preview data is not immutable so		preview data is not immutable so there is chance that at some point
	there is chance that at some point in the future the server would be		in the future the server would be able to generate meaningful text.
	able to generate meaningful text. However, this scenario is expected		However, this scenario is expected to be rare so a client should not
	to be rare so a client should not continually send out requests to		continually send out requests to try to capture this infrequent
	try to capture this infrequent occurrence.)		occurrence.)
	If the LAZY modifier is used, the server MAY return NIL for the		If the LAZY modifier is used, the server MAY return NIL for the
	preview response, indicating that preview generation could not be		preview response, indicating that preview generation could not be
	completed without causing undue delay. A server MUST NOT return NIL		completed without causing undue delay. A server MUST NOT return NIL
	to a FETCH PREVIEW request made without the LAZY modifier.		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.
	skipping to change at page 5, line 39 ¶		skipping to change at page 5, line 41 ¶
	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 [RFC5255] extension 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-generated		server, and should thus use the rules defined for human-readable text
	text described in the LANGUAGE extension (if supported on the		described in the LANGUAGE extension (if supported on the server).
	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.
	If this modifier is used, and the server is unable to return preview		If this modifier is used, and the server is unable to return preview
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	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
	additional 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, is the primary goal of this command as this is required to		details, is the primary goal of this command as this is required to
	allow the user to begin interacting with the mailbox. Preview data		allow the user to begin interacting with the mailbox. Preview data
	is likely to be of secondary importance; it provides useful context,		is likely to be of secondary importance; it provides useful context,
	but it is not necessary to perform message actions. A client can		but it is not necessary to perform message actions. A client can
	load unavailable previews in the background and display them		load 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 for the		requests, without the LAZY modifier, to load the PREVIEW data item
	messages in which preview data was not returned. It is RECOMMENDED		for the messages in which preview data was not returned. It is
	that these FETCH requests be issued in small batches, e.g. 50		RECOMMENDED that these FETCH requests be issued in small batches,
	messages per FETCH command, since preview generation may be expensive		e.g., 50 messages per FETCH command, since preview generation may be
	and a single large request may exceed server resource limits.		expensive and a single large request may exceed server resource
			limits.
	See Example 2 for an implementation of this strategy.		See Example 2 for an implementation of this strategy.
	A client SHOULD NOT continually issue LAZY PREVIEW FETCH commands in		A client SHOULD NOT continually issue LAZY PREVIEW FETCH commands in
	a selected mailbox as the server is under no requirement to return		a selected mailbox as the server is under no requirement to return
	preview information for this command, which could lead to an		preview information for this command, which could lead to an
	unnecessary waste of system and network resources.		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.
	skipping to change at page 7, line 24 ¶		skipping to change at page 7, line 24 ¶
	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: D1 FETCH 1:4 (ENVELOPE PREVIEW (LAZY))
	S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 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, 26 Oct 2017 12:17:23 +0000" [...]))		("Thu, 24 Sep 2020 12:17:23 +0000" [...]))
	S: * 3 FETCH (ENVELOPE ("Fri, 27 Oct 2017 22:19:21 +0000" [...])		S: * 3 FETCH (ENVELOPE ("Fri, 25 Sep 2020 09:13:45 +0000" [...])
	PREVIEW NIL)		PREVIEW NIL)
	S: * 4 FETCH (ENVELOPE ("Sat, 28 Oct 2017 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: D1 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: D2 FETCH 3:4 (PREVIEW)
	S: * 3 FETCH (PREVIEW {30}		S: * 3 FETCH (PREVIEW {30}
	S: Message data from message 3.		S: Message data from message 3.
	S: )		S: )
	S: * 4 FETCH (PREVIEW "Message 4 preview")		S: * 4 FETCH (PREVIEW "Message 4 preview")
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	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.
	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. Servers MAY limit		results are stored on the server after generation. In order to
	the resources that preview generation uses. In order to mitigate		mitigate such attacks, servers SHOULD log the client authentication
	such attacks, servers SHOULD log the client authentication identity		identity on FETCH PREVIEW operations in order to facilitate tracking
	on FETCH PREVIEW operations in order to facilitate tracking of		of abusive clients.
	abusive clients.
			Servers MAY limit the resources that preview generation uses. Such
			resource limitations might, in an extreme example, cause a server to
			return a preview that is the empty string for a message that
			otherwise would have had a non-empty preview. However, it is
			recommended that at least some preview text be provided in this
			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
	skipping to change at page 13, line 19 ¶		skipping to change at page 13, line 26 ¶
	o Remove algorithm selection; PREVIEW always returns text in format		o Remove algorithm selection; PREVIEW always returns text in format
	defined in Section 3.3		defined in Section 3.3
	Changes from draft-ietf-extra-imap-fetch-preview-08:		Changes from draft-ietf-extra-imap-fetch-preview-08:
	o FETCH PREVIEW without LAZY modifier MUST NOT return NIL		o FETCH PREVIEW without LAZY modifier MUST NOT return NIL
	o Improve client implementation advice for LAZY modifier		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
End of changes. 14 change blocks.
	38 lines changed or deleted		55 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/