< draft-ietf-extra-imap-fetch-preview-05.txt   draft-ietf-extra-imap-fetch-preview-06.txt >
EXTRA M. Slusarz EXTRA M. Slusarz
Internet-Draft Open-Xchange Inc. Internet-Draft Open-Xchange Inc.
Intended status: Standards Track April 28, 2019 Intended status: Standards Track July 1, 2019
Expires: October 30, 2019 Expires: January 2, 2020
IMAP4 Extension: Message Preview Generation IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-05 draft-ietf-extra-imap-fetch-preview-06
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 30, 2019. This Internet-Draft will expire on January 2, 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 17 skipping to change at page 2, line 17
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. FUZZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 6 5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 6
5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change History (To be removed by RFC Editor before Appendix A. Change History (To be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 11 publication) . . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
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 4, line 29 skipping to change at page 4, line 29
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
in the list SHOULD be ignored. For purposes of duplicate detection, in the list SHOULD be ignored. For purposes of duplicate detection,
priority modifiers (Section 5) should be ignored. A server MUST priority modifiers (Section 5) should be ignored. A server MUST
honor a client's algorithm priority decision. honor a client's algorithm priority decision.
A server should return preview data for the first algorithm that A server should return preview data for the first algorithm that
returns non-empty preview text. Non-empty preview text is defined as returns non-empty preview text. Empty preview text is defined as
either the NIL response or an empty string. If no algorithm produces either the NIL response or an empty (zero length) string. If no
non-empty preview text, the server should respond with the preview algorithm produces non-empty preview text, the server should respond
data generated by the final algorithm in the list. 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 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
skipping to change at page 5, line 7 skipping to change at page 5, line 7
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.
For example, the underlying IMAP server may change for an account due
to a software upgrade; account state information may be retained in
the migration, but the new server may support a different PREVIEW
generation algorithm. Thus, message state may remain the same but
the FETCH PREVIEW response may change, if that data was not part of
the data migration.
If the preview is not available, the server MUST return NIL as the It is possible that preview text is not available now, but might be
PREVIEW response. A NIL response indicates to the client that available later -- perhaps the server's preview-generating resources
preview information MAY become available in a future PREVIEW FETCH are overloaded, there is a server-imposed timeout during preview
request. generation, or there is some transient issue with fetching the
message body. In such cases, the server will return NIL as the
Examples why a preview may not be available include: the preview preview response, and the client can try to retrieve the preview
generation process is not available due to transient server resource later.
limitations, the message body text is unavailable, or a server-
imposed timeout was reached during generation.
A NIL response is semantically different than returning a zero-length On the other hand, it is possible that the server has determined that
string, which indicates that no meaningful preview text can be no meaningful preview text can be generated for a particular message,
generated for the message. and that decision won't change later. Examples of this involve
encrypted messages, content types the server does not support
previews of, and other situations where the server is not able to
extract information for a preview. In such cases, the server will
return a zero-length string. Clients should not send another FETCH
for a preview for such messages.
4. PREVIEW Algorithms 4. PREVIEW Algorithms
4.1. FUZZY 4.1. FUZZY
The FUZZY algorithm directs the server to use any internal algorithm The FUZZY algorithm directs the server to use any internal algorithm
it desires, subject to the below limitations, to generate a textual it desires, subject to the below limitations, to generate a textual
preview for a message. preview for a message.
The FUZZY algorithm MUST be implemented by any server that supports The FUZZY algorithm MUST be implemented by any server that supports
the PREVIEW extension. the PREVIEW extension.
The preview text MUST be treated as text/plain [RFC2046] MIME data by The preview text MUST be treated as text/plain [RFC2046] media type
the client. 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
skipping to change at page 9, line 34 skipping to change at page 10, line 13
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=FUZZY" capability This document requests that IANA adds the "PREVIEW=" capability to
to the IMAP4 [RFC3501] capabilities registry. the 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. FUZZY algorithm in that registry.
9. Security Considerations 9. Security Considerations
skipping to change at page 13, line 35 skipping to change at page 14, line 12
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: Changes from draft-ietf-extra-imap-fetch-preview-04:
o Make clear that preview caching is tied to retention period of the o Make clear that preview caching is tied to retention period of the
source message source message
Changes from draft-ietf-extra-imap-fetch-preview-05:
o Clarify "zero-length string" preview data vs. NIL preview data
o MIME data -> media type
o Capability registration should not include the algorithm name
o Give example of how PREVIEW data might change over time
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, Barry Leiba, Alexey
Newman, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi. Melnikov, Chris Newman, Jeff Sipek, Timo 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. 13 change blocks. 
32 lines changed or deleted 52 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/