IETF Logo Mail Archive

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

Roman Danyliw <rdd@cert.org> Wed, 03 April 2019 20:46 UTC

Return-Path: <rdd@cert.org>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB1AF120242; Wed, 3 Apr 2019 13:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51N7YAYB8OD3; Wed, 3 Apr 2019 13:46:23 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D31912023F; Wed, 3 Apr 2019 13:46:23 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x33KkI7m048913; Wed, 3 Apr 2019 16:46:18 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x33KkI7m048913
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1554324379; bh=iihckUTB04XUpnrym0nn/sgJR3BLIjPRvxspyOn38oI=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=VfNq3jLuNejxV2qg7AK5OlVwU4jQP6cWDbC/CK3EeqvS7qEbsXIBX/GJkAcyH27q5 r0vCcBuwXa1gfsJ353Em92ckYtKaHXr6CZlPwAuayImLCTm4SbFNsjL/oGJAro/ucS myxV7/XH5uYTQyv7umIFsibxhBoladzmuOCsL9MM=
Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x33KkEsu019561; Wed, 3 Apr 2019 16:46:14 -0400
Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASSINA.ad.sei.cmu.edu ([10.64.28.249]) with mapi id 14.03.0435.000; Wed, 3 Apr 2019 16:46:13 -0400
From: Roman Danyliw <rdd@cert.org>
To: Barry Leiba <barryleiba@computer.org>
CC: The IESG <iesg@ietf.org>, "extra@ietf.org" <extra@ietf.org>, Bron Gondwana <brong@fastmailteam.com>, "extra-chairs@ietf.org" <extra-chairs@ietf.org>, "draft-ietf-extra-imap-fetch-preview@ietf.org" <draft-ietf-extra-imap-fetch-preview@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
Thread-Index: AQHU6lsdU9pkh6o9mkWEzi03EGhTD6YrKIuA//++u7A=
Date: Wed, 03 Apr 2019 20:46:12 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B331BA30@marchand>
References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> <CALaySJL38DPqcSuB=SCnvDM6LN9C6GVoNCYd+fnpwR1qmscxBg@mail.gmail.com>
In-Reply-To: <CALaySJL38DPqcSuB=SCnvDM6LN9C6GVoNCYd+fnpwR1qmscxBg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/FN1pfA8IxAZH42IReS8DYYnD6ig>
Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 20:46:26 -0000


> -----Original Message-----
> From: Barry Leiba [mailto:barryleiba@computer.org]
> Sent: Wednesday, April 03, 2019 4:38 PM
> To: Roman Danyliw <rdd@cert.org>
> Cc: The IESG <iesg@ietf.org>; extra@ietf.org; Bron Gondwana
> <brong@fastmailteam.com>; extra-chairs@ietf.org; draft-ietf-extra-imap-
> fetch-preview@ietf.org
> 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.
> That said, your suggested change makes sense, and I think we should make
> it.
> 
> > (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.”
> 
> This also makes sense and should be made.
> 
> > (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./
> 
> These are both applications of RFC 8174 and should stand as they are written.

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

Roman

> Barry

v2.23.0 | Report a Bug | By Email