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

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 05 April 2019 21:05 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: extra@ietf.org
Delivered-To: extra@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B20120620; Fri, 5 Apr 2019 14:05:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-extra-imap-fetch-preview@ietf.org, Bron Gondwana <brong@fastmailteam.com>, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com>
Date: Fri, 05 Apr 2019 14:05:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/zAzsGXNXURJDTCXPIASchVmNASk>
Subject: [Extra] Benjamin Kaduk'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
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: Fri, 05 Apr 2019 21:05:14 -0000

Benjamin Kaduk 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:


I wavered a lot about whether this was DISCUSS-worthy, but it seems like
we should at least talk about how big a risk for future confusion there

I'm a little confused by the ABNF for 'capability' in Section 7 -- it
seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and
Section 3.1 talk only about *algorithms* in PREVIEW capability responses
(and not modifiers).  Is the intent to have capability tags for
(non-mandatory) priority modifiers?


Section 3.1

   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 algorithms MUST be one

nit: there's potential for misparsing here (e.g., that the PREVIEW
attribute contains the name of the algorithm and the parenthesized list
is after that), so maybe put "after the PREVIEW attribte" in parentheses
or offset by commas.

   of the algorithms identified as supported in the PREVIEW capability
   responses.  [...]

nit: singular/plural mismatch between "these algorithms" and "one of".

Section 7

How much discussion was there about "SHOULD be registered" (as opposed
to "MUST be registered")?

Section 8

side note: This is one of the shortest IANA considerations sections I've
seen thta creates registries (in that it doesn't lay out a registration
template), but IANA seems to be saying they have what information they
need, so who am I to complain...

Section 9

I agree with Roman that there should be discussion of the caching/data
retention strategy for message previews.

This existing text about denial-of-service attacks is probably fine,
though I might consider rephrasing it along the lines of "this mechanism
introduces a new way for clients to make requests that consume server
resources.  As is the case for all such mechanisms, it could be used as
part of a denial-of-service attack on server resources, e.g., via
excessive memory or CPU usage, or increased storage if preview results
are cached on the server after generation.  The additional attack
surface presented by this specific mechanism is not believed to higher
risk that other similar mechanisms in use already, since the individual
resource consumption per message processed is likely to be modest.
Nonetheless, servers MAY limit the resources consumed by preview

As I write the above, though, I wonder how this interacts with the
previous text in Section 3.1 about how the "server MUST honor a client's
algorithm priority decision".  Does that mean that if some future
(expensive) algorithm is specified, once a server implements that
algorithm, any client can force its use and thus the expensive resource
consumption on the server?  It's not entirely clear to me how this MAY
interacts with that MUST, in such a hypothetical scenario.