draft-ietf-extra-imap-fetch-preview-02.txt   draft-ietf-extra-imap-fetch-preview-03.txt 
EXTRA M. Slusarz EXTRA M. Slusarz
Internet-Draft Open-Xchange Inc. Internet-Draft Open-Xchange Inc.
Intended status: Standards Track February 13, 2019 Intended status: Standards Track February 16, 2019
Expires: August 17, 2019 Expires: August 20, 2019
IMAP4 Extension: Message Preview Generation IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-02 draft-ietf-extra-imap-fetch-preview-03
Abstract Abstract
This document specifies an IMAP protocol extension which allows a This document specifies an Internet Message Access Protocol (IMAP)
client to request that a server provide an abbreviated representation protocol extension allowing a client to request a server-generated
of a message that can be used by a client to provide a useful abbreviated representation of message data useful as a contextual
contextual preview of the message contents. preview of the entire message.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 17, 2019. This Internet-Draft will expire on August 20, 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 2, line 18 skipping to change at page 2, line 18
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11
11.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) . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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 indefinitely. Retrieval of message data may message, and then cached indefinitely. Retrieval of message data may
be expensive within a server, for example, so a server can be be expensive within a server, for example, so a server can be
configured to reduce its storage retrieval load by pre-generating configured to reduce its storage retrieval load by pre-generating
preview data. preview data.
A server that supports the PREVIEW extension indicates this with one A server indicates support for this extension by listing one or more
or more capability names consisting of "PREVIEW=" followed by a capability names consisting of "PREVIEW=" followed by a supported
supported preview algorithm name. This format provides for future preview algorithm name. This format provides for future upwards-
upwards-compatible extensions and/or the ability to use locally- compatible extensions and/or the ability to use locally-defined
defined preview algorithms. preview algorithms and priority modifiers.
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 8, line 42 skipping to change at page 8, line 42
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=FUZZY))
S: E2 OK SEARCH completed. S: E2 OK SEARCH completed.
S: * 5 FETCH (UID 13 PREVIEW (FUZZY "Preview!")) S: * 5 FETCH (UID 13 PREVIEW (FUZZY "Preview!"))
S: * 9 FETCH (UID 23 PREVIEW (FUZZY NIL)) S: * 9 FETCH (UID 23 PREVIEW (FUZZY 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 (FUZZY))
S: * 9 FETCH (PREVIEW (FUZZY "Another preview!")) S: * 9 FETCH (UID 23 PREVIEW (FUZZY "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 / preview-mod-ext) capability =/ "PREVIEW=" (preview-alg / preview-mod-ext)
skipping to change at page 9, line 32 skipping to change at page 9, line 32
preview-atom = 1*<any ATOM-CHAR except "="> preview-atom = 1*<any ATOM-CHAR except "=">
preview-mod = "LAZY" / preview-mod-ext preview-mod = "LAZY" / preview-mod-ext
preview-mod-ext = preview-atom ; New priority modifier names preview-mod-ext = preview-atom ; New priority modifier names
; SHOULD be registered with IANA ; SHOULD be registered with IANA
; and MUST conform with the ; and MUST conform with the
; recommendations described in ; recommendations described in
; RFC 6648, Section 3 ; RFC 6648, Section 3
8. Acknowledgements 8. IANA Considerations
The author would like to thank the following people for their
comments and contributions to this document: Stephan Bosch, Bron
Gondwana, Teemu Huovila, Steffen Lehmann, Alexey Melnikov, Chris
Newman, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi.
9. 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=FUZZY" capability
to the IMAP4 [RFC3501] capabilities registry. to the IMAP4 [RFC3501] capabilities registry.
This document requests that IANA create a new PREVIEW algorithms This document requests that IANA create a new PREVIEW algorithms
registry, which registers preview algorithms by publishing a registry, which registers preview algorithms by publishing a
standards track or IESG-approved experimental RFC. This document standards track or IESG-approved experimental RFC. This document
constitutes registration of the FUZZY algorithm in that registry. constitutes registration of the FUZZY algorithm in that registry.
This document requests that IANA create a new PREVIEW modifiers This document requests that IANA create a new PREVIEW priority
registry, which registers preview modifiers by publishing a standards modifiers registry, which registers preview priority modifiers by
track or IESG-approved experimental RFC. This document constitutes publishing a standards track or IESG-approved experimental RFC. This
registration of the LAZY modifier in that registry. document constitutes registration of the LAZY priority modifier in
that registry.
10. 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. the resources that preview generation uses.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
skipping to change at page 11, line 9 skipping to change at page 11, line 5
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham, [RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012, DOI 10.17487/RFC6648, June 2012,
<https://www.rfc-editor.org/info/rfc6648>. <https://www.rfc-editor.org/info/rfc6648>.
[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>.
11.2. Informative References 10.2. Informative References
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media
Type", RFC 2854, DOI 10.17487/RFC2854, June 2000, Type", RFC 2854, DOI 10.17487/RFC2854, June 2000,
<https://www.rfc-editor.org/info/rfc2854>. <https://www.rfc-editor.org/info/rfc2854>.
skipping to change at page 12, line 42 skipping to change at page 12, line 38
o Removed CAPABILITY string for examples where it did not add o Removed CAPABILITY string for examples where it did not add
valuable context valuable context
o Altered preview data in examples to cover a variety of potential o Altered preview data in examples to cover a variety of potential
server return scenarios server return scenarios
o Added "SHOULD be registered" language to algorithm names and o Added "SHOULD be registered" language to algorithm names and
priority modifiers priority modifiers
Changes from draft-ietf-extra-imap-fetch-preview-02:
o Move Acknowledgments to un-numbered appendix
o Improved abstract text
o Consistently use "priority modifiers" instead of "modifiers"
o Update example to conform with RFC 3501 UID FETCH requirements
Acknowledgments
The author would like to thank the following people for their
comments and contributions to this document: Stephan Bosch, Bron
Gondwana, Teemu Huovila, Steffen Lehmann, Alexey 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. 15 change blocks. 
37 lines changed or deleted 48 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/