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

Barry Leiba <barryleiba@computer.org> Wed, 03 April 2019 20:38 UTC

Return-Path: <barryleiba@gmail.com>
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 A982A1201F1; Wed, 3 Apr 2019 13:38:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
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 IGhg-3okBvJ6; Wed, 3 Apr 2019 13:38:01 -0700 (PDT)
Received: from mail-it1-f171.google.com (mail-it1-f171.google.com [209.85.166.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36AEC1201AC; Wed, 3 Apr 2019 13:38:01 -0700 (PDT)
Received: by mail-it1-f171.google.com with SMTP id z126so94676itd.5; Wed, 03 Apr 2019 13:38:01 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=RjcYaBV1sPxxSYy9tVpuRxRvJcsKF7hvfqIKcgmJOHM=; b=Kq0+ixYQsHGorJ4Dr+WQXl9uih9rMlgr5H36hGiUFq4OURe/Hpl4sn4maMM5XJ5YFl 6CKv9kNseLMi69C3Pc4IuN9Z5Ek+prq/7+GoM8bvkjD9pkJrRGh7VAZebTaZBTQZo3dt xAgarQ01FML5uR2mhkxQJiJGLQXCdEu6/VfHsCMX/+NUXob+Rby9qqNYqAkMltGB/n/1 qeruDQBmFCIn6yw/MPzTf0Z5650eEXpfcYdSH5AWOe1GZFEOY2vxAdvIOgrY/ORJUdUj wbGIWa1UtZGOgQBOKgdo1/kf0X6obcf2CedJbhnIFK6YNFBcVYU7uGl6oXFzcnulxwJk 2UNA==
X-Gm-Message-State: APjAAAV2ZuNlgkc/dvQjCMu/KF6D1hy/TtRKNG6QgIAIBVcgSKt9DVmm w5uRjAK7+aZ1D/qY8LyublschoYegP+lgkt+c50=
X-Google-Smtp-Source: APXvYqy7zcFMFE9mYzW71MfL58XCyatFMMomH1F6MP8aqNJicWPfwoxIvCIRjlsr5nK2Tk998CYR3lw8njcVf2gDwIA=
X-Received: by 2002:a24:4d12:: with SMTP id l18mr1745539itb.66.1554323880182; Wed, 03 Apr 2019 13:38:00 -0700 (PDT)
MIME-Version: 1.0
References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com>
In-Reply-To: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com>
From: Barry Leiba <barryleiba@computer.org>
Date: Wed, 03 Apr 2019 16:37:49 -0400
Message-ID: <CALaySJL38DPqcSuB=SCnvDM6LN9C6GVoNCYd+fnpwR1qmscxBg@mail.gmail.com>
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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/u5bP9JrZRsiGiawbq9SfQkUvDqQ>
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:38:03 -0000

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.

Barry