Considered, not adopted

RFC 9211 defines a single response header, Cache-Status, that lets every cache on the path say what it did with a request: whether it was a hit, why it was forwarded, how much freshness is left, whether the response was stored. Cache-Status: ExampleCache; hit; ttl=376 replaces the pile of proprietary headers — CF-Cache-Status, X-Cache, X-Cache-Status, X-Served-By — that each express a slice of the same thing in a different vocabulary. It is a Standards Track document from June 2022, it uses structured fields, and its authors work at Cloudflare, Akamai and Fastly.

The problem is that the people who wrote it have largely not shipped it on by default. Mark Nottingham’s August 2026 survey of 120 million responses from the Tranco top 100,000 found roughly 1.1 million Cache-Status instances against tens of millions of proprietary equivalents — about a thirtyfold gap. Squid and Caddy’s cache handler have built-in support and Fastly can be made to emit it with a recipe, but Cloudflare still leads with CF-Cache-Status and nginx has no native path. A reader who followed our advice would be configuring a header by hand that their CDN does not produce and their monitoring does not parse.

There is a second, more interesting reason to wait, and it is the one that generalises. Cache-Status is a debugging channel: it explains the cache to whoever is looking at the response, which in practice is the operator, not the visitor. We already carry Server-Timing on those grounds, so the shape is not disqualifying — but Server-Timing has no incumbent, and this does. A page that tells people to add a standard header their CDN will not emit, next to the proprietary one it already emits, asks them to run two vocabularies to describe one cache. That is worth recommending once the standard one wins, and not before.

A site that receives webhooks has a genuine problem: anyone who learns the endpoint URL can post to it. /.well-known/webhook-authorized-senders.json proposes to solve it from the receiving end — the receiver publishes a JSON allowlist of the hostnames it is willing to accept deliveries from, and a well-behaved sender fetches that file and refuses to deliver if it is not named. The idea is sound, the file is trivial to serve, and it is the kind of externally-checkable property this spec normally likes.

It has one implementer. The registration’s change controller is Intempus ApS, the registered reference is that company’s own documentation page, and we found no other party publishing or reading the file. Its permanent status in the IANA registry is easy to misread: permanent means a stable specification exists and the suffix will not be reassigned, not that anyone uses it. That is the whole of the adoption evidence, and it is not enough — a page here would tell readers to publish a file that exactly one sender in the world consults.

The comparison that settles it is Standard Webhooks, the multi-vendor effort covering the same ground. It verifies senders with HMAC or asymmetric signatures over the payload and tells receivers to keep a trust list of public keys — deliberately not a discovery document. Where the two approaches disagree, the one with several implementations behind it is the one to describe. This entry is our reference case for the rule that IANA permanence is a statement about the registry, not about the web.

RFC 9875 defines two response headers: Cache-Groups tags a response as belonging to one or more named groups, and Cache-Group-Invalidation declares a group stale. Together they let a server say “these seven URLs are one thing” — something HTTP has never been able to express, since invalidation has always been per-URL.

It is a genuinely good idea, and it is finished: Proposed Standard, published October 2025, with both field names registered permanently at IANA. The problem is that nothing appears to implement it. There is no MDN page and no Browser Compatibility Data key, no Chrome Platform Status entry, and no mention in Cloudflare’s cache documentation or changelog — Cloudflare still purges by proprietary Cache-Tag through its dashboard and API, with no in-band header path. Fastly, Varnish, nginx and Squid show no sign of it either. The one candidate implementation, the Go cache Souin, describes its support against the pre-RFC draft.

So a page today would recommend a header that no cache on any reader’s path would read. That is the opposite of what this spec is for. The standard is not the problem; the deployment is, and that can change quickly.

A cross-device flow is one where authentication starts on one device and finishes on another: scanning a QR code with a phone to sign in on a TV, or typing a short code shown on a console into a laptop. RFC 10027, published in August 2026 as BCP 247, catalogues the attacks these flows invite — largely variants of persuading someone to authorise a session they did not start — and sets out the mitigations: establish proximity where you can, keep codes short-lived and single-use, rate-limit and watch for anomalies at the authorization server, and prefer FIDO2/WebAuthn over a device authorization grant when the choice is available.

It is good advice, and it is not advice to a website. The document names its audience — architects, fraud analysts, and engineers building authentication systems — and every mitigation lands inside an authorization server or a native client. Nothing here is visible at an origin: there is no header to send, no element to emit, no resource to publish, and so nothing an outside observer could check. A site that consumes a well-implemented identity provider satisfies the BCP without doing anything, and a site that runs its own cannot express its compliance in any form this spec could describe.

This is the same line drawn for the HTTP QUERY method: a real standard, correctly aimed at the people who build protocol infrastructure, with no property of a good website at the other end of it. Where authentication does surface at the origin — the passkey-reuse assertion at /.well-known/webauthn, the password-change hint at /.well-known/change-password, the cognitive-load rules in accessible authentication — this spec already covers it.

IANA registered cyclic-trigger as a provisional well-known URI suffix on 17 August 2026. The idea behind it is a reasonable one for a certain kind of deployment: rather than every service keeping a timer or a background worker alive, a service exposes /.well-known/cyclic-trigger/go, and external infrastructure POSTs an empty JSON object to it on whatever schedule the ecosystem decides. The trigger carries no parameters at all — it says only “here is an opportunity to run”, and the receiving service decides for itself whether anything happens. In a serverless estate where idle workers cost money, that is a sensible inversion.

It is not, however, a property of a website. Nothing a visitor, a crawler or an agent does is affected by whether this endpoint exists, and nobody outside the operator’s own control plane is meant to call it. The /.well-known/ prefix makes it look like the discovery documents this spec normally covers — security.txt, the api-catalog, an agent card — but those are files a third party fetches to learn something about the site. This is a remote procedure call that happens to have a fixed name, addressed by infrastructure that already knows the service is there. Registering a suffix reserves a path; it does not make what lives at that path a website concern, and the well-known overview is where that distinction is drawn.

The second problem would keep it out even if the first went away. The specification requires that failures return 200 OK with a fault property in the body, explicitly to spare orchestrators from transport-level error handling. That is the soft-404 antipattern — which this spec marks avoid — generalised from one status code to all of them, and it contradicts what error pages says about signalling failure in the status line where every intermediary can see it. We would be recommending a convention that teaches the opposite of a page we already publish.

Adoption does not rescue it either. The registered reference is a two-commit GitHub repository created on 23 June 2026 and untouched since, with no stars, forks, watchers or issues, no named implementers, and no security section for an endpoint whose entire purpose is to make a service perform work on an unauthenticated POST. This entry is our reference case for a narrower rule than the usual one about adoption: a /.well-known/ name is not automatically a website property. Some registrations are private machinery wearing a public prefix.

xRegistry — “extensible registry” — is a CNCF Serverless Working Group project, a sibling of CloudEvents built largely by the same people. It “defines an abstract model for how to manage metadata about resources and provides a REST-based interface for creating, modifying, deleting and discovering of those resources”, with three concrete registries layered on that model: schemas, message definitions, and messaging endpoints. The core specification and all three domain specifications sit at v1.0-rc4. The xregistry suffix was added to the IANA Well-Known URIs registry on 19 August 2026, with the xRegistry Authors as change controller.

It did not land here because of whose origin is expected to answer. The well-known URIs this spec covers — security.txt, change-password, api-catalog — are published by the site a person or a crawler visits, and a site is better or worse for serving them. /.well-known/xregistry is answered by a registry server: a piece of messaging infrastructure whose clients are other services, discovering event schemas and endpoints. A content site that never serves it is not thereby a worse website, and there is no visitor, crawler, or agent outcome to phrase a “Why it matters” around. That the specification is still at release candidate is a second reason to wait, but not the operative one — a 1.0 would not change the scope argument.

This is the third registration in a month to fail the same test, after /.well-known/scitt-keys and /.well-known/cyclic-trigger, so treat it as the reference case for the general rule rather than one more instance: the Well-Known URIs registry is not a to-do list for websites. It is a namespace shared by everything that speaks HTTP, and much of what lands in it belongs to servers that no one browses. Before a suffix earns a page here, ask which host is meant to serve it. If the answer is “an API gateway”, “a registry”, or “a control plane”, it is out of scope no matter how permanent the registration or how healthy the standards body behind it.

IANA has registered dpp as a link relation type: “a link from a context URI that identifies a product to its digital product passport”, on the authority of the UN Transparency Protocol. A Digital Product Passport is the machine-readable record of a product’s materials, provenance and sustainability data that EU Ecodesign regulation will require for a widening list of categories, starting with textiles, footwear and batteries in 2026–2027. Three separate signals arrived within a few months of each other: the IANA registration, schema.org 30.0 adding EU Digital Product Passport examples aligned to UN/CEFACT codes, and the UNECE/ISO joint initiative. On the face of it that looks like a topic arriving.

The problem is where the link actually lives. UNTP does not put rel="dpp" on the product’s web page. It puts it in a linkset — RFC 9264, the same media type this spec already covers under the api-catalog — returned by an identity resolver, extending the GS1 Digital Link resolver schema. The context URI is a GS1 product identifier, the client is a scanner following a QR code on physical packaging, and the passport itself comes back as a verifiable credential. None of that is a property of a website. A spec page here would have to recommend that ordinary product pages emit a Link: <…>; rel="dpp" header, and nobody is doing that, because the protocol does not ask them to.

So this is not the usual too-early case of a good header nothing reads yet. It is a registered relation that is genuinely in use, in a place this spec does not describe. That could change: the regulation lands on manufacturers who already run product pages, and the cheapest way to make a passport discoverable to a crawler rather than a barcode scanner is to advertise it from the page. If that becomes the convention, it is a page — and the Link header and structured data topics are where it would connect.

QUERY is a safe, idempotent HTTP method that carries a request body, filling the long-standing gap between GET (safe and cacheable, but no body) and POST (body, but neither). It is a real addition to the platform, published as a Proposed Standard in June 2026.

It is also a property of an API, not of a website. A site does not become better for a visitor, a crawler, or an agent by supporting QUERY; the sites that need it are the ones exposing a search or filter API, and for them the method is an implementation choice among several reasonable ones. There is nothing here to check from the outside and no outcome to describe in terms of the people using the site.

That is the line this spec draws throughout: HTTP methods are how you build a thing, not what a good website does.

A page on subgrid was written and proposed, then closed unmerged. It is worth recording why, because the argument for it was a good one: subgrid has been Baseline widely available since September 2023, the spec already covers container queries and anchor positioning, and cross-component alignment is a real problem.

The reason it did not land is that subgrid is a way of building a site rather than something a good site does. A layout built with subgrid and the same layout built with flexbox and a few explicit track sizes are indistinguishable to the visitor, the crawler, and the agent. There is no header to check, no element to look for, no behaviour to verify. The benefit is real, but it accrues to the developer.

This is the reference case for every newly-Baseline CSS or JavaScript feature the daily standards scan turns up. Container queries and the Popover API earned pages because each maps to something a visitor experiences — components that adapt to the space they are given; dismissal and focus behaviour users can rely on. Most authoring conveniences do not, however well supported they are.

SCITT — Supply Chain Integrity, Transparency and Trust — gives software supply chains an append-only, auditable record. A publisher signs a statement about an artefact, a transparency service records it on a verifiable data structure, and the publisher gets back a receipt proving the registration happened. RFC 9943 published that architecture as a Proposed Standard in June 2026; the companion SCITT Reference APIs draft defines /.well-known/scitt-keys, which a transparency service serves so that relying parties can fetch the public keys needed to verify those receipts. IANA registered the suffix on 1 July 2026.

The registration is what brought it into view here, because new well-known URIs are exactly what this spec watches for. But the registry is not a scope boundary — it holds well-known URIs for smart inverters and for job-posting feeds too. The question is who serves the file, and the answer is a transparency service: a piece of supply-chain infrastructure, operated by whoever runs the ledger. It is not something a website serves alongside its security.txt. A site that publishes to a transparency service is a client of one of these endpoints, never the host of one.

That distinction is the useful part, and it generalises past SCITT. /.well-known/ is a shared namespace, not a list of things every origin should have, and a suffix landing in the registry says only that somebody needed a stable path — not that the somebody was a website. The test that matters is whether serving the file makes this origin better for its visitors, crawlers, or agents. For security.txt or change-password it plainly does. For scitt-keys it plainly does not, and no amount of adoption among ledger operators would change that — which is why the reason here is scope, not timing.