Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08

Michael Slusarz <> Tue, 07 July 2020 03:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C64D73A09CD for <>; Mon, 6 Jul 2020 20:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 hwzuhGT3QGTJ for <>; Mon, 6 Jul 2020 20:22:12 -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 00A023A09C9 for <>; Mon, 6 Jul 2020 20:22:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id 7F3CF6A2FF for <>; Tue, 7 Jul 2020 05:22:09 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1594092129; bh=LAe7Jr90X/zbmIO0r7tEHlQa69Wcyr7UpgN8a+h1iFw=; h=Date:From:To:In-Reply-To:References:Subject:From; b=fbWOZGY3gYKW9T4jIscoLDDJUqs47Jd7hDdQvF9RihXQ/1frYvrQOrqJueUyigHip jCrsLadn5mkDgTITzZt2Ebm0RzIMxsLFOm89eMrw5V7HEMiSO6KrfwRdluXdtXl1oh 3KLL++wDvo+Rc3HNo+CbwqW7GnJBOvvPWW/6k+1xMmUK/DEdupZdMyCve9sCi6yikz 6Nsdnk7k6lEL5NqvBTWSbQNnKIqaQL2CLxyn6Fy9nyc6Ulmf7XLKHFrpY3UWp8DEHT tPfWQKLiaoY39xcU1pc0PBE8K47KyC8CNXwkRysMI0kJc/X0mVN+Hkwzfa4DXeq3e/ YfVq/kckpg0nQ==
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6CC9D3C004B for <>; Tue, 7 Jul 2020 05:22:09 +0200 (CEST)
Date: Mon, 6 Jul 2020 21:22:08 -0600 (MDT)
From: Michael Slusarz <>
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_19547_2068058439.1594092129283"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev15
X-Originating-Client: open-xchange-appsuite
Archived-At: <>
Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08
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: Tue, 07 Jul 2020 03:22:14 -0000

>     On 07/02/2020 3:20 AM Timo Sirainen <> wrote:
>     On 2. Jul 2020, at 4.56, Bron Gondwana < > wrote:
>         > >         As discussed in the interim meeting, this document was brought back to the working group to be reverted to an earlier and simpler version.
> > 
> >         This email announces a 2 week working group last call for any further comments on this version before I re-submit to IESG for publication.  Please reply with any comments by Thursday, July 16th 2020.  Let's get this one off our plates before IETF108.
> > 
> >     > 
>        It is possible that preview text is not available now, but might be
>        available later -- perhaps the server's preview-generating resources
>        are overloaded, there is a server-imposed timeout during preview
>        generation, or there is some transient issue with fetching the
>        message body.  In such cases, the server will return NIL as the
>        preview response, and the client can try to retrieve the preview
>        later.
>     This sounds like it's possible for server to return NIL even when the LAZY modifier isn't specified. Is this really wanted? I'd think client developers would prefer that only LAZY can return NILs. Either way, it's not clearly enough specified what is intended.
I was originally going to agree with Timo ... but then I remember we added this part as a direct response to a potential DoS situation - what happens if preview requests are (subjectively) taking too much time.

If a server can't produce a preview within a certain time threshold, it should somehow be able to abort the request.  NIL might not be the best solution, but what if it empty string ("") is returned?  Then a caching client may never have preview text for that message, even though the inability to return the text may be a temporary issue.

LAZY means a server should return preview only if it is pre-generated (or can be generated without noticeable delay to user).  non-LAZY request should return PREVIEW unless it exceeds some sort of server-defined timeout.  But in the latter case - unless the server knows it can never create a PREVIEW, it does seem that NIL is the semantically correct response, at least given the current definitions.  Empty string means the server has canonically decided that no reasonable preview can be generated.

Another suggestion might be to return NO response to the FETCH ... but semantics of that are a little tortured if the rest of the FETCH request could be returned, or if preview can be returned for all but one of the messages requested in the FETCH.

In the IMAP spec we have: "The LIST command SHOULD return its data quickly, without undue delay."  Maybe adopt this language and leave it to server to figure out what is "undue delay?"  But that doesn't address whether empty string or NIL is the correct response if undue delay is reached...