IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-10

[Ballot comment]
Discuss cleared.

One minor comment:

  This standardized display can reduce user confusion when using
  multiple clients, as abbreviated message representations in clients
  will show identical message contents.

I didn't really find this reasoning to be compelling, and perhaps it could be removed.  In my experience the amount of preview displayed depends on client behaviour or settings (e.g., how much space to allow for previews).

Regards,
Rob

[Ballot comment]
Hi,

thank you for this document.
Couple of minor comments relating to normative language, plus a question.

  A server SHOULD strive to generate
shouldn't that be: A server SHOULD generate

  should be sized to prevent possible overflow errors
SHOULD?

Whether the server uses a cached preview or generates a new one (may be identical to cached) is implementation specific?

nits:
s/additional display/additionally display/

[Ballot comment]
Thank you for writing this document - I found it easy to read, useful, and interesting (even to a non-IMAP person!).

I was initially concerned that this would be adding significant load to the server, but the explanation on the tradeoff answered that - thanks!

I'd note that the shepherd write-up is now out of date - Barry, not Alexey is the responsible AD (this isn't worth updating, just mentioning)

[Ballot discuss]
Hi,

Thanks for this document.  I found it easy to read and understand, but have one potential issue that probably warrants a bit of discussion.  I don't have any great knowledge of IMAP, so this may already be handled elsewhere, but I had a concern about returning zero-length strings under error conditions.

  It is possible that the server has determined that no meaningful
  preview text can be generated for a particular 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 MUST return a zero-length
  string.  Clients SHOULD NOT send another FETCH for a preview for such
  messages.  (As discussed previously, preview data is not immutable so
  there is chance that at some point in the future the server would be
  able to generate meaningful text.  However, this scenario is expected
  to be rare so a client should not continually send out requests to
  try to capture this infrequent occurrence.)
 
  ... A server MUST NOT return NIL
  to a FETCH PREVIEW request made without the LAZY modifier.

When the LAZY modifier is not being used, then what would be returned if the server was transiently unable to return the preview for any reason?  Does it still have to return a zero-length string in this error case?  Is there some way that the server can indicate that it cannot satisfy the request now but without indicating that no preview is available?

[Ballot comment]
One minor comment:

  This standardized display can reduce user confusion when using
  multiple clients, as abbreviated message representations in clients
  will show identical message contents.

I didn't really find this reasoning to be compelling, and perhaps it could be removed.  In my experience the amount of preview displayed depends on client behaviour or settings (e.g., how much space to allow for previews).

Regards,
Rob

[Ballot comment]
I agree with Martin D's comment.

I was a little surprised to not see any mention of the analogous JMAP
capability (but I guess I'm not actually sure whether one or the other
"came first").

Section 3.3

  The server SHOULD limit the length of the preview text to 200 preview
  characters.  This length should provide sufficient data to generally
  support both various languages (and their different average word
  lengths) and diverse client display size requirements.

Does the internationalization directorate agree with this analysis?

  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).

nit: is "human-generated text" the right description here?  A quick read
of RFC 5255 suggests that "generated for human consumption" is usually
the appropriate characterization of text affected by the langauge
selection.

Section 4.2

  Once this initial FETCH is complete, the client can then issue FETCH
  requests, without the LAZY modifier, to load the preview data for the

nit: "PREVIEW data item" would be more consistent with the previous
paragraph (and make it harder to skip over the fact that the preview
data is being FETCHed, not the entire message).

  messages in which preview data was not returned.  It is RECOMMENDED
  that these FETCH requests be issued in small batches, e.g. 50
  messages per FETCH command, since preview generation may be expensive
  and a single large request may exceed server resource limits.

nit: comma after "e.g.".

Section 5

I'd consider updating the dates in the examples to be closer to the
publication date of the document.

Section 8

Does it go without saying that a given user should only have access to
preview content for messages that it has access to the full content of?

  results are stored on the server after generation.  Servers MAY limit
  the resources that preview generation uses.  In order to mitigate

Would this result in the server generating empty-string previews for
some messages that it would otherwise have produced a non-empty preview
for?  I'd like to see a little more description of expected server
behavior in the case of excessive resource usage for preview generation.

[Ballot comment]
I don't understand the purpose of the phrase "and that decision won't change later" in Section 3.2. Even if the decision were to change later, if there is nothing to present there will still be an empty response, no?

[Ballot comment]
In Section 1, this reads oddly:

  Using server-generated previews allows global generation once per
  message, and then cached for the retention period of the source
  message.

Perhaps add "they can be" before "cached"?

Down in Section 7, I'm not sure the URL is necessary or wise to include.  If IANA should choose to change it for whatever reason, this reference becomes obsolete.  I think the name of the registry is sufficient.

[Ballot comment]
This was balloted before, but has had major changes since then and is a very different document.  It's just been through another last call, and I've cleared out the old ballot so we can have a fresh look.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-imap-fetch-preview-09. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

In the Internet Message Access Protocol (IMAP) Capabilities Registry located at:

https://www.iana.org/assignments/imap-capabilities/

a new registration is to be made as follows:

Capability Name: PREVIEW
Reference: [ RFC-to-be ]

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-09-14):

From: The IESG
To: IETF-Announce
CC: brong@fastmailteam.com, barryleiba@gmail.com, Bron Gondwana , extra-chairs@ietf.org, extra@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IMAP4 Extension: Message Preview Generation) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP4
Extension: Message Preview Generation'
  as Proposed Standard

This document went through Last Call in February 2019, but has had major
revisions and simplification since then, and is back for a second Last Call
at this time.

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-09-14. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

  This document specifies an Internet Message Access Protocol (IMAP)
  protocol extension allowing a client to request a server-generated
  abbreviated text representation of message data useful as a
  contextual preview of the entire message.


The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-ietf-extra-imap-fetch-preview

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501).  The request type is
indicated in the title page header as "Standards Track"

2.

Technical Summary

  This spec extends IMAP with an additional fetch item (PREVIEW)
  which allows clients to obtain a short piece of text to use as
  a preview line in mailbox listings.

Working Group Summary

  This document and fetch item was originally named "snippet", however
  JMAP uses "preview" for the equivalent field, and "snippet" for a
  marked up section of the message containing search terms, so the
  working group agreed to change the naming to be consistent.

  There was also debate over the maximum length, with both JMAP and
  EXTRA working groups settling on 256 characters maximum.

  Finally there were questions over whether "LAZY" was useful, but nobody
  saw any downside to including it.  Servers can choose to always calculate
  the preview even if LAZY is given.

  There was a significant amount of rework through multiple meetings which
  led to a very complex document.  In the end, the authors asked to drop
  the complexity and go back to an earlier version.  This achieved working
  group consensus, so we're back where we were again!

Document Quality

  This spec is quite easy to implement - it has multiple examples for all
  the likely cases.  It's been implemented in Dovecot and Cyrus IMAPd.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
implemented it in the Cyrus IMAPd server.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool said that the document year doesn't match current
year, but that's only because I ran it really early in 2019!

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations just asks for an entry in the IMAP
capabilities registry.

18. There are no new IANA registries.

19. The formal sections were validated with Chris Newman's ABNF
validator tool.

[Ballot comment]
I support Barry's DISCUSS point on Section 3.2.

In Section 4.1, I suggest s/The FUZZY algorithm/The FUZZY algorithm identifier/
(since it doesn't refer to an actual algorithm)

[Ballot comment]
[Re-issuing ballot position to direct discussion of the ABNF for 'capability'
to Barry's ballot thread; the rest of the COMMENT is unchanged]

Section 3.1

  Alternately, the client may explicitly indicate which algorithm(s)
  should be used in a parenthesized list after the PREVIEW attribute
  containing the name of the algorithm.  These algorithms MUST be one

nit: there's potential for misparsing here (e.g., that the PREVIEW
attribute contains the name of the algorithm and the parenthesized list
is after that), so maybe put "after the PREVIEW attribte" in parentheses
or offset by commas.

  of the algorithms identified as supported in the PREVIEW capability
  responses.  [...]

nit: singular/plural mismatch between "these algorithms" and "one of".

Section 7

How much discussion was there about "SHOULD be registered" (as opposed
to "MUST be registered")?

Section 8

side note: This is one of the shortest IANA considerations sections I've
seen thta creates registries (in that it doesn't lay out a registration
template), but IANA seems to be saying they have what information they
need, so who am I to complain...

Section 9

I agree with Roman that there should be discussion of the caching/data
retention strategy for message previews.

This existing text about denial-of-service attacks is probably fine,
though I might consider rephrasing it along the lines of "this mechanism
introduces a new way for clients to make requests that consume server
resources.  As is the case for all such mechanisms, it could be used as
part of a denial-of-service attack on server resources, e.g., via
excessive memory or CPU usage, or increased storage if preview results
are cached on the server after generation.  The additional attack
surface presented by this specific mechanism is not believed to higher
risk that other similar mechanisms in use already, since the individual
resource consumption per message processed is likely to be modest.
Nonetheless, servers MAY limit the resources consumed by preview
generation."

As I write the above, though, I wonder how this interacts with the
previous text in Section 3.1 about how the "server MUST honor a client's
algorithm priority decision".  Does that mean that if some future
(expensive) algorithm is specified, once a server implements that
algorithm, any client can force its use and thus the expensive resource
consumption on the server?  It's not entirely clear to me how this MAY
interacts with that MUST, in such a hypothetical scenario.

[Ballot comment]
In relation to Benjamin's Discuss. I also think there are necessary to clarify if the Capability usage of PREVIEW is a single algorithm or allows listing all the algorithms server supports.

[Ballot discuss]
— Section 3.1 —

I don’t understand “the client’s priority decision”: what decision is that?  And what’s the point of giving the server a list of algorithms here, given that they all have to be ones that are supported by the server?  Won’t the server always have to use the first one in the list?  If not, please add some text explaining what the server does.

— Section 3.2 —

  If the preview is not available, the server MUST return NIL as the
  PREVIEW response.  A NIL response indicates to the client that
  preview information MAY become available in a future PREVIEW FETCH
  request.  Note that this is semantically different than returning a
  zero-length string, which indicates an empty preview.

I think the MUST here is hard to follow, because the text doesn’t make a clear enough distinction between “preview is not available” and “an empty preview”.  Can you expand the text a bit to explain the distinction more clearly, as this is a protocol requirement?  Also, as I noted in response to Meral’s Gen-ART review it would be good to be clear how encrypted messages should be handled in this regard.

— Section 4.1 —

  The preview text MUST be treated as text/plain MIME data by the
  client.

I think this requires a normative reference to RFC 2046.

— Section 7 —

As was mentioned in Ben’s review, either the ABNF for “capability” is in error (it should not include “preview-mod-ext”) or the description needs to be significantly beefed up.  I’m guessing that the intent is that PREVIEW= capabilities include both algorithms and modifiers, that PREVIEW=FUZZY is required, that the presence of any preview algorithm implies PREVIEW=LAZY such that the latter not only need not be specified, but is not permitted to be.  So we might have “PREVIEW=FUZZY PREVIEW=FURRY PREVIEW=SLEEPY”, which would mean we support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLEEPY.  Is that correct?

That seems somewhat obtuse to me, overloading the PREVIEW= capability and inviting confusion.

— Section 8 —

It seems like a bad idea to have to keep the IMAP Capabilities registry in sync with the two new registries: as it stands, when you add a new algorithm you have to add it to the Preview Algorithms registry, and also add a corresponding entry in the Capabilities registry... and similarly for a modifier, if I have that right above.

Why not follow the model of AUTH= and RIGHTS=, and just reserve the PREVIEW= capability in the registry, allowing it to apply to entries from the two new registries?  That avoids inconsistencies in registrations if we later add algorithms or modifiers.

[Ballot comment]
Thanks to everyone who has worked on this document. I have a handful of comments
that should be considered prior to publication.

---------------------------------------------------------------------------

§3.1:

>  These algorithms MUST be one
>  of the algorithms identified as supported in the PREVIEW capability
>  responses.

This is confusing, as "algorithms" and "one of" don't make sense with each
other. Is it meant to say something like "...MUST be a subset of the
algorithms..."?

---------------------------------------------------------------------------

§3.1:

>  If a client requests an algorithm that is unsupported,
>  the server MUST return a tagged BAD response.

This appear to be underspecified, or at least nonintuitive. As written,
it seems to say that an algorithm list of (known-1, known-2, unknown, known-3)
would be considered invalid, even though there are plenty of supported,
requested algorithms that could be used. Is this actually intended to be an
error? If so, please make it explicit, as it's pretty counterintuitive.

(As an aside: it's also unnecessarily fragile from an interop perspective, so I
would suggest that this is not the desired behavior: I believe you want to
return an error only when *none* of the requested algorithms are supported).

---------------------------------------------------------------------------

§6, example 5:

>    C: E1 CAPABILITY
>    S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY SEARCHRES
>    S: E1 OK Capability command completed.
>    [...a mailbox is SELECTed...]
>    C: E2 SEARCH RETURN (SAVE) FROM "FOO"
>    C: E3 FETCH $ (UID PREVIEW (LAZY=FUZZY))

This example shows the use of a modifier ("LAZY") with an algorithm; however,
this modifier doesn't appear to be advertised by the server in its CAPABILITY
line. If I understand how this is supposed to work (looking at the definitions
in section 7), I would have expected:

    S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY PREVIEW=LAZY SEARCHRES

I'll note that this syntax effectively places algorithms and modifiers in the
same namespace, although IANA doesn't seem to be given any explicit
instructions about this. I think this needs to be cleaned up prior to
publication.  I would make this last point a DISCUSS, except that it appears
to be covered by Benjamin's DISCUSS already.

---------------------------------------------------------------------------
§1:

>  Using server generated previews allows global generation once per0

nit: "server-generated"

[Ballot discuss]
— Section 3.1 —

I don’t understand “the client’s priority decision”: what decision is that?  And what’s the point of giving the server a list of algorithms here, given that they all have to be ones that are supported by the server?  Won’t the server always have to use the first one in the list?  If not, please add some text explaining what the server does.

— Section 3.2 —

  If the preview is not available, the server MUST return NIL as the
  PREVIEW response.  A NIL response indicates to the client that
  preview information MAY become available in a future PREVIEW FETCH
  request.  Note that this is semantically different than returning a
  zero-length string, which indicates an empty preview.

I think the MUST here is hard to follow, because the text doesn’t make a clear enough distinction between “preview is not available” and “an empty preview”.  Can you expand the text a bit to explain the distinction more clearly, as this is a protocol requirement?  Also, as I noted in response to Meral’s Gen-ART review it would be good to be clear how encrypted messages should be handled in this regard.

— Section 4.1 —

  The preview text MUST be treated as text/plain MIME data by the
  client.

I think this requires a normative reference to RFC 2046.

— Section 5.1 —

The way you have LAZY working isn’t really consistent with the IMAP protocol model.  In that model, the client would not have to ask for the preview twice, one with LAZY and one without.  Instead, with LAZY, the server would return FETCH PREVIEW responses when it could — perhaps some in the first set of FETCH responses, and some, where the PREVIEW part was missing before, in unsolicited FETCH responses when the preview became available.  That way, the server has the responsibility of setting off a separate task to generate the previews, and to send them to the client when it has them (at which point it either saves the for future FETCHes or doesn’t).

As it’s written here, the client has to open a separate IMAP session with the server and ask a second time for the previews it’s missing — a separate session to avoid blocking other action on the main session.  And if the server has spun off a task to preemptively generate them because the client asked once (a good practice, given the description here) it has to retain them for some indefinite period waiting for the client to ask again.

Why was this not done with the first mechanism?

— Section 7 —

As was mentioned in Ben’s review, either the ABNF for “capability” is in error (it should not include “preview-mod-ext”) or the description needs to be significantly beefed up.  I’m guessing that the intent is that PREVIEW= capabilities include both algorithms and modifiers, that PREVIEW=FUZZY is required, that the presence of any preview algorithm implies PREVIEW=LAZY such that the latter not only need not be specified, but is not permitted to be.  So we might have “PREVIEW=FUZZY PREVIEW=FURRY PREVIEW=SLEEPY”, which would mean we support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLEEPY.  Is that correct?

That seems somewhat obtuse to me, overloading the PREVIEW= capability and inviting confusion.

— Section 8 —

It seems like a bad idea to have to keep the IMAP Capabilities registry in sync with the two new registries: as it stands, when you add a new algorithm you have to add it to the Preview Algorithms registry, and also add a corresponding entry in the Capabilities registry... and similarly for a modifier, if I have that right above.

Why not follow the model of AUTH= and RIGHTS=, and just reserve the PREVIEW= capability in the registry, allowing it to apply to entries from the two new registries?  That avoids inconsistencies in registrations if we later add algorithms or modifiers.

[Ballot comment]
— Section 3.1 —

Nit: Please change “alternately” to “alternatively”.

  These algorithms MUST be one
  of the algorithms identified as supported in the PREVIEW capability
  responses.

There’s a number-agreement problem here.

NEW
  All algorithms in the list MUST have been included in the
  list of algorithms identified as supported in the PREVIEW capability
  responses.
END

— Section 3.2 —

  This relaxed requirement permits a
  server to offer previews as an option without requiring potentially
  burdensome storage and/or processing requirements to guarantee
  immutability for a use case that does not require this strictness.

That’s sensible, but can you include some text giving an example of a situation where the preview might change?  Given that the messages themselves are immutable, why would applying the same algorithm to the same text give different results?

— Section 4.1 —

  The server SHOULD limit the length of the preview text to 200 preview
  characters.  This length should provide sufficient data to generally
  support both various languages (and their different average word
  lengths) and different client display size requirements.

  The server MUST NOT output preview text longer than 256 preview
  characters.

The text here should make it clear, because many implementers do not understand the difference, that these refer to *characters*, not *bytes*, and that 200 or 256 characters can possibly be much longer than 256 bytes.  I worry that an implementer might allocate a buffer of 256 bytes, thinking that’s enough, and have it overflowed.

  The server SHOULD remove any formatting markup that exists in the
  original text.

This is OK as it is, but perhaps a bit more specific than necessary.  I think the sense is that the server is meant to do its best to render the preview as plain text, because that’s what the client will treat it as.  As such, I would fold this into the earlier paragraph that talks about no transfer encoding, and maybe say it something like this:

  The generated string will be treated by the client as plain text, so
  the server should do its best to provide a meaningful plain text string.
  The generated string MUST NOT be content transfer encoded and MUST be
  encoded in UTF-8 [RFC3629].  For purposes of this section, a "preview
  character" is defined as a single UCS character encoded in UTF-8.  The
  server SHOULD also remove any formatting markup, and do what other
  processing might be useful in rendering the preview as plain text.

[Ballot discuss]
I wavered a lot about whether this was DISCUSS-worthy, but it seems like
we should at least talk about how big a risk for future confusion there
is:

I'm a little confused by the ABNF for 'capability' in Section 7 -- it
seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and
Section 3.1 talk only about *algorithms* in PREVIEW capability responses
(and not modifiers).  Is the intent to have capability tags for
(non-mandatory) priority modifiers?

[Ballot comment]
Section 3.1

  Alternately, the client may explicitly indicate which algorithm(s)
  should be used in a parenthesized list after the PREVIEW attribute
  containing the name of the algorithm.  These algorithms MUST be one

nit: there's potential for misparsing here (e.g., that the PREVIEW
attribute contains the name of the algorithm and the parenthesized list
is after that), so maybe put "after the PREVIEW attribte" in parentheses
or offset by commas.

  of the algorithms identified as supported in the PREVIEW capability
  responses.  [...]

nit: singular/plural mismatch between "these algorithms" and "one of".

Section 7

How much discussion was there about "SHOULD be registered" (as opposed
to "MUST be registered")?

Section 8

side note: This is one of the shortest IANA considerations sections I've
seen thta creates registries (in that it doesn't lay out a registration
template), but IANA seems to be saying they have what information they
need, so who am I to complain...

Section 9

I agree with Roman that there should be discussion of the caching/data
retention strategy for message previews.

This existing text about denial-of-service attacks is probably fine,
though I might consider rephrasing it along the lines of "this mechanism
introduces a new way for clients to make requests that consume server
resources.  As is the case for all such mechanisms, it could be used as
part of a denial-of-service attack on server resources, e.g., via
excessive memory or CPU usage, or increased storage if preview results
are cached on the server after generation.  The additional attack
surface presented by this specific mechanism is not believed to higher
risk that other similar mechanisms in use already, since the individual
resource consumption per message processed is likely to be modest.
Nonetheless, servers MAY limit the resources consumed by preview
generation."

As I write the above, though, I wonder how this interacts with the
previous text in Section 3.1 about how the "server MUST honor a client's
algorithm priority decision".  Does that mean that if some future
(expensive) algorithm is specified, once a server implements that
algorithm, any client can force its use and thus the expensive resource
consumption on the server?  It's not entirely clear to me how this MAY
interacts with that MUST, in such a hypothetical scenario.

[Ballot comment]
On the positive side, I really like the "it allows consistent representation of previews across all clients" in section 1.

Some questions though:

1) In the FUZZY algorithm (section 4.1), are we sure that removing all markup does significantly change the message? a 
can sometimes be perceived as a '.' == end of sentence; and removing them could vastly change the meaning of the message.

2) Section 3.2 "A server SHOULD strive to generate the same string for a give message for each request." which seems to contradict the "consistent representation" stated in section 1.

[Ballot discuss]
(1) Retention practices of cached previews
Section 1 says “Using server generated previews allows global generation once per message, and then cached indefinitely”.  Why cache indefinitely, especially if the source messages has been expunged?  For privacy reasons, couldn’t this caching be consistent with the retention of the email.

In Section 9, Security Considerations, there needs to be discussion of this retention too.  Perhaps text like:
“Implementations that pre-generate and store previews MUST ensure that the stored preview is also deleted when the corresponding mail message is expunged.”

(2) Protection of previews at rest
In Section 9, Security Considerations, there needs to be discussion about the potential sensitivity of these previews and the need to protect them.  Perhaps text like:
“Just as the messages they summarize, previews may contain sensitive information.  When stored, these previews MUST be protected with equivalent authorization and confidentiality controls as the source message.”

[Ballot comment]
(1) Use of RFC 2119 words
Please consider if these proposed changes are appropriate uses of RFC 2119 key words:

Section 2
s/As with all IMAP extension documents, the case used in writing IMAP protocol elements herein is chosen for editorial clarity, and implementations must  pay attention to the numbered rules at the beginning of [RFC3501] Section 9./
As with all IMAP extension documents, the case used in writing IMAP protocol elements herein is chosen for editorial clarity, and implementations MUST pay attention to the numbered rules at the beginning of [RFC3501] Section 9./

Section 3.1
s/Alternately, the client may  explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm./
Alternately, the client MAY explicitly indicate which algorithm(s) should be used in a parenthesized list after the PREVIEW attribute containing the name of the algorithm./

(2) Section 3.1, the paragraph “If no algorithm identifier is provided, the server decides …” discusses algorithm identifiers but their use hasn’t been introduced yet.  I recommend swapping the order of this paragraph with the current third paragraph (“Alternative …”) as this is where algorithms are introduced.

(3) Section 4.1.  Duplicate word. s/to the the language/to the language/

(4) Section 4.1.  Nit on word order. s/no human-readable text to generate preview information from/no human-readable text from which to generate preview information/

(5) Section 7.  In the ABNF comments, consider using “[RFC6648]” instead of “RFC 6648”.

[Ballot comment]
A few small comments on the IANA section: It would be good to also provide a name for each of the new registries (but I'm sure IANA will ask about this in their review). However, I'm also wondering why you don't specify straight away the use of the IETF Review policy as specified in RFC5226? Is there something different in there that does not work for you?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-imap-fetch-preview-01. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at:

https://www.iana.org/assignments/imap-capabilities/

a single new capability is to be registered as follows:

Capability Name: PREVIEW=FUZZY
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the PREVIEW algorithms registry. Registrations are managed via standards track or IESG-approved experimental RFC as defined in RFC 8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The initial registry is to look as follows:

PREVIEW
Algorithm Reference
-----------------------+----------------
FUZZY [ RFC-to-be ]

Third, a new registry is to be created called the PREVIEW modifiers registry. Registrations are managed via standards track or IESG-approved experimental RFC as defined in RFC 8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The initial registry is to look as follows:

PREVIEW
Modifier Reference
-----------------------+----------------
LAZY [ RFC-to-be ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-extra-imap-fetch-preview@ietf.org, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, alexey.melnikov@isode.com, Bron Gondwana
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IMAP4 Extension: Message Preview Generation) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP4
Extension: Message Preview Generation'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document specifies an IMAP protocol extension which allows a
  client to request that a server provide an abbreviated representation
  of a message that can be used by a client to provide a useful
  contextual preview of the message contents.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/ballot/


No IPR declarations have been submitted directly on this I-D.

Document Shepherd Write-Up for draft-ietf-extra-imap-fetch-preview

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501).  The request type is
indicated in the title page header as "Standards Track"

2.

Technical Summary

  This spec extends IMAP with an additional fetch item (PREVIEW)
  which allows clients to obtain a short piece of text to use as
  a preview line in mailbox listings.

Working Group Summary

  This document and fetch item was originally named "snippet", however
  JMAP uses "preview" for the equivalent field, and "snippet" for a
  marked up section of the message containing search terms, so the
  working group agreed to change the naming to be consistent.

  There was also debate over the maximum length, with both JMAP and
  EXTRA working groups settling on 256 characters maximum.

  Finally there were questions over whether "LAZY" was useful, but nobody
  saw any downside to including it.  Servers can choose to always calculate
  the preview even if LAZY is given.

Document Quality

  This spec is quite easy to implement - it has multiple examples for all
  the likely cases.  It's been implemented in Dovecot and Cyrus IMAPd.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
implemented it in the Cyrus IMAPd server.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool said that the document year doesn't match current
year, but that's only because I ran it really early in 2019!

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations just asks for an entry in the IMAP
capabilities registry.

18. There are no new IANA registries.

19. The formal sections were validated with Chris Newman's ABNF
validator tool.

Document Shepherd Write-Up for draft-ietf-extra-imap-fetch-preview

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501).  The request type is
indicated in the title page header as "Standards Track"

2.

Technical Summary

  This spec extends IMAP with an additional fetch item (PREVIEW)
  which allows clients to obtain a short piece of text to use as
  a preview line in mailbox listings.

Working Group Summary

  This document and fetch item was originally named "snippet", however
  JMAP uses "preview" for the equivalent field, and "snippet" for a
  marked up section of the message containing search terms, so the
  working group agreed to change the naming to be consistent.

  There was also debate over the maximum length, with both JMAP and
  EXTRA working groups settling on 256 characters maximum.

  Finally there were questions over whether "LAZY" was useful, but nobody
  saw any downside to including it.  Servers can choose to always calculate
  the preview even if LAZY is given.

Document Quality

  This spec is quite easy to implement - it has multiple examples for all
  the likely cases.  It's been implemented in Dovecot and Cyrus IMAPd.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Alexey Melnikov


3. The Document Shepherd has read the document through in detail and
implemented it in the Cyrus IMAPd server.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool said that the document year doesn't match current
year, but that's only because I ran it really early in 2019!

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There are no downward normative references references.

16. This RFC does not change the status of any other RFCs.

17. The IANA considerations just asks for an entry in the IMAP
capabilities registry.

18. There are no new IANA registries.

19. The formal sections were validated with Chris Newman's ABNF
validator tool.