Re: [EXTERNAL] Proposal adaptation request

Thanks Roy! I will proceed with "_". Really appreciate the detailed information and your guidance.

Guohui

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

On May 12, 2025, at 12:38 PM, Guohui Deng <guohuideng@microsoft.com> wrote:

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

"_" could theoretically be registered by IETF consensus. It seems unlikely given that nothing "short" is ever registered by consensus. The content-coding grammar is a token


  token          = 1*tchar

  tchar          = "!" / "#" / "$" / "%" / "&" / "'" / "*"
                 / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~"
                 / DIGIT / ALPHA
                 ; any VCHAR, except delimiters

The nice thing about "_" is that quite a few dead bodies would have to be crossed for that to be registered, and yet it still remains syntactically valid as a token (in case that matters), is easy to check, and looks good.

But, as I said before, it is not an IETF concern so long as it remains inside the API as a non-protocol marker.
If the API allows Unicode, "💩" would also be fine (and even less likely to be a conflict).

....Roy