Re: [Gen-art] Genart last call review of draft-ietf-httpbis-cache-16

Mark Nottingham <mnot@mnot.net> Mon, 31 May 2021 02:07 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E13A1EAD; Sun, 30 May 2021 19:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=mnot.net header.b=psT1e0ub; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RMqLSoCO
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 RWXQ6YOm6UOA; Sun, 30 May 2021 19:07:26 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812463A1E13; Sun, 30 May 2021 19:07:22 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 1873F5C00D6; Sun, 30 May 2021 22:07:20 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 30 May 2021 22:07:20 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=p 1/93I6pGGidaLdaGk8CSKchMWWUP/QUF6GooUqQFv8=; b=psT1e0ub0JZkopmDj SBcwfkst47b5eoLDVQVF+XOJ2dPiD6wZiDOy8dfJjqD5xiK4B0muRDD8A7ZOjr88 skPMyJXTtequxDnjDSYxQHopW5wgrTNlvodXqoWQf0DTAPD2Yh/wTOOmQnPqLngE /KJsDXcAieHYLpABy72zNqcSmbS+397o+A3LJMlMSTFngg8dMuwJLxbxVCJ4n+d7 vSJ4LXzXXNm65FX0g8NJExfykS1ocxt96gWWIVDdqGENmedni7QK8PLn9hPNCXMC HWu6ME7iH1irBxKIP/OGkGT05+s4Pik26o58ZKlOKQlyYDJMng+d+XjgqoWXwiS0 bXKQg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=p1/93I6pGGidaLdaGk8CSKchMWWUP/QUF6GooUqQF v8=; b=RMqLSoCOotR0HaG2ZBFpA7aDaFin+k676gFXsLiYe7sIe7RdCvRy/Ivcv ytpg7cTU4/vekIM198FnwtET5sTR25wzRKRyKiwybZwBbpiaRmF4DC8YedWr+u/j WwJuGZY+TL4Idl4CodDZuyHLcuQ7RNLP0oIctVQj5tvaLuIfEXGh9i728SsGoVQQ aDp0Y+DYDuca5T6+sR4/5Z26vhTYIF0EJqpKVUWdqkKtsazGB3eFhPx+yl6oPqsV 5yhMvRXAdo9jqovJMhQynYjRCTRihSBfmlHichCDMSG12FGHAzLrwk9BelgHtKok 6luYagZen+7ieO3nsFgLGRCNTStEg==
X-ME-Sender: <xms:1US0YOtSz3HtmUxB5O56Qopin_OCgEQ9-4v3hZ7O6B6Nps53R9GspA> <xme:1US0YDeMXzz_f4D7ClCm3OnUz63x2p5t9k1W-PnF5xFZc8zcT6T_MmFwJjNDjBwgg aLCtv5_1Jmx-ibCIw>
X-ME-Received: <xmr:1US0YJx1vHixaCEKclzNK4P5_AE-k0WZRnZi4FFhRCe-0j1cVDyX85Ypa2uxemAP8 trXbwLD9hYRYuSa8wYVurS7fWQps6U7prU21gUrayjaLEyWyFZ2VYoqo1jFzHaszw8e0n3 pdMU8B_FYpIE9zQklmZnjRplqFzDp3Od2bd8NvmKQXzQQmL7Pa7JO2KwEQhaSHcEN8Ci9h ghfA4RdKhtAGpQYQsqki7uB1lxFt9MxcGc-cmcNstOEHw>
X-ME-Received: <xmr:1US0YJOnm7KnizeHDxkkRIN9LUwfHIev6GhNZMIkQXjtvuG67zoXgF4VvnJtxHcmhkGfQWk0zIG0jz54vjnjZJbzAhcGTXj4H5eLYT6fKpq0g1V3dmBBVv3e>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelvddgheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpefgleeiffevgfdthefhffdvvdekueelvddujeekjeejfeeuleeggeefffdtleek leenucffohhmrghinhephhhtthhpfhhivghlughnrghmvghrvghgihhsthhrhidrihhtpd hgihhthhhusgdrtghomhdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth
X-ME-Proxy: <xmx:1US0YO8vnBYdNgSH-r4kNfuplYZL2CbEkxto9NE_Rt8jUC9kef0l6Q> <xmx:1US0YBW_y-YRd_WrsSZk7MNmueiULNtQ6D8R0pbGdRx3ERmaqGgcKg> <xmx:1US0YHfLZiJKvJzQf8Hs9umY7qMwlarBtTax7k5np7c0DJDdjtfrqA> <xmx:2ES0YDOSsC5zgo1SaKLDU9ZKIefPH2F2eGgpb2tVCuVMsmEYX0iTiw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 30 May 2021 22:07:15 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <162238407309.22812.14001073203740035939@ietfa.amsl.com>
Date: Mon, 31 May 2021 12:07:13 +1000
Cc: gen-art@ietf.org, draft-ietf-httpbis-cache.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FF6DC9E-1A66-4F75-92FD-0305E15342C3@mnot.net>
References: <162238407309.22812.14001073203740035939@ietfa.amsl.com>
To: Mohit Sethi <mohit.m.sethi@ericsson.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ZH9odeiOYb0bucKa3eL6gc0FGeI>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-httpbis-cache-16
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 May 2021 02:07:33 -0000

Hi Mohit,

Thanks for the review. Responses below.

> On 31 May 2021, at 12:14 am, Mohit Sethi via Datatracker <noreply@ietf.org> wrote:

> - In the HTML version of the draft, the reference to [Semantics] does not work
> properly. I looked at the xml source which looks fine. I suspect it is
> something to do with the tooling.

Julian has covered this, I think.

> - It is not clear to me which draft is creating the "Hypertext Transfer
> Protocol (HTTP) Field Name Registry". It seems both this draft and
> draft-ietf-httpbis-semantics are creating it? Perhaps you could remove the text
> in this draft saying "introduce the new" and just ask IANA to update the
> registry with fields in Table 1 of this draft.

That text includes a reference to the Semantics text creating the registry, so I think it's clear which is doing the work. It's important to mention this because it's a fairly substantial change from IANA's standpoint.

> Nits/editorial comments:
> 
> - Section 1: When does a client or server act as "tunnel"? I don't know if it
> is absolutely necessary to explain the term. You can decide.

This is defined in Semantics; I've added a reference in https://github.com/httpwg/http-core/commit/ee8c9306972

> - Section 1: HTTP caching's goal is significantly improving performance -> HTTP
> caching's goal is to significantly improve performance?

That introduces a split infinitive.

> - Section 1.3: Maybe it is obvious to many readers, but I was not sure what is
> meant by a "canned string"?

Fixed in https://github.com/httpwg/http-core/commit/51bfc119585

> - Section 3 vs Section 4: "A cache MUST NOT store a response to a request
> unless:" does not have a comma before unless while "When presented with a
> request, a cache MUST NOT reuse a stored response, unless:" has a comma before
> unless?

https://github.com/httpwg/http-core/commit/da887ff5

> - Some of the bullets in section 3 and 4 were hard to parse. Take for example:
> "When presented with a request, a cache MUST NOT reuse a stored response,
> unless: the stored response does not contain the no-cache cache directive
> (Section 5.2.2.4), unless it is successfully validated (Section 4.3), and". I
> am not sure how to simplify the text on all these requirements.

We've struggled with how to clearly state these requirements for some time now; the feedback we've received during and since RFC7234 indicates that this format is preferred. That said, the specific phrasing is undoubtedly not perfect, and we're open to suggestions for improvements.

Cheers and thanks again,


--
Mark Nottingham   https://www.mnot.net/