Re: [EXTERNAL] Re: Proposal adaptation request

My apologies! I missed the previous email.

Please ignore this one!

Guohui
________________________________
From: Guohui Deng <guohuideng@microsoft.com>
Sent: Wednesday, May 14, 2025 9:49 AM
To: Yoav Weiss <yoav.weiss@shopify.com>; Roy T. Fielding <fielding@gbiv.com>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>; Anne van Kesteren <annevk@annevk.nl>; Mark Nottingham <mnot@mnot.net>
Subject: Re: [EXTERNAL] Re: Proposal adaptation request

Hi,

Could someone let me know the answer? Is "_unknown" a value that cannot be registered too?

Cheers,
Guohui


________________________________
From: Guohui Deng <guohuideng@microsoft.com>
Sent: Monday, May 12, 2025 1:38 PM
To: Yoav Weiss <yoav.weiss@shopify.com>; Roy T. Fielding <fielding@gbiv.com>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>; Anne van Kesteren <annevk@annevk.nl>
Subject: Re: [EXTERNAL] Re: Proposal adaptation request

Hi Roy and Yoav,

Besides "_",  is there something else like "_unknown" a "non-HTTP value that cannot be registered"?

For us, "_unknown" is better than "_".  I checked "rfc8941" and I don't see any restrictions on the values in that doc. I guess it cannot be registered but I am not sure.

Cheers,
Guohui

________________________________
From: Guohui Deng <guohuideng@microsoft.com>
Sent: Thursday, May 1, 2025 11:42 AM
To: Yoav Weiss <yoav.weiss@shopify.com>; Roy T. Fielding <fielding@gbiv.com>
Cc: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Re: [EXTERNAL] Re: Proposal adaptation request

Hi,

Thanks for the discussion! I will proceed with "_" value in place of "unknown".

Warm regards,
Guohui

________________________________
From: Yoav Weiss
Sent: Tuesday, April 29, 2025 11:27 PM
To: Roy T. Fielding
Cc: Guohui Deng; ietf-http-wg@w3.org
Subject: [EXTERNAL] Re: Proposal adaptation request



On Tue, Apr 29, 2025 at 1:47 AM Roy T. Fielding <fielding@gbiv.com<mailto:fielding@gbiv.com>> wrote:
I don't think it is appropriate to restrict HTTP (reserve a bogus "unknown" content coding) just because one extension to an internal API might want to indicate a non-registered value has been received without actually storing a potential attacker-provided value.

The simplest alternative would be to store a non-HTTP value that cannot be registered (like "_").

Using "_" seems reasonable, thanks!


A more reasonable solution would be to understand that PerformanceResourceTiming is not an appropriate API for collecting encoding information. If you want to know if a fetched "resource" was decoded, then compare the two body lengths that are already stored for that purpose (encoded size and decoded size).

Determining "how" the resource was encoded is not PerformanceResourceTiming, IMO.
[An origin can determine that from the body size.]

Why?
Knowing whether a resource was encoded a certain way is critical to enable developers to detect encoding mistakes and fix them.


....Roy


On Apr 28, 2025, at 2:29 PM, Guohui Deng <guohuideng@microsoft.com<mailto:guohuideng@microsoft.com>> wrote:

Greetings!

I would like to request the doc mentioned below to be considered for adaptation.

Reason for this proposal:

A new field contentEncoding is proposed(https://github.com/whatwg/fetch/pull/1796)
 to be added to PerformanceResourceTiming(https://www.w3.org/TR/resource-timing/).
 This field explicitly exposes the content encoding value in the http response that
 delivered the resource.  This value is beneficial to web sites' and CDNs' content
 delivery optimization, analytics and debugging.

To ensure that the contentEncoding in PerformanceResourceTiming doesn't become a side
 channel, all arbitrary values that are not recognized or supported are converted to
 unknown before exposed in PerformanceResourceTiming. This conversion requires that the
 original value cannot be unknown.

Therefore, this doc proposes a new reserved value unknown for the HTTP protocol parameter
content coding.. A content coding value cannot be unknown.


Warm regards,
Guohui

________________________________
From: internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>
Sent: Friday, April 25, 2025 9:27 AM
To: Guohui Deng
Subject: [EXTERNAL] New Version Notification for draft-deng-httpbis-unknown-content-coding-00.txt


A new version of Internet-Draft
draft-deng-httpbis-unknown-content-coding-00.txt has been successfully
submitted by Guohui Deng and posted to the
IETF repository.

Name:     draft-deng-httpbis-unknown-content-coding
Revision: 00
Title:    Register a new reserved content coding value
Date:     2025-04-23
Group:    Individual Submission
Pages:    3
URL:      https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-deng-httpbis-unknown-content-coding-00.txt&data=05%7C02%7Cguohuideng%40microsoft.com%7C7736da90b9994adb7a5908dd840dc201%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638811916843736505%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2ugM6recUnsGRGd3vfA%2FHHoOoihq7AIBD6c3WCQ4p38%3D&reserved=0<https://www.ietf.org/archive/id/draft-deng-httpbis-unknown-content-coding-00.txt>
Status:   https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-deng-httpbis-unknown-content-coding%2F&data=05%7C02%7Cguohuideng%40microsoft.com%7C7736da90b9994adb7a5908dd840dc201%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638811916843760376%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3SIKAZtPIUWyxYNFCWf6V3WYDp%2BNA%2FcK0jMWdVR7sEc%3D&reserved=0<https://datatracker.ietf.org/doc/draft-deng-httpbis-unknown-content-coding/>
HTMLized: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-deng-httpbis-unknown-content-coding&data=05%7C02%7Cguohuideng%40microsoft.com%7C7736da90b9994adb7a5908dd840dc201%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638811916843773997%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LvWphsxMZKfSWk5qqvAwAsg8yStFfCtiBW0JPM953XE%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-deng-httpbis-unknown-content-coding>


Abstract:

   This document proposes a new reserved value unknown for the HTTP
   protocol parameter content coding.



The IETF Secretariat