< draft-ietf-extra-imap-fetch-preview-04.txt		draft-ietf-extra-imap-fetch-preview-05.txt >
	EXTRA M. Slusarz		EXTRA M. Slusarz
	Internet-Draft Open-Xchange Inc.		Internet-Draft Open-Xchange Inc.
	Intended status: Standards Track April 24, 2019		Intended status: Standards Track April 28, 2019
	Expires: October 26, 2019		Expires: October 30, 2019
	IMAP4 Extension: Message Preview Generation		IMAP4 Extension: Message Preview Generation
	draft-ietf-extra-imap-fetch-preview-04		draft-ietf-extra-imap-fetch-preview-05
	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 October 26, 2019.		This Internet-Draft will expire on October 30, 2019.
	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 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 indefinitely. Retrieval of message data may		message, and then cached for the retention period of the source
	be expensive within a server, for example, so a server can be		message. Retrieval of message data may be expensive within a server,
	configured to reduce its storage retrieval load by pre-generating		for example, so a server can be configured to reduce its storage
	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 by listing one or more
	capability names consisting of "PREVIEW=" followed by a supported		capability names consisting of "PREVIEW=" followed by a supported
	preview algorithm name. This format provides for future upwards-		preview algorithm name. This format provides for future upwards-
	compatible extensions and/or the ability to use locally-defined		compatible extensions and/or the ability to use locally-defined
	preview algorithms.		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",
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 8 ¶
	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 stored permanently, these previews MUST be		sensitive information. If generated preview data is stored on the
	protected with equivalent authorization and confidentiality controls		server, e.g. for caching purposes, these previews MUST be protected
	as the source message.		with equivalent authorization and confidentiality controls as the
			source message.
	10. References		10. References
	10.1. Normative References		10.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>.
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 30 ¶
	o Add normative reference for text/plain		o Add normative reference for text/plain
	o Add warning regarding buffers and multiple octet preview		o Add warning regarding buffers and multiple octet preview
	characters		characters
	o Clarify how to handle preview data return when using an explicit		o Clarify how to handle preview data return when using an explicit
	algorithm list		algorithm list
	o Various editorial fixes		o Various editorial fixes
			Changes from draft-ietf-extra-imap-fetch-preview-04:
			o Make clear that preview caching is tied to retention period of the
			source message
	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, Alexey Melnikov, Chris		Gondwana, Teemu Huovila, Steffen Lehmann, Alexey Melnikov, Chris
	Newman, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi.		Newman, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi.
	Author's Address		Author's Address
	Michael M. Slusarz		Michael M. Slusarz
End of changes. 6 change blocks.
	11 lines changed or deleted		17 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/