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

[Michael Slusarz <[e-mail]>]

Roman,

Thanks for your comments.  See below:

> On April 3, 2019 at 2:23 PM Roman Danyliw via Datatracker <[e-mail]> wrote:
> 
> ----------------------------------------------------------------------
> 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.”

Agree with your comments (and Barry and Alexey) that this language can be improved.  I implemented better language last week in the draft ... but unfortunately I can't access those changes at the moment as our RCS system is involved in a public cloud outage.  Once back online, I'll share the revised text.

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

My recollection is that I added this text, or a slight derivation of it, to the Security section.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (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”.

Fixes to these various nits were added to the draft.  Per Barry's reply, I did not implement the proposed RFC 8174 changes.

michael