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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 03 Apr 2019 13:23:17 -0700

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

---

From: Barry Leiba <[email-masked]>
Date: Wed, 3 Apr 2019 16:37:49 -0400

Hi, Roman.

> caching be consistent with the retention of the email.

"Indefinitely" doesn't mean forever... it means that the time period
is not definite.
That said, your suggested change makes sense, and I think we should make it.

> authorization and confidentiality controls as the source message.”

This also makes sense and should be made.

> containing the name of the algorithm./

These are both applications of RFC 8174 and should stand as they are written.

Barry

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 3 Apr 2019 20:46:12 +0000

> -----Original Message-----
> From: Barry Leiba [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2019 4:38 PM
> To: Roman Danyliw <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; Bron Gondwana
> <[email-masked]>; [email-masked]; draft-ietf-extra-imap-
> [email-masked]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-
> preview-03: (with DISCUSS and COMMENT)
> 
> Hi, Roman.
> 
> > (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.
> 
> "Indefinitely" doesn't mean forever... it means that the time period is not
> definite.
> > 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.”
> 
> > 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./
> 

Right.  I forgot RFC8174.  These replacements don't make sense.

Roman

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 10 Apr 2019 08:46:15 -0400

Hi,

On Wed, Apr 3, 2019, at 9:38 PM, Barry Leiba wrote:
> That said, your suggested change makes sense, and I think we should make it..

This might be obvious for IMAP server implementors, because this is a state associated with a message and once the message is gone there is no way to retrieve it.

But agree that the text can be improved here.

> This also makes sense and should be made.

Sure.

Best Regards,
Alexey

---

From: Michael Slusarz <[email-masked]>
Date: Wed, 10 Apr 2019 19:58:29 -0600 (MDT)

Roman,

Thanks for your comments.  See below:

> On April 3, 2019 at 2:23 PM Roman Danyliw via Datatracker <[email-masked]> wrote:
> 

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.

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

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

michael

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 25 Apr 2019 18:44:29 +0000

Hi Michael!

Thanks for the -04 update.  Comments below ...

> From: iesg [mailto:[email-masked]] On Behalf Of Michael Slusarz
> Sent: Wednesday, April 10, 2019 9:58 PM
> To: Roman Danyliw <[email-masked]>; Roman Danyliw via Datatracker
> <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-
> > 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.

It doesn't look like the revised text to address the retention issue made it into -04.  Furthermore, the new language in Section 9, "If stored permanently, ..." reiterates my concern. 

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

The new text addresses my concern.  Thanks.

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

Looks good.  Thank you.

Roman

---

From: Michael Slusarz <[email-masked]>
Date: Sun, 28 Apr 2019 22:28:58 -0600 (MDT)

> On April 25, 2019 at 12:44 PM Roman Danyliw <[email-masked]> wrote:
>

Guilty.  There was work being done in multiple local repositories, and some changes were not merged to the final draft.

I've addressed your concerns around permanence language in both Section 1 and Section 9, and will be pushing an updated draft in a few minutes.

michael