Re: [Editorial Errata Reported] RFC9110 (7530)

Mark Thomas <markt@apache.org> Wed, 31 May 2023 09:42 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 9CAEFC15108B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 May 2023 02:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.646
X-Spam-Level:
X-Spam-Status: No, score=-7.646 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRNSZRFtEY3M for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 31 May 2023 02:42:28 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B26DC151522 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 31 May 2023 02:42:19 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1q4IJB-002zav-J5 for ietf-http-wg-dist@listhub.w3.org; Wed, 31 May 2023 09:39:57 +0000
Resent-Date: Wed, 31 May 2023 09:39:57 +0000
Resent-Message-Id: <E1q4IJB-002zav-J5@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <markt@apache.org>) id 1q4IJA-002za6-5l for ietf-http-wg@listhub.w3.org; Wed, 31 May 2023 09:39:56 +0000
Received: from mxout1-ec2-va.apache.org ([3.227.148.255]) by titan.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <markt@apache.org>) id 1q4IJ8-00B0u7-EN for ietf-http-wg@w3.org; Wed, 31 May 2023 09:39:55 +0000
Received: from mail.apache.org (mailroute1-lw-us.apache.org [207.244.88.153]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mxout1-ec2-va.apache.org (ASF Mail Server at mxout1-ec2-va.apache.org) with ESMTPS id 411FA4442A for <ietf-http-wg@w3.org>; Wed, 31 May 2023 09:39:49 +0000 (UTC)
Received: (qmail 2647059 invoked by uid 116); 31 May 2023 09:39:47 -0000
Received: from ec2-52-204-25-47.compute-1.amazonaws.com (HELO mailrelay1-ec2-va.apache.org) (52.204.25.47) by apache.org (qpsmtpd/0.94) with ESMTP; Wed, 31 May 2023 09:39:47 +0000
Authentication-Results: apache.org; auth=none
Received: from [192.168.23.12] (host86-157-170-31.range86-157.btcentralplus.com [86.157.170.31]) by mailrelay1-ec2-va.apache.org (ASF Mail Server at mailrelay1-ec2-va.apache.org) with ESMTPSA id 66B703EB36; Wed, 31 May 2023 09:39:46 +0000 (UTC)
Message-ID: <1651412e-db00-fb5b-b806-8674e02ed6c1@apache.org>
Date: Wed, 31 May 2023 10:39:45 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0
Content-Language: en-US
To: Julian Reschke <julian.reschke@gmx.de>, Philippe Cloutier <chealer@gmail.com>, "Roy T. Fielding" <fielding@gbiv.com>
Cc: RFC Errata System <rfc-editor@rfc-editor.org>, Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
References: <20230529214703.0DAA385293@rfcpa.amsl.com> <4D37E8D2-A2DF-4C50-9F8F-1A6E1BDEAB48@gbiv.com> <CANA_mJJEzdcD=KLLVWnfu9v_Z2-U8KwfR8Prt6g6_s_o6kT5HQ@mail.gmail.com> <78e19602-cf7e-3204-2e60-31b179fcdda8@gmx.de>
From: Mark Thomas <markt@apache.org>
In-Reply-To: <78e19602-cf7e-3204-2e60-31b179fcdda8@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass client-ip=3.227.148.255; envelope-from=markt@apache.org; helo=mxout1-ec2-va.apache.org
X-W3C-Hub-Spam-Status: No, score=-17.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, ENV_AND_HDR_SPF_MATCH=-0.5, NICE_REPLY_A=-0.091, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1q4IJ8-00B0u7-EN 6454dac32a0b9b55065ae6301ec0ce5b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [Editorial Errata Reported] RFC9110 (7530)
Archived-At: <https://www.w3.org/mid/1651412e-db00-fb5b-b806-8674e02ed6c1@apache.org>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/51131
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 30/05/2023 17:42, Julian Reschke wrote:
> On 30.05.2023 18:37, Philippe Cloutier wrote:
>> Hi Roy,
>>
>> Le mar. 30 mai 2023 à 12:01, Roy T. Fielding <fielding@gbiv.com
>> <mailto:fielding@gbiv.com>> a écrit :
>>
>>      > On May 29, 2023, at 2:47 PM, RFC Errata System
>>     <rfc-editor@rfc-editor.org <mailto:rfc-editor@rfc-editor.org>> wrote:
>>      >
>>      > The following errata report has been submitted for RFC9110,
>>      > "HTTP Semantics".
>>      >
>>      > --------------------------------------
>>      > You may review the report below and at:
>>      > https://www.rfc-editor.org/errata/eid7530
>>     <https://www.rfc-editor.org/errata/eid7530>
>>      >
>>      > --------------------------------------
>>      > Type: Editorial
>>      > Reported by: Philippe Cloutier <chealer@gmail.com
>>     <mailto:chealer@gmail.com>>
>>      >
>>      > Section: 15.5.2.
>>      >
>>      > Original Text
>>      > -------------
>>      > The 401 (Unauthorized) status code indicates that the request 
>> has not
>>      > been applied because it lacks valid authentication credentials for
>>      > the target resource.
>>      >
>>      > Corrected Text
>>      > --------------
>>      > The 401 (Unauthorized) status code indicates that the request 
>> has not
>>      > been processed because it lacks valid authentication 
>> credentials for
>>      > the target resource.
>>      >
>>      > Notes
>>      > -----
>>      > "applying a request" is not a standard expression. Usually,
>>     requests are "treated", "granted" or "processed".
>>      >
>>      > This phrasing was imported in Apache Tomcat; thanks to Mark
>>     Thomas for pointing out it came from this RFC.
>>
>>     REJECT
>>
>>     A method is applied to a resource to have an effect that results in
>>     a response.
>>     Any web search on "method applied" will show you that it is quite
>>     common in
>>     standard English.
>>
>>
>> You are right that a method can be applied. But the problematic
>> statement is about a *request*. It is perfectly valid to "apply a method
>> to process a request", for example, but that's not what the sentence 
>> says.
> 
> The method is part of the HTTP request...
> 
>>
>>     The request has already been processed, at least partially,
>>     in order to make a decision that resulted in a 401 error.
>>
>>
>> To clarify, the contents of "Corrected Text" are merely a suggestion.
>> Please don't take this as a request to change with the text I wrote, but
>> as a request to apply whatever fix is best. There are several other
>> options. I suggested "processed" since it's in line with 400, but I do
>> not disagree that returning a 401 error is some partial request 
>> processing.
>>
>>  > The 401 (Unauthorized) status code indicates that the request has not
>> been granted because it lacks valid authentication credentials for the
>> target resource.
>>
>> ...would be IMO more exact. "fulfilled" would be another option.
> 
> "granted" would be for authorization (403), but not for authentication
> (401).
> 
>>
>>     [...]
>>
>>     In any case, RFC9110 defines a lot of standard expressions.
>>
>>
>> I am sorry but I fail to understand what you are saying.
>>
>>
>>     ....Roy
> 
> Same here. Let's stick to the terminology that we've been using for
> years now.

When I read that sentence out of context (on its own as a description of 
what a 401 response means and without the rest of the RFC 9110 text) the 
use of "applied" did strike me as a little odd. When read in the context 
of RFC 9110, it is more obvious (to me at least) that the request has 
not been applied to the target resource.

How about a slight re-wording of that sentence to:

"The 401 (Unauthorized) status code indicates that the request has not 
been applied to the target resource because it lacks valid 
authentication credentials for that resource."

It arguably adds a little redundancy to the text but I think the 
additional clarity justifies that.

Mark