List HTTP headers "tdm-reservation" and "tdm-policy"

[jfrech]

Proposal

Create the following two pages describing Text and Data Mining (TDM) reservation via HTTP headers:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/tdm-reservation
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/tdm-policy

Task list

• Create page https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/tdm-reservation, explain its syntax and reference https://www.w3.org/2022/tdmrep/#sec-tdm-header.
• Create page https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/tdm-policy and possibly another page detailing the intricacies and implications of a TDM policy.

Additional information

Cf. https://www.w3.org/2022/tdmrep/#sec-tdm-header

Are you willing to support this work?

Yes; I would be happy to create a PR for both pages.

Depends on

Possibly an article discussing TDM reservation more broadly; HTTP headers are only one of three currently defined "techniques" (cf. https://www.w3.org/2022/tdmrep/#sec-processing-priority) to state TDM reservation.

[bsmth]

Thanks for opening the issue. @jfrech do you know the implementation status of these? Does any browser support it? Criteria for inclusion can be found here: https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Criteria_for_inclusion#web_standards_technologies

[jfrech]

(...) Does any browser support it? (...)

These headers' raisons d'être are to be machine-understood. It thus would surprise me if any human-operated browser user-visibly interpreted them.

I make the claim, this fact doesn't preclude an MDN write-up.

[bsmth]

Are there any systems that respect this? Ideally there's some evidence that there are implementations which observe those prefs before we document it, otherwise people may assume it's providing safeguards which are not in fact enforced. Some references:

• https://w3c.github.io/tdm-reservation-protocol/docs/tdm-meaning.html
• https://www.w3.org/community/tdmrep/2025/10/01/notes-september-30th-2025/

[jfrech]

Ideally there's some evidence that there are implementations which observe those prefs before we document it, (...)

I neither think that's the ideal (documenting expressly doesn't equate to advertising) nor do I think that's the reality for MDN in its current form:

• e.g. cf. https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/device-cmyk#browser_compatibility [2025-10-29]

---

As a European citizen, I firmly believe the thoughts some European legislative bodies are coming up with to reign in certain technological happenings are worth looking at and recognizing their existence of.
With this very issue, I wanted to ask MDN if they are interested to lend a minuscule portion of their outreach to a W3C spec. Since MDN documents all kinds of legacy/used-by-no-browser/possibly-nonsensical corners of the Web, I didn't expect this to receive such ontological pushback.

[bsmth]

Thanks @jfrech for the response, and just to be clear,

I firmly believe the thoughts some European legislative bodies are coming up with to reign in certain technological happenings are worth looking at and recognizing their existence of.

I'm 100% behind you, and I'm sure the rest of the team here are, too. Maybe I can add some more context why I said this in my previous comment:

people may assume it's providing safeguards which are not in fact enforced

We've been here before with DNT. This even found its way into browser UIs, and it was ultimately considered harmful -> it gave users the impression that they could use this mechanism to control tracking preferences, but this was practically not true. There's a significant amount of cleanup and clarifications involved in situations like this.

The same applies here, which is why I'm asking about implementation status, if it's worth developers invest the time such that their sites include it at all. If there are no systems that respect it, it can be harmful to propagate.

I don't want to block the work, and I think it would be great to show support for this initiative, but I'm advocating for some caution, as we do with all nascent technologies, hence my questions about whether it does anything or not.

You're welcome to get feedback from the other team members for the sake of diverse opinions: CC @mdn/content-team

[pepelsbey]

Since MDN documents all kinds of legacy/used-by-no-browser/possibly-nonsensical corners of the Web

MDN recently celebrated 20 years and we constantly evolving to stay relevant, useful, and maintainable. You can check our writing guidelines for Criteria for inclusion and Experimental, deprecated, and obsolete if you’re interested in our current policies.

Yes, there are pages that were added before these policies were implemented and device-cmyk() is a good example. But we try to avoid documenting such features and remove the ones that are still left.

So I agree with @bsmth that we would have to wait for this feature to be supported to document it. Although advocating for useful features is as important as documenting them, we’re focused on documenting here. Which doesn’t stop us from writing about other stuff on our blog. For example: Implications of Global Privacy Control and Introduction to web sustainability.

[pransh15]

Thanks for putting this together, @jfrech — I really appreciate the thoroughness of your proposal.

I agree that documenting TDM reservation mechanisms, especially those defined in the W3C Text and Data Mining Reservation Protocol, aligns with MDN’s role in surfacing open and web-exposed standards. The concept is open, relevant to the web (HTTP headers), and emerging in legal and technical discussions, so it meets several of our criteria for inclusion.

That said, I’d echo some of the caution raised earlier. As with Do Not Track, we’ve seen how documenting early-stage or low-adoption mechanisms can unintentionally suggest to developers or users that these headers are already widely supported or enforceable — when they may not be.

The ideal next step may be to begin with a conceptual article on TDM reservation and linking to header reference pages from there makes more sense. This balances openness with accuracy, and gives us room to expand once the technology matures.

[jfrech]

The way I understood it, DNT, Accept-Charset, not-specifically-requested Sec-CH-UA-Bitness, too-fine-grained Device-Memory etc. have at their problematic heart the increase of requestor entropy. As Tdm-Reservation is a response-only header field, all of that doesn't apply; servers are neither human persons (so don't fall under GDPR protection/moral care) nor is their identity unclear (they intentfully shout their host name, IP address, often detailed Server and X-Powered-By etc. out into the world).

[jfrech]

@bsmth

I'm 100% behind you, and I'm sure the rest of the team here are, too.

I am very uncertain regarding the truthfulness of this statement; I have contributed to the MDN corpus and wasn't asked or notified that the MDN corpus got and continues to get AI-mangled (cf. https://github.com/orgs/mdn/discussions/741 [2025-11-08]).

MDN actively uses and promotes these technologies that under some jurisdictions, such as the EU, and under some interpretations within them violate basal Urheberrechts-conceptions as well as under some, possible very subjective interpretations hurt people's Persönlichkeitsrechte. Most definitely, their juridicial and moral interpretation isn't by any means unilaterally negotiated within society.

En somme, I would urge you to reconsider the implied "100% from most of MDN" and knock it down a bit. I would kindly ask you not to wield claims of 100% affirmation as a default.

[jfrech]

I would furthermore like to bring attention to the fact that Tdm-Reservation's effect may not necessitate automatic interpretation: We have seen ideations to bring certain as-wrongful-perceived data mining practices to court (cf. https://drewdevault.com/2022/06/23/Copilot-GPL-washing.html [2025-11-08]), and in the process of interpreting contractual intent in the implicit agreement made by dint of the data exchange between the server-owning party and the data-mining party, the mere, never-from-the-crawler-interpreted presence of W3C-semantics-imbued metadata such as Tdm-Reservation may very well prove a decisive factor. In this sense, setting Tdm-Reservation: 1 already at this hour has an effect, irrespective of client-side implementation proliferation.

[bsmth]

@jfrech: Everyone collaborating in Mozilla spaces, including online spaces such as GitHub repositories, must adhere to Mozilla Community Participation Guidelines (CPG). Being rude, dismissive, or disrespectful will not be tolerated. Please read the CPG and familiarize yourself with the Open source etiquette guide. Thank you.