[Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-extra-imap-fetch-preview-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/



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


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