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

Michael Slusarz <michael.slusarz@open-xchange.com> Wed, 15 July 2020 03: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 D3DA53A0E0C for <extra@ietfa.amsl.com>; Tue, 14 Jul 2020 20:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: 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 0aLwG7d_916Y for <extra@ietfa.amsl.com>; Tue, 14 Jul 2020 20:29:37 -0700 (PDT)
Received: from mx3.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 750293A0E09 for <extra@ietf.org>; Tue, 14 Jul 2020 20:29:37 -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)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id AD6E36A312 for <extra@ietf.org>; Wed, 15 Jul 2020 05:29:33 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1594783773; bh=2+GhpZ6F5xL8bIhfDT4EUykfhKnMLMwHW/6DbINy3pI=; h=Date:From:To:In-Reply-To:References:Subject:From; b=g+DdybiBqceDena9uJzBgjorypuBkbdXBCMPd47R0+OSrlsmbYvLP2gs1TM6HRMrU J8fsm+ruBEwUm05n7XeJnb0BLM2cWQIea1l921O5dimhZAyK9fxAYROMCehIR8NtED d7F2N3a+IysMs1re/979fMPdRSY26twu/MUqCvM7BzFOKGLUeZUbIdyWb1U2Xsh3pn UV92gXE4CnxcUa5jqF9o+/7ovyLlmMTKEpK0HNt/6RAe7UJHnRrFQx+xc5kamcsm8V 6T6xBVR6uiclQer3Kk4j8EqF4Dw77Ws2QIx7shYELpBvT8+Vv+01Njf+LtLuknOEvM ueBWEfzm1ChSA==
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 9ED283C02B0 for <extra@ietf.org>; Wed, 15 Jul 2020 05:29:33 +0200 (CEST)
Date: Tue, 14 Jul 2020 21:29:33 -0600 (MDT)
From: Michael Slusarz <michael.slusarz@open-xchange.com>
To: extra@ietf.org
Message-ID: <381786159.2271.1594783773523@appsuite.open-xchange.com>
In-Reply-To: <c531ac34-00fd-455e-a0a0-5d3f3b51a038@dogfood.fastmail.com>
References: <c4da8962-ec81-4ee5-b2e1-258d5b247770@dogfood.fastmail.com> <E7CA280C-D1B9-4BE7-8109-E070CF742623@sirainen.com> <1948688035.19548.1594092129291@appsuite.open-xchange.com> <388F9721-0CB5-4146-AC23-503C4481A090@sirainen.com> <c531ac34-00fd-455e-a0a0-5d3f3b51a038@dogfood.fastmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2270_1403645970.1594783773511"
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.3-Rev17
X-Originating-Client: open-xchange-appsuite
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/Lug4f5AdTgefbAZcxSmFl4eFrtk>
Subject: Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08
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, 15 Jul 2020 03:29:40 -0000

It seems I was a day late to submit, as submissions are paused before the meeting...

I've finished the -09 draft.  If interested, I could post a copy.  Otherwise, I will just submit at end of the month when submission tool is reopened.

Changes in -09:
* PREVIEW without LAZY MUST NOT return NIL (kept it simple)
* Rewrote the LAZY modifier section a bit to break apart the semantics of LAZY from "Client Implementation Advice".  The latter is a combo of some of the text previously in the section with list recommendations.  Slightly tweaked Example 2 to request two previews in a single FETCH request in background.
Decided to make no mention of NO response in this document.  After discussion here, it seems like that is expected to be an extremely rare case - and that case is already adequately handled by FETCH command definition in base IMAP spec.

michael


>     On 07/07/2020 5:00 AM Bron Gondwana <brong@fastmailteam.com> wrote:
>      
>      
>     On Tue, Jul 7, 2020, at 18:54, Timo Sirainen wrote:
> 
>         > >         On 7. Jul 2020, at 6.22, Michael Slusarz <michael.slusarz=40open-xchange.com@dmarc.ietf.org mailto:michael.slusarz=40open-xchange.com@dmarc.ietf.org > wrote:
> > 
> >             > > >              
> > > 
> > >                 > > > >                 On 07/02/2020 3:20 AM Timo Sirainen <timo@sirainen.com mailto:timo@sirainen.com > wrote:
> > > >                  
> > > >                  
> > > >                 On 2. Jul 2020, at 4.56, Bron Gondwana < brong@fastmailteam.com mailto:brong@fastmailteam.com > 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.
> > > 
> > >         > >          
> >         I don't really see why this would be an issue. IMAP protocol doesn't have this kind of a special "DoS-prevention feature" anywhere else. Especially now that the preview is always text, I don't think it can be excessively slow to generate it. At least in Dovecot's implementation it's basically as expensive as fetching BODYSTRUCTURE, and we don't have DoS prevention against fetching those. Maybe in theory if server wanted to analyze attachments in some way .. but is it really worth the added complexity for a problem that probably will remain theoretical?
> >          
> >         FETCH is also good in that it returns the results after each mail. So the server is allowed to start throttling the responses to the client without actually failing it.
> > 
> >     >      
>     You're right.  Here we are overcomplexing it again!
>      
>     Server MUST NOT return NIL to a non-lazy preview is fine by me.
>      
>     Server SHOULD NOT return NIL is fine by me as well, along with clients SHOULD NOT cache a NIL response.  Either way our server is always going to have one because it gets calculated on APPEND.
>      
>     Bron.
>      
>      
>     --
>       Bron Gondwana, CEO, Fastmail Pty Ltd
>       brong@fastmailteam.com
>      
>      
>     _______________________________________________
>     Extra mailing list
>     Extra@ietf.org
>     https://www.ietf.org/mailman/listinfo/extra
>