< draft-ietf-extra-imap-fetch-preview-00.txt   draft-ietf-extra-imap-fetch-preview-01.txt >
EXTRA M. Slusarz EXTRA M. Slusarz
Internet-Draft Open-Xchange Inc. Internet-Draft Open-Xchange Inc.
Intended status: Standards Track November 5, 2018 Intended status: Standards Track January 22, 2019
Expires: May 9, 2019 Expires: July 26, 2019
IMAP4 Extension: Message Preview Generation IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-00 draft-ietf-extra-imap-fetch-preview-01
Abstract Abstract
This document specifies an IMAP protocol extension which allows a This document specifies an IMAP protocol extension which allows a
client to request that a server provide an abbreviated representation client to request that a server provide an abbreviated representation
of a message that can be used by a client to provide a useful of a message that can be used by a client to provide a useful
contextual preview of the message contents. contextual preview of the message contents.
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 May 9, 2019. This Internet-Draft will expire on July 26, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
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 . . . . . . . . . . . . . . . . . 5 5. PREVIEW Priority Modifiers . . . . . . . . . . . . . . . . . 6
5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. LAZY . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 12
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
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 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.
Generation of a preview on the server has several benefits. First, Generation of a preview on the server has several benefits. First,
it allows consistent representation of previews across all clients. it allows consistent representation of previews across all clients.
This standardized display can reduce user confusion when using This standardized display can reduce user confusion when using
multiple clients, as abbreviated message representations in clients multiple clients, as abbreviated message representations in clients
will show identical message details. will show identical message contents.
Second, server-side preview generation is more efficient. A client- Second, server-side preview generation is more efficient. A client-
based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE based algorithm needs to issue, at a minimum, a FETCH BODYSTRUCTURE
command in order to determine which MIME [RFC2045] body part(s) command in order to determine which MIME [RFC2045] body part(s)
should be represented in the preview. Subsequently, at least one should be represented in the preview. Subsequently, at least one
FETCH BODY command may be needed to retrieve body data used in FETCH BODY command may be needed to retrieve body data used in
preview generation. These FETCH commands cannot be pipelined since preview generation. These FETCH commands cannot be pipelined since
the BODYSTRUCTURE query must be parsed on the client before the list the BODYSTRUCTURE query must be parsed on the client before the list
of parts to be retrieved via the BODY command(s) can be determined. of parts to be retrieved via the BODY command(s) can be determined.
skipping to change at page 3, line 19 skipping to change at page 3, line 19
algorithm to display data contained in a text/html [RFC2854] part algorithm to display data contained in a text/html [RFC2854] part
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 them to be generated globally Using server generated previews allows global generation once per
once per message, and then cached indefinitely. Retrieval of message message, and then cached indefinitely. Retrieval of message data may
data may be expensive within a server, for example, so a server can be expensive within a server, for example, so a server can be
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 that supports the PREVIEW extension indicates this with one
or more capability names consisting of "PREVIEW=" followed by a or more capability names consisting of "PREVIEW=" followed by a
supported preview algorithm name. This format provides for future supported preview algorithm name. This format provides for future
upwards-compatible extensions and/or the ability to use locally- upwards-compatible extensions and/or the ability to use locally-
defined preview algorithms. defined preview algorithms.
2. Conventions Used In This Document 2. Conventions Used In This Document
skipping to change at page 4, line 36 skipping to change at page 4, line 36
honor a client's algorithm priority decision. honor a client's algorithm priority decision.
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
C: A1 FETCH 1 (PREVIEW)
S: * 1 FETCH (PREVIEW (FUZZY "Preview text!"))
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.
If the preview is not available, the server MUST return NIL as the If the preview is not available, the server MUST return NIL as the
PREVIEW response. A NIL response indicates to the client that PREVIEW response. A NIL response indicates to the client that
preview information MAY become available in a future PREVIEW FETCH preview information MAY become available in a future PREVIEW FETCH
request. request. Note that this is semantically different than returning a
zero-length string, which indicates an empty preview.
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
skipping to change at page 5, line 38 skipping to change at page 5, line 41
The server MUST NOT output preview text longer than 256 preview The server MUST NOT output preview text longer than 256 preview
characters. characters.
The server SHOULD remove any formatting markup that exists in the The server SHOULD remove any formatting markup that exists in the
original text. original text.
If the FUZZY algorithm generates a preview that is not based on the If the FUZZY algorithm generates a preview that is not based on the
body content of the message and the LANGUAGE [RFC5255] extension is body content of the message and the LANGUAGE [RFC5255] extension is
supported by the server, the preview text SHOULD be generated supported by the server, the preview text SHOULD be generated
according to the the language rules that apply to human-readable according to the the language rules that apply to human-readable
text. text. For example, a message that consists of a single image MIME
part has no human-readable text to generate preview information from.
Instead, the server may wish to output a description that the message
contains an image and describe some attributes of the image, such as
image format, size, and filename. This descriptive text is not a
product of the message body itself but is rather auto-generated data
by the server, and should thus use the rules defined for human-
generated text described in the LANGUAGE extension (if supported on
the server).
5. PREVIEW Priority Modifiers 5. PREVIEW Priority Modifiers
5.1. LAZY 5.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.
This modifier allows a client to inform the server that preview data This modifier allows a client to inform the server that preview data
is nice-to-have, but the server SHOULD NOT block the return of other is nice-to-have, but the server SHOULD NOT block the return of other
FETCH information at the expense of generating the preview data. FETCH information at the expense of generating the preview data.
For example, a client displaying the initial mailbox listing to a For example, a client displaying the initial mailbox listing to a
user may want to display preview information associated with messages user may want to display preview information associated with messages
in that listing. However, this information is secondary to providing in that listing. However, this information is secondary to providing
the mailbox listing, with message details, and the client is willing the mailbox listing, with message details, and the client is willing
to load any unavailable previwes in the background and display them to load any unavailable previews in the background and display them
as they are provided by the server. In this case, the client would as they are provided by the server. In this case, the client would
use the LAZY modifier to the desired algorithm(s) to direct the apply the LAZY modifier to the desired algorithm(s) to direct the
server to only return pre-generated preview data so that retrieval of server to only return pre-generated preview data so that retrieval of
the other FETCH information is not blocked by possibly expensive the other FETCH information is not blocked by possibly expensive
preview generation. preview generation.
Generally, the LAZY modifier will only be used once per mailbox load
during the initial listing. If preview information is not available
during this initial FETCH, the expectation is that a second non-LAZY
FETCH will take place after mailbox listing activities are complete.
Thus, a maximum of 2 PREVIEW FETCH queries should occur for any
message in a selected mailbox. A client SHOULD NOT continually issue
LAZY PREVIEW FETCH commands in a selected mailbox as the server is
under no requirement to return preview information for this command,
which could lead to an unnecessary waste of system and network
resources. See Example 4 in the Examples section for how this can be
implemented.
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.
6. Examples 6. Examples
Example 1: Requesting FETCH without explicit algorithm selection.
Example 1: Requesting FETCH without explicit algorithm selection
C: A1 CAPABILITY C: A1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY
S: A1 OK Capability command completed. S: A1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
C: A2 FETCH 1 (RFC822.SIZE PREVIEW) C: A2 FETCH 1 (RFC822.SIZE PREVIEW)
S: * 1 FETCH (RFC822.SIZE 20000 PREVIEW (FUZZY {58} S: * 1 FETCH (RFC822.SIZE 20000 PREVIEW (FUZZY {58}
S: This is the first line of text from the first text part. S: This is the first line of text from the first text part.
S: )) S: ))
S: A2 OK FETCH complete. S: A2 OK FETCH complete.
Example 2: Requesting FETCH with explicit algorithm selection Example 2: Requesting FETCH with explicit algorithm selection.
C: B1 CAPABILITY C: B1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY
S: B1 OK Capability command completed. S: B1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
C: B2 FETCH 1 (RFC822.SIZE PREVIEW (FUZZY)) C: B2 FETCH 1 (RFC822.SIZE PREVIEW (FUZZY))
S: * 1 FETCH (RFC822.SIZE 20000 PREVIEW (FUZZY {58} S: * 1 FETCH (RFC822.SIZE 20000 PREVIEW (FUZZY {58}
S: This is the first line of text from the first text part. S: This is the first line of text from the first text part.
S: )) S: ))
S: B2 OK FETCH complete. S: B2 OK FETCH complete.
Example 3: Requesting FETCH with invalid explicit algorithm selection Example 3: Requesting FETCH with invalid explicit algorithm
selection.
C: C1 CAPABILITY C: C1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY
S: C1 OK Capability command completed. S: C1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
C: C2 FETCH 1 (RFC822.SIZE PREVIEW (X-PREVIEW-ALGO)) C: C2 FETCH 1 (RFC822.SIZE PREVIEW (UNKNOWN-PREVIEW-ALGO))
S: C2 BAD FETCH contains invalid preview algorithm name. S: C2 BAD FETCH contains invalid preview algorithm name.
Example 4: Use explicit algorithm priority selection, with LAZY Example 4: Use explicit algorithm priority selection, with LAZY
modifier, to obtain previews during initial mailbox listing if modifier, to obtain previews during initial mailbox listing if
readily available; otherwise, load previews in background readily available; otherwise, load previews in background.
C: D1 CAPABILITY C: D1 CAPABILITY
S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY
S: D1 OK Capability command completed. S: D1 OK Capability command completed.
[...a mailbox is SELECTed...] [...a mailbox is SELECTed...]
C: D2 FETCH 1:3 (ENVELOPE PREVIEW (LAZY=FUZZY)) C: D2 FETCH 1:3 (ENVELOPE PREVIEW (LAZY=FUZZY))
S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...]) S: * 1 FETCH (ENVELOPE ("Wed, 25 Oct 2017 15:03:11 +0000" [...])
PREVIEW (FUZZY {58} PREVIEW (FUZZY {58}
S: This is the first line of text from the first text part. S: This is the first line of text from the first text part.
S: )) S: ))
skipping to change at page 9, line 14 skipping to change at page 10, line 14
capability =/ "PREVIEW=FUZZY" capability =/ "PREVIEW=FUZZY"
fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP fetch-att =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP
preview-alg-fetch) ")"] preview-alg-fetch) ")"]
msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")" msg-att-dynamic =/ "PREVIEW" SP "(" preview-alg SP nstring ")"
preview-alg = "FUZZY" / preview-alg-ext preview-alg = "FUZZY" / preview-alg-ext
preview-alg-ext = preview-atom ; New algorithms MUST be preview-alg-ext = preview-atom ; New algorithm names MUST
; registered with IANA ; conform with the
; recommendations described in
; RFC 6648, Section 3
preview-alg-fetch = preview-alg / preview-mod "=" preview-alg preview-alg-fetch = preview-alg / preview-mod "=" preview-alg
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 modifiers MUST be preview-mod-ext = preview-atom ; New priority modifier names
; registered with IANA ; MUST conform with the
; recommendations described in
; RFC 6648, Section 3
8. Acknowledgements 8. Acknowledgements
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, Chris Newman, Jeff Sipek, Gondwana, Teemu Huovila, Steffen Lehmann, Alexey Melnikov, Chris
Timo Sirainen, Steffen Templin, and Aki Tuomi. Newman, Jeff Sipek, Timo Sirainen, Steffen Templin, and Aki Tuomi.
9. IANA Considerations 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
registry, which registers preview algorithms by publishing a
standards track or IESG-approved experimental RFC. This document
constitutes registration of the FUZZY algorithm in that registry.
This document requests that IANA create a new PREVIEW modifiers
registry, which registers preview modifiers by publishing a standards
track or IESG-approved experimental RFC. This document constitutes
registration of the LAZY modifier in that registry.
10. Security Considerations 10. Security Considerations
There are no known additional security issues with this extension Implementation of this extension might enable denial-of-service
beyond those described in the base protocol described in IMAP4 attacks against server resources, due to excessive memory or CPU
[RFC3501]. usage during preview generation or increased storage usage if preview
results are stored on the server after generation. Servers MAY limit
the resources that preview generation uses.
11. References 11. References
11.1. Normative References 11.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>.
skipping to change at page 10, line 32 skipping to change at page 11, line 45
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet [RFC5255] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255, Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008, DOI 10.17487/RFC5255, June 2008,
<https://www.rfc-editor.org/info/rfc5255>. <https://www.rfc-editor.org/info/rfc5255>.
[RFC6648] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648,
DOI 10.17487/RFC6648, June 2012,
<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 11.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>.
skipping to change at page 11, line 33 skipping to change at page 13, line 4
o Updated length requirements for PREVIEW=FUZZY o Updated length requirements for PREVIEW=FUZZY
o Added preview-atom ABNF to limit use of "=" character o Added preview-atom ABNF to limit use of "=" character
o UTF-8 is a normative reference o UTF-8 is a normative reference
o Clarify that characters for purpose of length limitations are o Clarify that characters for purpose of length limitations are
defined as UCS characters as encoded by UTF-8 defined as UCS characters as encoded by UTF-8
o Fix some incorrect literal lengths in examples o Fix some incorrect literal lengths in examples
Changes from draft-ietf-extra-imap-fetch-preview-00:
o Updated postal address
o Added example to FETCH response section
o Added example on how LANGUAGE extension may influence preview
generation
o Added recommendation that only one LAZY FETCH be executed for a
message per mailbox
o Added request to create algorithm and modifier registries
o Added requirement that algorithm and modifier names conform to RFC
6648
o Added DoS attack info to security considerations
o Distinguish between NIL response and zero-length string
o Don't use deprecated "X-" convention in example
o Spelling and nits
Author's Address Author's Address
Michael Slusarz Michael M. Slusarz
Open-Xchange Inc. Open-Xchange Inc.
Denver, Colorado 530 Lytton Avenue
Palo Alto, California 94301
US US
Email: michael.slusarz@open-xchange.com Email: michael.slusarz@open-xchange.com
 End of changes. 29 change blocks. 
42 lines changed or deleted 116 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/