IETF Logo Mail Archive

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

Michael Slusarz <michael.slusarz@open-xchange.com> Mon, 29 April 2019 04:29 UTC

Return-Path: <michael.slusarz@open-xchange.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 938B41200B5; Sun, 28 Apr 2019 21:29:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 xo0NwjVM_Wsf; Sun, 28 Apr 2019 21:29:01 -0700 (PDT)
Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 73292120098; Sun, 28 Apr 2019 21:29:01 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 642F56A33B; Mon, 29 Apr 2019 06:28:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1556512139; bh=ghpB5QiNAEarSvC1fVw5mbCaXVtJcnY80Q9II/T7doI=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=Jj0PUu6ATM4xtoqvjNJJG8xXHtDMIYDPGks0OVHK1BVWYclN0uZ/yCcumvw819EBp cHHcdQ8cczL2jODp2GNYj4EdQnLqVX/1gvXWDn7MV3WuaITJOJZDdOqPeqXsJkSKOw fxRwq5LzBpoYD8m4cESu7yUgeKa/nw2wd91Ol97Nd3qd3e0CmrrXl4K5KjpAjphHhI TouyJWYr/4QGt2Ji6PSvNR4X4XH3zAjaOX7VymRAErXkIUnPbxRDddTuS0g62A1+g/ HOGh/FX459yaiZYc7Wrr/CsTHK684WbQ3LMKgsrC2133Mg+MgBc7vZ8z/FpOmuVKWR vny3Z8V/Y22Ng==
Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 487F33C0042; Mon, 29 Apr 2019 06:28:59 +0200 (CEST)
Date: Sun, 28 Apr 2019 22:28:58 -0600
From: Michael Slusarz <michael.slusarz@open-xchange.com>
To: Roman Danyliw <rdd@cert.org>, Michael Slusarz <michael.slusarz=40open-xchange.com@dmarc.ietf.org>, The IESG <iesg@ietf.org>
Cc: extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org
Message-ID: <1314584272.50149.1556512139210@appsuite.open-xchange.com>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B334911F@marathon>
References: <155432299793.22684.17651098563381437965.idtracker@ietfa.amsl.com> <270245125.18005.1554947909394@appsuite.open-xchange.com> <359EC4B99E040048A7131E0F4E113AFC01B334911F@marathon>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/miJu7_ZaDO4i-hlw7wdZ0iVWOI8>
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: Mon, 29 Apr 2019 04:29:06 -0000

> On April 25, 2019 at 12:44 PM Roman Danyliw <rdd@cert.org> wrote:
>
> > -----Original Message-----
> > From: iesg [mailto:iesg-bounces@ietf.org] On Behalf Of Michael Slusarz
> > Sent: Wednesday, April 10, 2019 9:58 PM
> > To: Roman Danyliw <rdd@cert.org>; Roman Danyliw via Datatracker
> > <noreply@ietf.org>; The IESG <iesg@ietf.org>
> > Cc: extra@ietf.org; brong@fastmailteam.com; extra-chairs@ietf.org; draft-
> > ietf-extra-imap-fetch-preview@ietf.org
> > Subject: Re: [Extra] Roman Danyliw's Discuss on draft-ietf-extra-imap-fetch-
> > preview-03: (with DISCUSS and COMMENT)
> > 
> > Roman,
> > 
> > Thanks for your comments.  See below:
> > 
> > > On April 3, 2019 at 2:23 PM Roman Danyliw via Datatracker
> > <noreply@ietf.org> 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.
> 
> 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. 

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

v2.23.0 | Report a Bug | By Email