Re: [Technical Errata Reported] RFC7232 (5236)

Chris Pacejo <chris@pacejo.net> Wed, 17 January 2018 07:57 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 1D8D1124B18 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Jan 2018 23:57:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.661
X-Spam-Level:
X-Spam-Status: No, score=-6.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ApsdL7talFUA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 16 Jan 2018 23:57:43 -0800 (PST)
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 C38D51252BA for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 16 Jan 2018 23:57:43 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ebiYr-0005RC-6Q for ietf-http-wg-dist@listhub.w3.org; Wed, 17 Jan 2018 07:55:05 +0000
Resent-Message-Id: <E1ebiYr-0005RC-6Q@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1ebiYk-0003xu-CI for ietf-http-wg@listhub.w3.org; Wed, 17 Jan 2018 07:54:58 +0000
Received: from raoul.w3.org ([128.30.52.128]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <ylafon@w3.org>) id 1ebiYi-0004Cx-4R for ietf-http-wg@w3.org; Wed, 17 Jan 2018 07:54:58 +0000
Received: from platy.fdn.fr ([80.67.176.7] helo=[192.168.1.37]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <ylafon@w3.org>) id 1ebiYh-0005TM-Rk for ietf-http-wg@w3.org; Wed, 17 Jan 2018 07:54:56 +0000
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Content-Type: text/plain; charset="us-ascii"
From: Chris Pacejo <chris@pacejo.net>
In-Reply-To: <55475510-2367-435F-8719-77DFBACADE5C@gbiv.com>
Resent-From: Yves Lafon <ylafon@w3.org>
Date: Tue, 16 Jan 2018 20:35:11 +0000
Cc: Julian Reschke <julian.reschke@greenbytes.de>, ben@nostrum.com, aamelnikov@fastmail.fm, adam@nostrum.com, Mark Nottingham <mnot@mnot.net>, pmcmanus@mozilla.com, ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Resent-Date: Wed, 17 Jan 2018 08:54:53 +0100
Message-Id: <1516134882.3375943.1237594864.4C01254F@webmail.messagingengine.com>
Resent-To: HTTP Working Group <ietf-http-wg@w3.org>
References: <20180116155124.07618B81F2B@rfc-editor.org> <55475510-2367-435F-8719-77DFBACADE5C@gbiv.com>
X-Name-Md5: efe3dad792d606410c9cc49cedaffc94
To: "Roy T. Fielding" <fielding@gbiv.com>, RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3445.5.20)
X-W3C-Hub-Spam-Status: No, score=-2.2
X-W3C-Hub-Spam-Report: ALL_TRUSTED=-1, BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, T_RP_MATCHES_RCVD=-0.01, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1ebiYi-0004Cx-4R 02127a2072b8f8c5f2e8727d7a5c4551
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Technical Errata Reported] RFC7232 (5236)
Archived-At: <https://www.w3.org/mid/1516134882.3375943.1237594864.4C01254F@webmail.messagingengine.com>
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/35018
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>

Hi Roy and Julian, thanks for the replies.

On Tue, Jan 16, 2018, at 2:33 PM, Roy T. Fielding wrote:
> The Original Text is about weak validators, which don't even require that
> the content be the same. The two do not conflict.  The suggested change
> would be incorrect.

The specific text which confuses me, from the section on weak validators, is (emphasis mine):

"However, two simultaneous representations might share the same *strong* validator if they differ only in the representation metadata, such as when two different media types are available for the same representation data."

Am I misunderstanding that this is in conflict with the example you gave?  (text/plain and application/json representations with same octets must have different strong validators.)

Similarly:

"Likewise, a validator is weak if it is shared by two or more representations of a given resource at the same time, unless those representations have identical representation data."

The "unless" clause would appear to apply to the example you gave, implying that both representations can have the same validator but need not be weak.

Thanks, Chris