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

Michael Slusarz <> Thu, 11 April 2019 02:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4837120119; Wed, 10 Apr 2019 19:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.3
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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LoPZHWdGpSBM; Wed, 10 Apr 2019 19:32:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 040E51200B2; Wed, 10 Apr 2019 19:32:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 819A96A25F; Thu, 11 Apr 2019 04:32:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1554949931; bh=oxTSErv1TeEdBIDOrNCgCuwg+13uYBjkN4fX3bcJkC8=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=SPqC1yGCCTjv/u2UxZfone+2FGLJjMWBqwrFQ1I6wqXw4bcAyskaqepbhHbj3ffWp kOAmRiFRmWgkfiEafdB51lAMxrYrCQlKgrE++oDI1J/N5ZnO1gKk5d7WTpyjYFDbVW CwlIKOpBcmgzRa9iXXn1WUjCwsxWL/g4L3vddxV0HaZybJViZ8fCupm5NJaw9ro30m bSFAnV9AUIdPV+ZITTGxkzoHV5OB4vpxvk38zqe0UuRs5yia5wRSI0ORCREdSrkzRP zb8x6dR5x4HP0wpAMkKHSsFT4Dt1lJ/gszyjISQ3QBglvQbozAqle5qlDMEcj4MXpQ UvXeEQ4tgwkJg==
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6CD4B3C0066; Thu, 11 Apr 2019 04:32:11 +0200 (CEST)
Date: Wed, 10 Apr 2019 20:32:11 -0600 (MDT)
From: Michael Slusarz <>
To: Benjamin Kaduk <>, Benjamin Kaduk via Datatracker <>, The IESG <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Medium
X-Mailer: Open-Xchange Mailer v7.10.1-Rev10
X-Originating-Client: open-xchange-appsuite
Archived-At: <>
Subject: Re: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Apr 2019 02:32:17 -0000


Thank you for the comments.  Disccusion below:

> On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker <> wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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
> is:
> 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?

[Edit: looks like this was discussion item moved to Barry's ballot, but I'll leave the discussion here for clarity in the thread history]

I struggled with the decision to include priority modifier extensions in the draft.

Algorithm extensions make sense, as there can be competing or expanded way of generating preview text in the future.  But priority modifiers are tied to the behavior of the command, not the output of the command.  In the case there would be a need for a priority modifier in the future, that's a fundamental change to the semantics of the command itself and would probably require extensive discussion.

Under further thought and review, I would be perfectly fine with removing the extension/registry for priority modifiers and simply making it an explicit part of the base command.  This would simplify the draft a bit.  Thoughts?

(To answer your original DISCUSS: a separate CAPABILITY string wasn't defined, because it is implicit in PREVIEW=FUZZY, which is required to implement PREVIEW, that LAZY must also be handled.  Not requiring PREVIEW=LAZY, and not defining what a potential capability would look like in the future, were explicit choices.)

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

Alexey and I discussed in a previous thread, located here:

I think a valid summation is that Alexy was pushing hard for MUST register, but my reading of 6648 is that it allows flexibility in allowing extensions, as long as you follow naming conventions.

My personal example is that there is at least one additional PREVIEW extension we may develop, and which may be implemented quickly, but there is no intention to register that extension (at least at the beginning) because it is a very specific use-case that may not be generally useful to the wider Internet.  So demanding a MUST register to me seems unduly harsh and inflexible.

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

As mentioned in response to Roman, I worked on this language last week and I will share with the group once I have access to that revision.

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

I don't see this as any different of a problem than with other IMAP commands.  Example: a user issues a SORT/THREAD command in a large mailbox, and that command would require 10,000s of message accesses to return.  An IMAP server should be allowed to abort the response somehow (we will return an unsorted list, for example), subject to some kind of resource limitations, even though the requirements of the command is that it must return a sorted list.

More broadly, any IMAP command should be subject to this kind of truncation if there is concern that completion risks resource starvation as a consequence.  (On that note, I thought there was some sort of "resource limitation" response code defined for this kind of situation, e.g. in RFC 5530, but it looks like there isn't.  Maybe we need something like this).