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

"Chris Newman" <chris.newman@oracle.com> Thu, 11 April 2019 23:34 UTC

Return-Path: <chris.newman@oracle.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 5272012034E; Thu, 11 Apr 2019 16:34:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, 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=oracle.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 8sx7tbPJy9FR; Thu, 11 Apr 2019 16:34:37 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 0F97D1200FF; Thu, 11 Apr 2019 16:34:37 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3BNUREa121630; Thu, 11 Apr 2019 23:34:31 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=QXTi4ibgoohry+6xz8ZEaHb1c7uDWtBPiHdMvcBOowQ=; b=c7tzuwx5zlm5fU35atzXmWm72Ce5jsF0w4I3jMXeSZSjRES7o5Rycz5BvLd63vKOpYed RtpeHHgmPbyFm2Nrnb1KOMVCJb4Ys5rGC/5fGiU0k/MV540uD8tj9YGsPmqZy/IZztUw 3FcgaiwwjJyNcQWyDwhjPnq1mE6I5mrge/Fx2ioNXcqjDINgOY4ypYhpJavRpmD134em OjuPy9X6NGWllTA0udDJZ7oL0Q1a1zuqMKn8mkiZEHve8AsM7fANZWSVpFSFNu55g0jG LbH7BVtLOPqThI8dQms/OhLL6avfqbuOmLWbKyMA+HoQVdQ8PM5qapBmEX+OkBMx21+N QA==
Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2rpkhtbs2t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Apr 2019 23:34:31 +0000
Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x3BNXhju104509; Thu, 11 Apr 2019 23:34:30 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserp3020.oracle.com with ESMTP id 2rpytd26st-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Apr 2019 23:34:30 +0000
Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x3BNYThq003704; Thu, 11 Apr 2019 23:34:29 GMT
Received: from [192.168.56.1] (/166.154.192.86) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 11 Apr 2019 16:34:29 -0700
From: "Chris Newman" <chris.newman@oracle.com>
To: "Michael Slusarz" <michael.slusarz=40open-xchange.com@dmarc.ietf.org>
Cc: "Benjamin Kaduk" <kaduk@mit.edu>, "Benjamin Kaduk via Datatracker" <noreply@ietf.org>, "The IESG" <iesg@ietf.org>, extra@ietf.org, brong@fastmailteam.com, extra-chairs@ietf.org, draft-ietf-extra-imap-fetch-preview@ietf.org
Date: Thu, 11 Apr 2019 16:34:23 -0700
X-Mailer: MailMate (1.12.4r5594)
Message-ID: <2CEEDFCA-72F6-46B1-BB4F-5585E003F57B@oracle.com>
In-Reply-To: <200085968.18013.1554949931366@appsuite.open-xchange.com>
References: <155449831312.10103.6827275120612153265.idtracker@ietfa.amsl.com> <200085968.18013.1554949931366@appsuite.open-xchange.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9224 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110151
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9224 signatures=668685
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904110151
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/5KhbHg_aLlORkPxUvh5bWYvQP94>
Subject: Re: [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
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: Thu, 11 Apr 2019 23:34:38 -0000

On 10 Apr 2019, at 19:32, Michael Slusarz wrote:
> Benjamin,
>
> Thank you for the comments.  Disccusion below:
>
>> On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker 
>> <noreply@ietf.org> wrote:
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> 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?

As a server implementor, I think that's a good proposal to resolve this 
issue.

		- Chris

> (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.)
>
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> 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).
>
> michael
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=_6NkoEgIENsYMaNoSASPfK2B1zYYYPt9O1NJVWklBGw&s=YRIPXtCQVIlTe3Fk5OkDQMENKX5db8JeL5XXhi7DfAU&e=