-
```bikeshed
Title: Your Spec Title
Shortname: your-spec
Level: 1
Status: w3c/UD
Group: WGNAMEORWHATEVER
Repository: org/repo-name
URL: http://example.com/url-this-spec-will-live-at
Editor: Y…
-
Hi everyone!
As we (Akamai) are rolling out support for Client Hints, we're exploring some of the edge cases around the spec and current Chromium implementation to make sure our infrastructure beha…
-
STD63 (as opposed to RFC3629) does not have a DOI; it IMHO should be removed. (Apparently this was done in AUTH48 for 8941).
-
Should we define a header that can carry problem details?
E.g., for the first example in the spec:
~~~ json
{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have e…
-
This issue is a result of the PING review requested here: https://github.com/w3cping/privacy-request/issues/94
This is not a privacy-sensitive issue, but a question (and request) that came up durin…
-
§7 Using Access Tokens: Editor's note:
I don't actually like the idea of using only one header type for differently-bound access tokens. Perhaps instead these values should somehow reflect the key…
-
`Attribution-Reporting-Register-Source` sends JSON as value but it's better to use Structured Field Values instead, since it standardized for replace JSON in header field values.
https://www.rfc-ed…
-
IMHO we need to be clear what the requirements of SF support are. The way the spec currently is written (referencing RFC 8941) means that SF-shaped field values using the new sf-date format are not su…
-
The spec currently states: `The title and detail values MUST NOT be serialized in the Problem field if they contain characters that are not allowed by String; see {{Section 3.3.3 of STRUCTURED-FIELDS}…
-
cow_http_struct_hd:parse_dictionary/1 does detect tokens when they start with an `APLHA`, e.g.:
```
> cow_http_struct_hd:parse_dictionary().
[{,{item,{token,},[]}}]
```
However, according to…