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=
- [Extra] Benjamin Kaduk's Discuss on draft-ietf-ex… Benjamin Kaduk via Datatracker
- Re: [Extra] Benjamin Kaduk's Discuss on draft-iet… Michael Slusarz
- Re: [Extra] Benjamin Kaduk's Discuss on draft-iet… Alexey Melnikov
- Re: [Extra] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Extra] Benjamin Kaduk's Discuss on draft-iet… Chris Newman
- Re: [Extra] Benjamin Kaduk's Discuss on draft-iet… Michael Slusarz