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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/