Re: [Technical Errata Reported] RFC7232 (5236)

Julian Reschke <julian.reschke@gmx.de> Fri, 22 June 2018 10:40 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F48130E22 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Jun 2018 03:40:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.651
X-Spam-Level:
X-Spam-Status: No, score=-7.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 mK38QgnX7kLr for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 22 Jun 2018 03:40:25 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (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 44310130E20 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 22 Jun 2018 03:40:25 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1fWJSs-0005Z4-2I for ietf-http-wg-dist@listhub.w3.org; Fri, 22 Jun 2018 10:38:50 +0000
Resent-Date: Fri, 22 Jun 2018 10:38:50 +0000
Resent-Message-Id: <E1fWJSs-0005Z4-2I@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <julian.reschke@gmx.de>) id 1fWJSo-0005YR-SE for ietf-http-wg@listhub.w3.org; Fri, 22 Jun 2018 10:38:46 +0000
Received: from mout.gmx.net ([212.227.17.22]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <julian.reschke@gmx.de>) id 1fWJSl-0006cv-Gw for ietf-http-wg@w3.org; Fri, 22 Jun 2018 10:38:45 +0000
Received: from [192.168.1.34] ([217.91.35.233]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M51eM-1gOYCa1Qpa-00zIX2; Fri, 22 Jun 2018 12:38:02 +0200
To: Mark Nottingham <mnot@mnot.net>, Chris Pacejo <chris@pacejo.net>
Cc: Roy Fielding <fielding@gbiv.com>, RFC Errata System <rfc-editor@rfc-editor.org>, Ben Campbell <ben@nostrum.com>, Alexey Melnikov <aamelnikov@fastmail.fm>, adam@nostrum.com, pmcmanus@mozilla.com, ietf-http-wg@w3.org
References: <20180116155124.07618B81F2B@rfc-editor.org> <55475510-2367-435F-8719-77DFBACADE5C@gbiv.com> <1516134882.3375943.1237594864.4C01254F@webmail.messagingengine.com> <991B2144-B092-4CD0-B6F1-6B66E550FC5E@mnot.net>
From: Julian Reschke <julian.reschke@gmx.de>
Message-ID: <d41c5a2c-30f0-4b0f-a983-07e8335620e9@gmx.de>
Date: Fri, 22 Jun 2018 12:37:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <991B2144-B092-4CD0-B6F1-6B66E550FC5E@mnot.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:MVk7qW6RvfanFnhKK3Ijl+8vyquP2FqgnvV3SRhZGURuGmoRVy8 XankkYPaZRalkbZhkNDtVpIqDvgyMxttrXimnywxqwSUlYZ421KCIBtpU9dWUaXyoMZ0N5N t4y0FbspMkgO98iomj56FjtWjVUGJlxeaARL2notNdmRrZ+R8wxtTiPchrdMs8Z/LCvYNG9 rhsHTrUlTfmZq1LwAljRw==
X-UI-Out-Filterresults: notjunk:1;V01:K0:xxu7aXkc4Mc=:phMI8sgkeDKtQkeUOeRqj4 1NYgskdXMcNyEW3qHhV8t6mb+dWf24FQpJ8lwY/r+WLyyWvwhkVS0W0sz0B0qBNgGn4IlAvZr 9KJfK0QUmMb1bc+tuLmo3aQ/WT2A01uQ/XFEUBsSwBNSmgTKSzHyH7TFJivg+9IT9BwBVkyHa RQjCo3c1vvZMSDX7WbT+NXie1HMOLWIbo4BpeiyqlfQLQpHxpwq1V0/LlAp3oQVdO75D7Sdzv c8gp3CMLCMmAMP8Eb6s0vDM14xk9ktLTKNir2iBkbXPgAnSbJZLWEJckaFICYdbHcs3KhiNmY 2/GGHJHUJ9CpH8y6CSate/qe4R3eFpX3yUbM7gs2t8G6tb9Txk/5TNEofLYWZYhTEPIN3UJw/ ATvVnldgq87IssW3vj+3XvEMnQkNufgYA68cjBmtHo3dU6pNE6QFr4FnqOSFm1CC0qungX4KS ZhGCtjiulTud0EQMXRYVPSTb3K4uubnbjrtk2MhRzFV/u4pjMpA6ZSdpPT6haW5yejQjOaZNJ m3vFIqqDj2hR0rdz9PbTC+FiZnLnPf6YdTYdt/CGwKlRrvhX3H+YIIun3hHg06S3N0iI5j1jP wXl5TCnPpkdlW36Q681C4cLo+ZkYDxUkC9D2ACxXrkhaadY3UL8XD0OEp1SUQ+gDVwG97+ZYL RbH9YnEHSM5L53Y4xCiNsNSnzJAjP89ZMIniUI9OaUjwmDd4a2PwI+mV06Ek4f2gZondExSgI LbKyGggtLYvYZXn1dITVpgWIh9P67A2iPmUV3D8m0Ow6qat1l53itsVDO3WWGlty4yDAiv3ps XgJ+M/9
X-W3C-Hub-Spam-Status: No, score=-6.3
X-W3C-Hub-Spam-Report: AWL=-0.378, BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1fWJSl-0006cv-Gw 4b5f23dfa63d350a56b792665547924b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7232 (5236)
Archived-At: <https://www.w3.org/mid/d41c5a2c-30f0-4b0f-a983-07e8335620e9@gmx.de>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35563
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 2018-01-29 02:00, Mark Nottingham wrote:
> FWIW, I think the source of confusion here is taking this statement out of context:
> 
> """However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations."""
> 
> The complete paragraph is:
> 
> """There are a variety of strong validators used in practice. The best are based on strict revision control, wherein each change to a representation always results in a unique node name and revision identifier being assigned before the representation is made accessible to GET. A collision-resistant hash function applied to the representation data is also sufficient if the data is available prior to the response header fields being sent and the digest does not need to be recalculated every time a validation request is received. However, if a resource has distinct representations that differ only in their metadata, such as might occur with content negotiation over media types that happen to share the same data format, then the origin server needs to incorporate additional information in the validator to distinguish those representations."""
> 
> I.e., the statement is being made in the context of generating strong validators based only upon the message body, when the headers might also change.
> 
> Cheers,

So, are we in agreement that this erratum should be rejected?

Best regards, Julian