Network Working Group T. Vaughan
Internet-Draft Common Crawl Foundation
Intended status: Informational 3 July 2026
Expires: 4 January 2027
Defining Machine Readability for Usage Preferences and Policy Expression
draft-vaughan-machine-readability-00
Abstract
The term "machine readable" is widely invoked when content usage
preferences, rights, and legal terms are expressed for automated
consumption, but it is rarely defined with enough precision to be
actionable. This document distinguishes a series of properties
(discoverability, parseability, interpretability, actionability, and
verifiability) that together determine whether an expression of
preferences or policy can be reliably acted upon by a non-human agent
without human intervention. It applies these properties to the case
of usage preferences and legal terms of service.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-vaughan-machine-readability/.
Source for this draft and an issue tracker can be found at
https://github.com/thunderpoot/readability-draft.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 January 2027.
Vaughan Expires 4 January 2027 [Page 1]
Internet-Draft Machine Readability July 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. A Ladder of Machine Readability . . . . . . . . . . . . . . . 4
3.1. Discoverable . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Parseable . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Interpretable . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Actionable . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. Verifiable . . . . . . . . . . . . . . . . . . . . . . . 5
4. Separability . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Requirements for Legal Terms . . . . . . . . . . . . . . . . 6
6. Relationship to Existing Work . . . . . . . . . . . . . . . . 7
6.1. Robots Exclusion Protocol . . . . . . . . . . . . . . . . 7
6.2. AIPREF . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. ODRL . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.4. DPV . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. CC REL . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.6. TDMRep . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.7. Schema.org . . . . . . . . . . . . . . . . . . . . . . . 10
6.8. Dublin Core . . . . . . . . . . . . . . . . . . . . . . . 10
6.9. C2PA . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Vaughan Expires 4 January 2027 [Page 2]
Internet-Draft Machine Readability July 2026
1. Introduction
Expressions of how content may be used by automated systems are
increasingly published in forms described as "machine readable".
Operators of crawlers and other automated Agents are expected to
discover these Expressions, determine what they permit or forbid, and
act accordingly. The term "machine readable" is invoked frequently
in this context, in standards work, in policy, and in legislation,
but it is rarely defined with enough precision to tell an implementer
whether a given Expression actually supports automated action.
The difficulty is that "machine readable" names several distinct
properties that are commonly conflated. An Expression may be
serialised in a structured syntax, and so be straightforward for a
program to parse, while still conveying nothing a program can act
upon. A terms-of-service document placed verbatim in a JSON string
sits inside a parseable envelope, but the terms themselves parse no
better than the same text in a web page. What a conforming Agent
recovers is a string of legalese, not a structured representation of
anything upon which it can act. Conversely, an Expression may be
richly actionable yet undiscoverable, or trivially discoverable yet
unverifiable. Treating "machine readable" as a single binary
property obscures these differences, and permits a Declaring Party to
claim machine readability on the strength of the least demanding
property while failing the ones that actually matter for automated
action.
This document separates "machine readable" into five properties: an
Expression may be discoverable, parseable, interpretable, actionable,
and verifiable. These are defined in Section 2 and Section 3. They
are presented as a ladder, from least to most demanding, but they do
not strictly entail one another, and Section 4 sets out how they come
apart in practice. The purpose of the framework is diagnostic: it
allows a given mechanism to be described in terms of precisely which
properties it provides, rather than asserted to be machine readable
as an undifferentiated whole.
The framework is general, but this document applies it in particular
to two cases: the expression of usage preferences for automated
processing, and the expression of legal terms of service. The latter
is treated at length in Section 5, because legal text exposes the gap
between the lower and higher rungs most sharply. Terms that are easy
to publish in a structured form are frequently impossible to act upon
without human interpretation.
Vaughan Expires 4 January 2027 [Page 3]
Internet-Draft Machine Readability July 2026
This document does not define a vocabulary, a syntax, or a protocol,
and it is not a product of any IETF working group. It does not
propose that any existing mechanism be changed. Its contribution is
a set of definitions against which existing and future mechanisms can
be assessed.
2. Terminology
Agent: A non-human process that acquires, processes, or acts upon
content or its associated expressions without real-time human
direction. A web crawler, for instance.
Expression: A concrete artefact (for instance: a file, header,
embedded block, or metadata record) that conveys preferences,
rights, terms, or other policies about a resource.
Resource: The content or asset to which an Expression pertains.
Declaring Party: The entity asserting an Expression.
3. A Ladder of Machine Readability
The properties below are presented as a ladder, from least to most
demanding, because each higher rung is most useful when the rungs
beneath it also hold. An Expression whose meaning is fixed
(interpretable) is of little utility if an Agent cannot find it
(discoverable). For expository purposes this document treats the
rungs as cumulative. They are not, however, strictly dependent, and
Section 4 describes the cases in which they come apart.
An Expression should have the following properties:
3.1. Discoverable
An Expression is discoverable if an Agent can locate it from the
Resource, or from the act of acquiring the Resource, without out-of-
band knowledge specific to the Declaring Party. A test would be
whether the Agent can find the Expression, when given only the
Resource's identifier and a general method. A robots.txt file passes
this test (fixed path, fetched first). A terms page linked only from
a human-readable footer fails. The "without out-of-band knowledge"
clause is what excludes something like "email us for our API terms".
Vaughan Expires 4 January 2027 [Page 4]
Internet-Draft Machine Readability July 2026
3.2. Parseable
An Expression is parseable if its syntax is defined such that a
conforming Agent recovers the same structured representation from it
that any other conforming Agent would. A test for this would be
whether there is a grammar or schema against which the Expression is
valid or invalid, deterministically. A terms-of-service document
carried in a JSON string is a useful case about which to be precise:
the JSON envelope is valid against a grammar and every conforming
Agent recovers the same envelope, but the terms inside it recover
only as an opaque string, with no grammar of their own. Wrapping
prose in a parseable container does not make the prose parseable, and
this is the characteristic most often mistaken for machine
readability as a whole.
3.3. Interpretable
An Expression is interpretable if the meaning of its parsed elements
is fixed against a shared, identified vocabulary, such that two
conforming Agents assign the same meaning to the same element. A
test for this is whether each term is resolvable to a definition that
is itself machine-identified, (like a URI or a registry entry) rather
than relying on the Agent's own natural-language understanding. This
characteristic separates something like a JSON field called
"may_train" (whose meaning is whatever a reader guesses) from
AIPREF's train-ai, whose meaning is pinned to a specification.
3.4. Actionable
An Expression is actionable if an interpretable Expression
additionally determines, for the Agent's purposes, a definite outcome
(like "permitted", "forbidden", or something like "conditional-based-
on-a-checkable-condition") without recourse to a human. A test for
this could be whether the Agent can map the interpreted Expression
onto its specific pending action and get an answer. An Expression
that says "use must be fair" is interpretable but admits no definite
outcome, because 'fair' is not a checkable condition. One that says
"training forbidden" is actionable against the action "train".
3.5. Verifiable
An Expression is verifiable if an Agent can establish that it
genuinely originates from a party authorised to make assertions about
the Resource, and that it has not been altered. A test for this
could be whether there is a mechanism binding the Expression to an
authorised Declaring Party and detecting tampering.
Vaughan Expires 4 January 2027 [Page 5]
Internet-Draft Machine Readability July 2026
4. Separability
The ladder metaphor is an expository convenience, and not a claim
that each characteristic actually strictly entails the ones below it.
Real Expressions satisfy these properties in patches.
The Robots Exclusion Protocol [RFC9309] is both highly discoverable
and parseable. It is fetched from a fixed location before any other
resource, and its grammar is defined in ABNF. It is deliberately not
interpretable in the rich sense used here, because its vocabulary is
confined to access control (allow and disallow against paths) and
carries no shared semantics for what an Agent may do with content
once fetched. It provides no verifiability whatsoever and trust
derives entirely from the authority of the server.
Conversely, a cryptographic provenance Expression may be verifiable
and parseable while saying nothing about usage permissions at all,
and so contribute nothing on the actionable rung for a usage
decision.
An Expression may, therefore, occupy a high rung while failing a
lower one, or satisfy a lower rung richly while being absent higher
up. The value of the ladder is diagnostic in that it lets one state
precisely which property a given mechanism provides and, more
importantly, which it does not, rather than asserting that a
mechanism is or is not "machine readable" as an undifferentiated
whole.
5. Requirements for Legal Terms
The properties of Section 3 are general, but legal terms of service
are where the gap between the lower and higher rungs is widest.
Terms are easy to publish in a parseable form, and may even reach
Section 3.3, but in most cases they stop short of Section 3.4: they
cannot be acted upon without a human to interpret them. A document
may be structurally sound, valid against a schema, and served from a
location an Agent can discover, and still offer that Agent no
machine-determinable answer to the one question it actually has,
which is whether the action it is about to take is permitted.
Vaughan Expires 4 January 2027 [Page 6]
Internet-Draft Machine Readability July 2026
At crawl scale this ceases to be a nuisance and becomes a barrier.
An Agent operating across the web encounters resources in numbers
that make per-resource interpretation of natural-language terms
infeasible as part of fetching them. No stage of a crawl pipeline
can read a terms-of-service document, written for human readers and
varying from one site to the next, quickly enough, reliably enough,
and cheaply enough to decide the fetch. A mechanism that demands
this does not describe a workable system. It describes a human
reading legalese, repeated some billions of times.
It is sometimes proposed that a large language model (LLM) could
close the gap, reading the terms at scale and reporting what they
permit. Such an approach must not be relied upon for usage
decisions. A language model does not determine what a document
permits. It produces text resembling that determination, and it does
so with a well-documented tendency to hallucinate or fabricate. A
crawler that fetches or declines a Resource on the strength of a
model's reading of prose is making an access decision from output
that may be confidently wrong, and cannot be checked against the
source without the very human reading it was meant to replace.
Wrapping the prose in a structured form changes none of this. The
wrapper is parseable, but it does not render the terms inside it
actionable.
6. Relationship to Existing Work
The mechanisms surveyed below each address some part of the problem
this document frames, and none addresses all of it. They are
described here in terms of what they do and where they sit against
the properties of Section 3, not to rank them, but to show that the
framework describes existing work rather than displacing it.
6.1. Robots Exclusion Protocol
The Robots Exclusion Protocol [RFC9309], standardised in 2022 from
the convention Martijn Koster introduced in 1994, lets a service
state which URI paths a named crawler may fetch. Its grammar is
defined in ABNF and a crawler retrieves it from a fixed location
before fetching anything else, so it is highly discoverable and
parseable. It is, by its own terms, access control and not
authorisation, and it says nothing about what may be done with
content once fetched. It carries no provenance or integrity
mechanism, and a crawler's trust in it rests entirely on the server's
authority over the domain. It is the clearest example in this
document of a mechanism that sits firmly on the lower rungs and makes
no claim to the higher ones.
Vaughan Expires 4 January 2027 [Page 7]
Internet-Draft Machine Readability July 2026
6.2. AIPREF
The IETF's AI Preferences working group (AIPREF) is developing a
means for content owners to express how their material may be used by
automated systems, in particular for AI training. Its work is split
between a vocabulary ([I-D.ietf-aipref-vocab]), which defines
preference categories such as train-ai and search and fixes their
meaning against a specification, and an attachment mechanism
([I-D.ietf-aipref-attach]), which conveys those preferences through
an HTTP header and through an extension to robots.txt. The
vocabulary is what lets AIPREF reach the interpretable rung where
most usage signals stop short: a crawler encountering train-ai=n
recovers not merely a string but a term whose meaning is pinned, as
discussed at Section 3. AIPREF is explicit that preferences are not
a security mechanism, and it provides no verifiability. It
establishes neither who set a preference nor that it is unaltered.
It is (at the time of writing) a work in progress.
6.3. ODRL
The Open Digital Rights Language (ODRL) [ODRL], a W3C Recommendation
since 2018, is a formal language for expressing policies over digital
assets. Permissions, prohibitions, and duties are attached to
actions drawn from an identified vocabulary and narrowed by
constraints such as time, place, or purpose. Of the mechanisms
surveyed here it reaches highest on the interpretable and actionable
rungs, because its terms are pinned to a published vocabulary and its
rules are structured precisely enough that an evaluator can decide
whether a given action is permitted. That expressive power is also
its difficulty. ODRL says nothing in itself about where a policy is
to be found or whether it is genuine. Discovery is left to other
mechanisms that link an asset to its policy, and integrity is left to
metadata borrowed from outside vocabularies, since ODRL 2.2 carries
no native means to establish that a policy is authentic or unaltered.
It is a rich answer to interpretability and actionability that leaves
discoverability and verifiability to others.
6.4. DPV
The Data Privacy Vocabulary (DPV) [DPV], a W3C Community Group
specification rather than a Recommendation, is a large taxonomy of
terms for describing how personal data is processed: purposes, legal
bases, processing operations, technical measures, and, through its
extensions, concepts drawn from regulations such as the GDPR and the
EU AI Act. It is included here not because a crawler would discover
and act on a DPV document in the way it discovers robots.txt, but
because of the role it plays on the interpretable rung. DPV is
designed to be used inside other mechanisms. Its terms can supply
Vaughan Expires 4 January 2027 [Page 8]
Internet-Draft Machine Readability July 2026
the meaning of a condition in an ODRL policy, so that a constraint
refers to a defined concept of purpose or jurisdiction rather than to
a bare string. In the vocabulary of Section 3 it is an
interpretability resource, a source of identified, shared meaning
that other Expressions can draw on, rather than a discoverable, self-
standing signal in its own right. Like the others surveyed here it
provides provenance metadata but no cryptographic integrity, and it
establishes nothing about who asserted a given statement.
6.5. CC REL
Creative Commons Rights Expression Language (CC REL) [CCREL],
published as a W3C Member Submission in 2008, is the method Creative
Commons recommends for attaching licence information to a work in
machine-readable form. It is RDF-based and designed to be embedded
where the work lives: as RDFa attributes in HTML, or as XMP metadata
inside a media file so that the licence travels with the file when it
is copied. Its terms are interpretable in the sense Section 3
requires, since a CC licence is identified by a URI that resolves to
a defined set of permissions, requirements, and prohibitions rather
than to free text, and it is the most widely deployed of the
mechanisms surveyed here by virtue of the licences themselves. Its
placement on the ladder is otherwise mixed: discovery depends on the
work carrying the embedded markup, which an Agent can read where it
is present but cannot rely on in general; and while CC REL records
attribution and source, giving a measure of provenance, the
specification itself provides no cryptographic means to confirm that
a licence statement is authentic or unaltered. It is also worth
noting that a Member Submission is not a W3C standard; W3C received
the work but did not place it on the standards track.
6.6. TDMRep
The TDM Reservation Protocol (TDMRep) [TDMREP], a W3C Community Group
Final Report, is a deliberately simple mechanism by which a rights
holder can reserve text-and-data-mining rights over web content,
developed as a technical response to the reservation contemplated by
Article 4 of the EU's Digital Single Market copyright directive. Its
core is a single property, tdm-reservation, set to 1 or 0, optionally
accompanied by a URL pointing to a fuller policy. A crawler finds it
in a file at a well-known location that the specification directs an
Agent to fetch before "mining" anything on the server, with HTTP
headers and in-document metadata as alternatives. Of everything
surveyed here, TDMRep climbs the crawler-relevant rungs most cleanly
for its narrow question: it is discoverable by fixed convention,
parseable, interpretable because tdm-reservation is a defined term
rather than a guessable field, and actionable because its value
yields a definite outcome against the act of "mining". Where it
Vaughan Expires 4 January 2027 [Page 9]
Internet-Draft Machine Readability July 2026
stops, like the others, is verifiability. The specification provides
no cryptographic means to establish who set a reservation or that it
is unaltered, and the schemes that add this by binding declarations
to content fingerprints actually sit outside TDMRep. Its narrowness
is the point of its success. By asking only whether mining is
reserved, it essentially stays answerable.
6.7. Schema.org
Schema.org [SCHEMA-ORG] is a vocabulary of structured-data terms
embedded in web pages, maintained by a community backed by the major
search engines rather than published as a standard. Among its terms
are several concerned with rights: license, usageInfo,
acquireLicensePage, and others, attached to a described work. These
are the closest thing to a usage signal that a great many sites
already publish, which is what makes schema.org the sharpest
illustration of the distinction that this document draws. The
license property is defined as "a license document that applies to
this content, typically indicated by URL", and that phrase is the
whole difficulty in miniature. A schema.org licence annotation is
reliably discoverable and parseable, and where the URL it carries is
a recognised licence with fixed meaning, for instance a specific
Creative Commons licence, it is interpretable too. But where the URL
points to a publisher's own licence page written in prose, the
structured part of the chain ends at that link, and what waits on the
other side is exactly the human-readable document that Section 5
describes. It is parseable to reach, not actionable once reached.
Schema.org is structured data that can carry an actionable signal or
a mere pointer to prose with equal ease, and nothing in the markup
itself tells an Agent which it has been handed. It provides, like
the others, no means to verify who published the annotation. It is
the case that most tempts the conflation mentioned above in
Section 1, where being structured is mistaken for being machine-
readable in the sense that actually matters.
6.8. Dublin Core
The Dublin Core metadata terms [DCTERMS], maintained by the Dublin
Core Metadata Initiative and standardised as ISO 15836, are a
general-purpose vocabulary for describing resources of any kind.
Among the terms are two concerned with rights: dcterms:rights,
defined as information about rights held in and over the resource,
and dcterms:license, a sub-property defined as a legal document
giving official permission to do something with the resource. Like
schema.org and CC REL, Dublin Core is a way of attaching a rights
value to a described work rather than a policy language in its own
right, and it sits on the ladder in much the same place. Where the
value of dcterms:license is a URI resolving to a licence of fixed
Vaughan Expires 4 January 2027 [Page 10]
Internet-Draft Machine Readability July 2026
meaning, the annotation is interpretable; where it is a free-text
statement of rights, as dcterms:rights commonly is, it reaches no
further than parseable, and a consuming Agent is left stuck with a
string it can't resolve. Dublin Core's own guidance is very open
about this, noting that a bare URI recorded as a value string gives a
consuming application no reliable way to tell it apart from any other
string and so to treat it as an identifier. It provides, like the
other embedded-metadata schemes, provenance (in the weak sense of
recorded attribution) but no means to verify that a rights statement
is authentic or unaltered.
6.9. C2PA
The Coalition for Content Provenance and Authenticity (C2PA) [C2PA]
is unlike everything else surveyed here, because it is not a usage-
preference or rights mechanism at all but a provenance one, and it is
the only mechanism in the survey that answers the verifiability rung.
C2PA binds a cryptographically signed manifest to a digital asset,
recording assertions about the asset's origin and editing history;
the signature and a hash binding make the manifest tamper-evident, so
that any later alteration of the content or the manifest can be
detected. This is genuine verifiability of a kind none of the others
provide. It is worth being precise, though, about which part of
verifiability it delivers. The verifiable rung (Section 3.5) as
defined here asserts that an Expression has not been altered, and
that it genuinely originates from a party authorised to make the
assertion. C2PA answers the first part cleanly. The second is only
answered halfway, in that it establishes that a particular signer
made the assertion and that the assertion is unchanged since, but not
that the assertion is true, nor that the signer had any standing to
make it. As C2PA's own materials put it, it proves who signed a
claim, not whether the claim is true. The integrity limb is solved;
the authority limb, who is entitled to speak for the Resource, is
left where the other mechanisms leave it.
7. Security Considerations
This document defines terminology and a diagnostic framework. It
specifies no protocol, syntax, or wire format, and so introduces no
new protocol elements to secure. The security considerations that
arise concern how the properties it defines are relied upon by Agents
making usage decisions.
An Expression that is not verifiable (Section 3.5) can be forged,
altered in transit or at rest, or published by a party with no
authority over the Resource. An Agent that acts on unverifiable
Expressions is trusting, at most, the channel over which it obtained
them: for a robots.txt file, the server's authority over its own
Vaughan Expires 4 January 2027 [Page 11]
Internet-Draft Machine Readability July 2026
domain; for embedded metadata, whoever last wrote the file. Every
mechanism surveyed in Section 6 except C2PA has this property, and
Agents should treat the assertions such Expressions carry
accordingly.
The absence of integrity protection also permits downgrade by
removal. Where an Expression is conveyed separately from the
Resource it governs, an intermediary that strips or weakens the
Expression leaves the Agent with no indication that a preference was
ever asserted. An Agent cannot tell the difference between "no
Expression published" and "Expression removed in transit" unless the
mechanism binds the Expression to the Resource in some tamper-evident
way.
Conflation of the lower rungs with the higher ones is itself a
hazard. An Agent that treats a parseable Expression as actionable is
acting on content it has not, in the sense of Section 3, actually
understood, and a Declaring Party or third party can exploit that gap
by presenting structurally valid Expressions whose free-text content
does not mean what the Agent's heuristics assume it means.
Finally, the use of language models to interpret natural-language
terms, discussed in Section 5, adds an attack surface beyond the
reliability problem described there. Text under the control of a
Declaring Party or of a third party is processed by a model whose
output steers the Agent's behaviour; adversarially crafted terms may
induce a permissive reading that the document does not support, or
otherwise manipulate the consuming system. This is a further reason
such output must not be the basis of usage decisions.
8. IANA Considerations
This document has no IANA actions.
Acknowledgments
The author thanks Pedro Ortiz Suarez, Erin Simon, and Christopher
Flammang for their reviews of this document and their suggested
additions.
Informative References
[C2PA] Coalition for Content Provenance and Authenticity,
"Coalition for Content Provenance and Authenticity (C2PA)
Technical Specification", n.d.,
.
Vaughan Expires 4 January 2027 [Page 12]
Internet-Draft Machine Readability July 2026
[CCREL] Abelson, H., Adida, B., Linksvayer, M., and N. Yergler,
"ccREL: The Creative Commons Rights Expression Language",
W3C Member Submission, 20 August 2008,
.
[DCTERMS] Dublin Core Metadata Initiative, "DCMI Metadata Terms",
DCMI Recommendation, 20 January 2020,
.
[DPV] Pandit, H. J., Esteves, B., and G. P. Krog, "Data Privacy
Vocabulary (DPV)", W3C Community Group Final Report, 1
August 2024, .
[I-D.ietf-aipref-attach]
Illyes, G. and M. Thomson, "Associating AI Usage
Preferences with Content in HTTP", Work in Progress,
Internet-Draft, draft-ietf-aipref-attach-04, 28 October
2025, .
[I-D.ietf-aipref-vocab]
Keller, P. and M. Thomson, "A Vocabulary For Expressing AI
Usage Preferences", Work in Progress, Internet-Draft,
draft-ietf-aipref-vocab-06, 27 April 2026,
.
[ODRL] Iannella, R. and S. Villata, "ODRL Information Model 2.2",
W3C Recommendation, 15 February 2018,
.
[RFC9309] Koster, M., Illyes, G., Zeller, H., and L. Sassman,
"Robots Exclusion Protocol", RFC 9309,
DOI 10.17487/RFC9309, September 2022,
.
[SCHEMA-ORG]
Schema.org, "schema.org: license property", n.d.,
.
[TDMREP] Meur, L. L., "TDM Reservation Protocol (TDMRep)",
W3C Community Group Final Report, 10 May 2024,
.
Vaughan Expires 4 January 2027 [Page 13]
Internet-Draft Machine Readability July 2026
Author's Address
Thom Vaughan
Common Crawl Foundation
Email: thom@commoncrawl.org
Vaughan Expires 4 January 2027 [Page 14]