<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.39 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-vaughan-machine-readability-00" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.34.0 -->
  <front>
    <title abbrev="Machine Readability">Defining Machine Readability for Usage Preferences and Policy Expression</title>
    <seriesInfo name="Internet-Draft" value="draft-vaughan-machine-readability-00"/>
    <author fullname="Thom Vaughan">
      <organization>Common Crawl Foundation</organization>
      <address>
        <email>thom@commoncrawl.org</email>
      </address>
    </author>
    <date year="2026" month="July" day="03"/>
    <keyword>machine readable</keyword>
    <keyword>usage preferences</keyword>
    <keyword>policy expression</keyword>
    <abstract>
      <?line 93?>

<t>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.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-vaughan-machine-readability/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/thunderpoot/readability-draft"/>.</t>
    </note>
  </front>
  <middle>
    <?line 106?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>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.</t>
      <t>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.</t>
      <t>This document separates "machine readable" into five properties: an Expression may be discoverable, parseable, interpretable, actionable, and verifiable.  These are defined in <xref target="terminology"/> and <xref target="ladder"/>.  They are presented as a ladder, from least to most demanding, but they do not strictly entail one another, and <xref target="separability"/> 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.</t>
      <t>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 <xref target="requirements-for-legal-terms"/>, 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.</t>
      <t>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.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <dl>
        <dt>Agent:</dt>
        <dd>
          <t>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.</t>
        </dd>
        <dt>Expression:</dt>
        <dd>
          <t>A concrete artefact (for instance: a file, header, embedded block, or metadata record) that conveys preferences, rights, terms, or other policies about a resource.</t>
        </dd>
        <dt>Resource:</dt>
        <dd>
          <t>The content or asset to which an Expression pertains.</t>
        </dd>
        <dt>Declaring Party:</dt>
        <dd>
          <t>The entity asserting an Expression.</t>
        </dd>
      </dl>
    </section>
    <section anchor="ladder">
      <name>A Ladder of Machine Readability</name>
      <t>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 <xref target="separability"/> describes the cases in which they come apart.</t>
      <t>An Expression should have the following properties:</t>
      <section anchor="discoverable">
        <name>Discoverable</name>
        <t>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".</t>
      </section>
      <section anchor="parseable">
        <name>Parseable</name>
        <t>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.</t>
      </section>
      <section anchor="interpretable">
        <name>Interpretable</name>
        <t>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.</t>
      </section>
      <section anchor="actionable">
        <name>Actionable</name>
        <t>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".</t>
      </section>
      <section anchor="verifiable">
        <name>Verifiable</name>
        <t>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.</t>
      </section>
    </section>
    <section anchor="separability">
      <name>Separability</name>
      <t>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.</t>
      <t>The Robots Exclusion Protocol <xref target="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.</t>
      <t>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.</t>
      <t>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.</t>
    </section>
    <section anchor="requirements-for-legal-terms">
      <name>Requirements for Legal Terms</name>
      <t>The properties of <xref target="ladder"/> 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 <xref target="interpretable"/>, but in most cases they stop short of <xref target="actionable"/>: 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.</t>
      <t>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.</t>
      <t>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.</t>
    </section>
    <section anchor="existing">
      <name>Relationship to Existing Work</name>
      <t>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 <xref target="ladder"/>, not to rank them, but to show that the framework describes existing work rather than displacing it.</t>
      <section anchor="robots-exclusion-protocol">
        <name>Robots Exclusion Protocol</name>
        <t>The Robots Exclusion Protocol <xref target="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.</t>
      </section>
      <section anchor="aipref">
        <name>AIPREF</name>
        <t>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 (<xref target="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 (<xref target="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 <tt>train-ai=n</tt> recovers not merely a string but a term whose meaning is pinned, as discussed at <xref target="ladder"/>.  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.</t>
      </section>
      <section anchor="odrl">
        <name>ODRL</name>
        <t>The Open Digital Rights Language (ODRL) <xref target="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.</t>
      </section>
      <section anchor="dpv">
        <name>DPV</name>
        <t>The Data Privacy Vocabulary (DPV) <xref target="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 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 <xref target="ladder"/> 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.</t>
      </section>
      <section anchor="cc-rel">
        <name>CC REL</name>
        <t>Creative Commons Rights Expression Language (CC REL) <xref target="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 <xref target="ladder"/> 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.</t>
      </section>
      <section anchor="tdmrep">
        <name>TDMRep</name>
        <t>The TDM Reservation Protocol (TDMRep) <xref target="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, <tt>tdm-reservation</tt>, 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 <tt>tdm-reservation</tt> 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 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.</t>
      </section>
      <section anchor="schemaorg">
        <name>Schema.org</name>
        <t>Schema.org <xref target="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: <tt>license</tt>, <tt>usageInfo</tt>, <tt>acquireLicensePage</tt>, 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 <xref target="requirements-for-legal-terms"/> 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 <xref target="introduction"/>, where being structured is mistaken for being machine-readable in the sense that actually matters.</t>
      </section>
      <section anchor="dublin-core">
        <name>Dublin Core</name>
        <t>The Dublin Core metadata terms <xref target="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: <tt>dcterms:rights</tt>, defined as information about rights held in and over the resource, and <tt>dcterms:license</tt>, 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 <tt>dcterms:license</tt> is a URI resolving to a licence of fixed meaning, the annotation is interpretable; where it is a free-text statement of rights, as <tt>dcterms:rights</tt> 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.</t>
      </section>
      <section anchor="c2pa">
        <name>C2PA</name>
        <t>The Coalition for Content Provenance and Authenticity (C2PA) <xref target="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 (<xref target="verifiable"/>) 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.</t>
      </section>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>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.</t>
      <t>An Expression that is not verifiable (<xref target="verifiable"/>) 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 domain; for embedded metadata, whoever last wrote the file.  Every mechanism surveyed in <xref target="existing"/> except C2PA has this property, and Agents should treat the assertions such Expressions carry accordingly.</t>
      <t>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.</t>
      <t>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 <xref target="ladder"/>, 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.</t>
      <t>Finally, the use of language models to interpret natural-language terms, discussed in <xref target="requirements-for-legal-terms"/>, 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.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>The author thanks Pedro Ortiz Suarez, Erin Simon, and Christopher Flammang for their reviews of this document and their suggested additions.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC9309">
        <front>
          <title>Robots Exclusion Protocol</title>
          <author fullname="M. Koster" initials="M." surname="Koster"/>
          <author fullname="G. Illyes" initials="G." surname="Illyes"/>
          <author fullname="H. Zeller" initials="H." surname="Zeller"/>
          <author fullname="L. Sassman" initials="L." surname="Sassman"/>
          <date month="September" year="2022"/>
          <abstract>
            <t>This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers. Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="9309"/>
        <seriesInfo name="DOI" value="10.17487/RFC9309"/>
      </reference>
      <reference anchor="I-D.ietf-aipref-vocab">
        <front>
          <title>A Vocabulary For Expressing AI Usage Preferences</title>
          <author fullname="Paul Keller" initials="P." surname="Keller">
            <organization>Open Future</organization>
          </author>
          <author fullname="Martin Thomson" initials="M." surname="Thomson">
            <organization>Mozilla</organization>
          </author>
          <date day="27" month="April" year="2026"/>
          <abstract>
            <t>   This document defines a vocabulary for expressing preferences
   regarding how digital assets are used by automated processing
   systems.  This vocabulary allows for the declaration of restrictions
   or permissions for use of digital assets by such systems.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-aipref-vocab-06"/>
      </reference>
      <reference anchor="I-D.ietf-aipref-attach">
        <front>
          <title>Associating AI Usage Preferences with Content in HTTP</title>
          <author fullname="Gary Illyes" initials="G." surname="Illyes">
            <organization>Google</organization>
          </author>
          <author fullname="Martin Thomson" initials="M." surname="Thomson">
            <organization>Mozilla</organization>
          </author>
          <date day="28" month="October" year="2025"/>
          <abstract>
            <t>   Content creators and other stakeholders might wish to signal their
   preferences about how their content might be consumed by automated
   systems.  This document defines how preferences can be signaled as
   part of the acquisition of content in HTTP.

   This document updates RFC 9309 to allow for the inclusion of usage
   preferences.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-aipref-attach-04"/>
      </reference>
      <reference anchor="ODRL" target="https://www.w3.org/TR/odrl-model/">
        <front>
          <title>ODRL Information Model 2.2</title>
          <author initials="R." surname="Iannella" fullname="Renato Iannella">
            <organization/>
          </author>
          <author initials="S." surname="Villata" fullname="Serena Villata">
            <organization/>
          </author>
          <date year="2018" month="February" day="15"/>
        </front>
        <seriesInfo name="W3C" value="Recommendation"/>
      </reference>
      <reference anchor="DPV" target="https://www.w3.org/community/reports/dpvcg/CG-FINAL-dpv-20240801/">
        <front>
          <title>Data Privacy Vocabulary (DPV)</title>
          <author initials="H. J." surname="Pandit" fullname="Harshvardhan J. Pandit">
            <organization/>
          </author>
          <author initials="B." surname="Esteves" fullname="Beatriz Esteves">
            <organization/>
          </author>
          <author initials="G. P." surname="Krog" fullname="Georg P. Krog">
            <organization/>
          </author>
          <date year="2024" month="August" day="01"/>
        </front>
        <seriesInfo name="W3C" value="Community Group Final Report"/>
      </reference>
      <reference anchor="CCREL" target="https://www.w3.org/submissions/2008/02/">
        <front>
          <title>ccREL: The Creative Commons Rights Expression Language</title>
          <author initials="H." surname="Abelson" fullname="Hal Abelson">
            <organization/>
          </author>
          <author initials="B." surname="Adida" fullname="Ben Adida">
            <organization/>
          </author>
          <author initials="M." surname="Linksvayer" fullname="Mike Linksvayer">
            <organization/>
          </author>
          <author initials="N." surname="Yergler" fullname="Nathan Yergler">
            <organization/>
          </author>
          <date year="2008" month="August" day="20"/>
        </front>
        <seriesInfo name="W3C" value="Member Submission"/>
      </reference>
      <reference anchor="TDMREP" target="https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-20240510/">
        <front>
          <title>TDM Reservation Protocol (TDMRep)</title>
          <author initials="L. L." surname="Meur" fullname="Laurent Le Meur">
            <organization/>
          </author>
          <date year="2024" month="May" day="10"/>
        </front>
        <seriesInfo name="W3C" value="Community Group Final Report"/>
      </reference>
      <reference anchor="SCHEMA-ORG" target="https://schema.org/license">
        <front>
          <title>schema.org: license property</title>
          <author>
            <organization>Schema.org</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="DCTERMS" target="https://www.dublincore.org/specifications/dublin-core/dcmi-terms/">
        <front>
          <title>DCMI Metadata Terms</title>
          <author>
            <organization>Dublin Core Metadata Initiative</organization>
          </author>
          <date year="2020" month="January" day="20"/>
        </front>
        <seriesInfo name="DCMI" value="Recommendation"/>
      </reference>
      <reference anchor="C2PA" target="https://c2pa.org/specifications/">
        <front>
          <title>Coalition for Content Provenance and Authenticity (C2PA) Technical Specification</title>
          <author>
            <organization>Coalition for Content Provenance and Authenticity</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAHKRR2oAA6V9W3MbyZHuO35FB/UwVARAURx7Y4YTG7E0JY21K80wKHl8
ztNOobsAtNnohru6ycEw9N9PfplZtwZIjX0cdogAuuuSlZcvb+XFYjEb6qGx
l8XJG7uq27pdFx9NualbW9xaU5ll3dTDvlh1ffE3Z9a2uOntyva2La0rTFsV
N11Tl/vi7W+73jpXd+3JzCyXvb2nIY+MdDIrzWDXXb+/LOp21c1mVVe2Zksr
qHqzGhb3ZlxvTLvYyruLPr67OD+fuXG5rXmeYb+jl96//fxuVu/6y2LoRzdc
nJ9/f34xa8ft0vaXs4rmupzRUr6d3dn9Q9dXl7NiUejYhYzdWHw38u52cXf4
ciebs2Fzs3vbjjRkUazrYTMuaZP0T1vZftd1w6t0sbydk9nMjMOm6zEvvVUU
q7FpZL8nnzfdtvhF9nvCP3b92rT172agqS6L62677driujcPTfGuo2n4B37S
bk3d8Ozd9r9KfrDEc2c0BE0K0vZbevyeF3v77vr7b8+/x5/vF2/OajusFqbG
Zhf3XWmWx34ww0BkupzRTz+/uf1wydMOpl/b4bLYDMPOXb569fDwcPbwLSZ9
9fn2VVf1zWLbVbZ5JU8ra+H94r1fEm3pI54pLs4uZNuBRPyfRSH0ubWtGbri
vWlb2zRm8usnHJMpfqnpp0F+5NMuLs5ff7c4v1i8/jN/6WxfWwd6+PH//u01
BgfRrCcp/fTm5pev7hHvjC2dLp30rusH96ra3ZfrV9c/Lt69/+nqw4I+Li7O
L/50/t3565wGb2iVJDz1vSGG+gVEHxvT74tTmvflc2T4q+nd5t70FXFJ8d9n
xQ1JXT1MHvqLNUNf/168dYO9B+9mv/5oafHFzVnxP323zkh18afFOVHr9XOk
uvabLn7su3FXvKtb0xABQQAQ7vr69u3X2SMKrntFUvrdq/OLnEBliWGKzxtL
HG+ZdVUCXHFbrzeDS5RM8cG065Ek9nnKNcXV0jZOZSYlV1tcVXU1ZaqP9Z0t
PtTtnbs3e9tPfv3JDDiD/2v7daM/ejqCiN/RyT9Hx48WSqn4FAgB4n1+8/H2
7c2/wXhDtaU/I+fJZ2G+P78+z2lLs9CB0bruRf5u+m7oyq4pTjG/3T3LgB/M
SKI2FB8sbWHsD/jnz4vXz+77a/zz6fqvbz9eLX6+/fE4GVy5IW3HZCBtbFtn
s73Fny8L/Z3UeLezPazNsW3xo5/Cayz815/f3n789PQ5VOOyqduy661w886W
9aoumZykBfjXBX5+VZXbejHYfusmCuD643si4EAWgjTBZzzwzPLe8IhEu97G
l94TFWuWjPwQzkmCn2Y+THxM4V1f3Fwd33B5sTPHtpnt57ozZOfATQAH12SQ
wSTEWWQiDRlQRgdXtDf6ui5x/KeY8SVtvdy0NGZTfEqHf4YY//JUs9lisSjM
0g29KYnJoFRwJMXJ1PSfFLUrHmoyR3vCI/fdna2KBxqnKHUWxgWzBBfMi561
0ZxnbeyaNsLHXRg6K4UKNAqWSrvpyOTZakbDuXG7wybmxXIcinrAzD29QzNX
wF6YmUBFYduOIAGgSFmzriMjuLQz2gh9wJrPSG1s6GVCTuMWa6xqNxByG2u3
ASpTHii6lRcE+jQ7padKolivAGVe7Miy2PCppv32NOkQvvEz+o9tRfCnpwPT
r14WpA8HWh4xz4Y0W2VBB1CXKMjfkLaM2InWk9KRjtbjq5KeW+JMGhqayEET
EzHGHb2zpE9F27WLzbilp+gs2mEGMnVEQ/mOF36Po+9aIs37oTC7XQMC0Bqi
MuAvOnxH89HXtJoDzHdwpERCaE1SK2czYaptXVWEGGcvSBqHvqtGJlLx+KJO
Pn6ZzaKt4lE23UNgqa3ZY7sjuAT780xSuD2Zb2UkUjbEoyTIayLIDtqADrei
r8FY9ExlXdnXS/rKuCNsTYT4mXZNAKrn+Rkc2l522MnhhHmvQNXAv5apT6Ty
DKN0THY0z84aPLCxtEp8M+BcaYnLuhIJocOk/5FqrHgvzLzPSqMXw1Vv/znS
wlgyaQb6iSn42wBmLdxAoxMsIvHt+jv+SthJpqWPdJC1a8y/K3MDoU5wcL3d
NRZyRpQIjE34n1guRSS0z9E0NLAbd2yiEwKLJJ2JIqrqFem8sSGNWDsRoSOE
gO11xHwQ2EYlnCiZMjPexJkJ/KeZiTyrBhOeFVfZ2pTjoBdIkzrhI9IT5DPR
qntmvXYwvwnpXMcPk+6EoqOzfCAyiz7D/OvebEEfVh9zIknd4GkC4ljAvd3D
iWyJx/BvfANCDl6AWBMTXImELbrVQiUs6rNdY0paE219Sae3lcX+96eff8Ki
MKqrB/CJI72NGUSP0SosTd8QgeS4B+UzVgRbZxtCxvIwLY+2OAzM26blJx0R
vAB3yXQPdknPrqFs/86EZup24Pm1CAwdFouHwzEavzSSNVYgFrQhKuRkJohG
Z0IvCw6jh027F0qxuiNilhvwqVKLZr8GTWnNDTP2kVPt6RVRmmofir0lMrdR
3ze0FDo9WuB9zSya/qRPe80u5oUBOC3qCGMa3ixk2RZLgnLkw3i4VXRLV9I+
veYFpwerCc4SDYEB3tiS3B9McWPwJvETfUFnnU8o0YdOT2igsdYkrUQ2fG5I
P5LxIxjXQrfEZQhLrshDxtd4tGuDwHgxJcnE+WdmOhXU1MA6S2xDDxzTtLA/
XbGCuxKF8/L4UeVHEvg2M774GM9S6JYfDtMWgu9VGDHs46Po467p1vsvX/it
x8fGVJXtv3yRt/b8kjKgGA5TyCNz0rbdVilK29l2KWWDOBHndMzUYPYSmhms
XDegL03JdmWucwvN5ARpQc7SubPRJkvIQ5HaopfoIZa4HZAa7KzYh93Y7zq2
0nx+K9IgFnoeslbVZt3SAuvyEqJCp9k9uKCStwQvTVu7reCmxFDCinirLpoe
dkBELtGrNWvZe9ItwHqG9T1rCUO4rlfbSANPOYHp2bLgCdsDqzOc7Bqruj/b
BykRKHdP3ZThPIKphTZEI1gM07NdeugYwRCTgTQZwDoMY00YnHZW4mkcKs7p
cIQn4I8cSyNCA7sFFQEmGugNlkrmQtjsumdz6RY09YKHE3/oyxfaqi0NAZ8w
C6lbmp5OmnVGsTY7KOYHa0Xk6WQZRlbFhmwR/dmP7doJe7qN6XcCKFTJqz0k
JmaFoqjpwNZBi/ODKcLY0iJcjWOkN72dKo4gTZbSo1qi6mgXkA6RS5r0PsR5
5liC2lhvSNkFV7TCyETMxU5gpBoHjnAyxIEuW8ODFpAbZgPrQlRk/y3CleIP
JKJA7Io/14AG9LIgKZKKkc2Q2C/LU/La2dmiL9eGjOygIhKGxYJXI2gZZ3Ae
xENI4P+cASJ/jjppNmOjeTm7JNMfAb3yo9fNzDwkdvo1/gS1Sloxn4eH0PQl
2xHnulKkzCZ4258asSixXk1qRiaraPBS3YQrtvAKi+csJdgr3MmzFL3LgkuE
VwnyEtsMdgX2OE3fIHVPFgDaekPKAOMh1kOKlQB+05V3vIutd+OBG/pKvSeB
TK446mGy2PDLAtkZ4EIvmCX2h6FcN/a85Fv9EwuGqCakwpmwWpeDzE0T1B6O
mYaYGGU/EjQZWVVRf8IAyQB80FfFB7Yj4KBj+YPHF2qKRA0m2nZJgO3h/8Mw
qT6xNGmqI8DT/Cz9uBob8emhUUSBLEn1mmEj5oPwLqloSEaOmklxO7C44bQI
Dbiqf6PVnWbG+iV+gNqsh4GUBwkUb7iG8CpOJMmAnJJcsaCfpijgJc36jo6I
lWBN3tremz43MQmscF2yB6IS/TQ2HBBKLTxNNoeZhe8wj6a6sjvbVjTUExba
G0oXfGRgbOWZicWmQ89p5UjgGtLS5t6Kwe5glRNUBlBEnPKieJNiz8cXKTG+
TEdlY588PqEqmQdkk0BU5hJM7MWApSZ8a1SfsoLxoDA+6hUG/Q8OyRL0uWs7
Ug0VWVMfBfPhg4mYnLEvAzXJJFjG8Acejovl88dXcYNz4UsBLuzCpev6huiP
86K51QgajxmgTDYds2zRd8tucGfDbwPrIEILLnAPr+tU+HZHDE/iZIcSgYRV
3bvhZXTE2NkhLm7hevNSmHhGVOcigJxV1zFsJtTnFBScPEu+EwB7iCgCbdB4
9reyGSs4tx12ATo2iLufcE6LBJaVMVGguLp5L4s7OWPWuQmO3uOLAJ6PMU30
CIljYCjE9DI/KWZ2I3P1Vzy74Bg+7cMxmeohml9R1QdjMncovelQsEc+omNc
01uxyXCct4T66FkJc09Mcs5NeOee/PuKzWPLf8ZIDYx3Cc/nK853afq+9hGC
1OnmFak65QiaGCFdCUNiRdUCTPld75HHtfkdxN2BXaCr9n/kIJ5y8TUaUId3
hIkFk3c7Q0BPNyLijhBAIC87GTX98QBo8Pee4LeqLvBtm8UYYFdpB4h3egS2
NXei9eSFxK8TiF07ifQwCIOfQ+4cTkMsVLca4LbQNzSMhLiPOcFsFL0v8YLD
j9EKSfwxfj4mFNkDEAwsyFu3TuSEl06nIQEvF41ePDXAbkt8FVRTlcHcKFfs
p0wOlCFbvU4iLn4BqlvljGX6I8LCOkTEhC0+hxER0yOV2dwbD98TFCtrwasD
uXsrT9pFXP68OGX9Y4q/3b4XcN4jcjj07N72+5eZF4jgIVOsjfqdNDWxTtEa
0hAEORtNThZcGcCBSnrDh+0nPBBjCxN9qNJHSyT9AMklSp9szf5/EZhrT4rT
A3wC9QpB4h0AhxbrkVH0S9FSV+9vbt+++wbOG42wMPX8EOMQ47fi4poiS/8I
113FKNPjiximOMZvSUBK7HbOgGnotKr4rCQ25SPLbq7nHonsodE8HrGF1WFg
Iqd4IjEmgpEn8+JEAtF01CeMB6YWh9jTz0xWizh/QY6JWZCqLe+wyEV44ORl
4lWUZJycchqbxyOcWj4PBrbk6OKbQBOieUKRDjElNlweewC7MfaWfAMUy9rC
4NB/HTnJB+iV+d4Zci1OYH23I61uyVGx/uRQHUCZmoqDc6QYp7SNOPsbvP9N
dFYDqYpAKqQeWpvOz+yGxcfjmDCIVy+K1bB+eUst/y8hAEZsF6Nhx9gu/noA
F+mAjIQERCkMgFMjsRqxXUc+V92yHCrw2XFgUhKSHDOH+wFNr44Qe8hsAnMw
KTpfxt8YIdQSAQ3TEMXtMQxwjFk8Bkic+FpYYGL1wYZtus5pbBULglSV7LwN
ZksiAn0Ex+1T4gMQaTOXQHw18cPYe91tOo79SFrP+yvswbY1XFfZvHIGh3OZ
EKyqJ2ovpkvyUKKL8VpxDWvYAfIlmzQBRYw11G61P0zxcbgMENdpyO2W4TG9
TKjTZcUPj49aF0XOD+2KHhMXchog58i1t+kSfIFd9EBauEXMJDskmGRpV0jd
RzzYZ/wBOfPoIwGltPirv/z0LsxR2YYcMlgHWhPIOrHh6tICgDkufOCcIngn
Siymiga6kCyaTMeRLg6/cDgI9SAcTBWOqZ1+UNmE/0CWBL8JRmRVIXCApic1
SOcq4P1BsLCKHoLfVSeoK0QlkLZXEsp2fcwVg2ZpZh7NdWLYIFso9CPS9DXy
ObDinM+Lvp5IAvIGgnEAcUlBzmZZKqUo+/1uQG5qt4F+jdUEh3H7RKdkzOCT
XybPebFS0EgsrJHyrOFYdcixhRCcDW8qpkgUI8cyJPUmA1aaoTzwwGmpc9Eb
4Dwyd2U57pA9B0vLOHlexGh0lWRNjKOKlP+eX9Hkkry5tLI9OD8+2MLhSMgZ
ofsxxOtVaWTBemFX0YsNZwNaQHI48E9E4/dHgvqBTYiKcwLQUJNb5FsN4rjz
mEHz6PxYDF+0KPt+ceSaSxLUsj2R+HomvP+ClFSMffOZfeAgt0SnH188Gxo/
iIsRIWP+hsM6WbrgeJSen3tg2/EvRNO1AsYNIZT+ZBQ9cj5gvbAyZMTikHrW
84+PuSfyRXPvrXg7ElficJIbuh0CR/0gu03g5JdLjThJ6Gxp05oQD8QUfGGR
YUpO9bKFDQ6tT36rBy9GB9W08wOPVJxslVBojaDeg2LPAIU3E/oG58A7cIdw
lzzYdsHp8NhWNQlwm3d8IAzkozoJyCd5SoIQgatdhiYVKEnuQJEIDQaIAiDv
cTA0xSCRbtqggYvEmMPKSbDjbgrCQS7UUi1RLMalREvW9IouZT8d15UIFiV/
Vww2gumEAIisA9x1b+3YHks1tsb4GUHRCAv/yCSrAlY48KO8i79CRYym2jhx
SA+zEVFYhJP/qYNSWbMqMrrtXb0jS9paPjRINP3yZASEqN2DcOKKC4uJOyXV
M/dkRhnMgjNYhwEp6zG2XJ5Cgl7eMaRBWck8Vjb5L9iIbqzZhe+44Ia0YKXx
U+yK+TjJZ4J+EvsOweGQcZLYLUIEXS+AXKqJNFkUYrsm2RE7QqFYobc7SenB
SyKw2TS+eAkpFMApASXsROEbn3mqvC5tUEdYhFPjSvDi9MOHjy8V4ZaNJKpY
Nc3DGmIUBy4DsygIJKWuNRuuvMaINvVplEyG2dEqoHfYwVFlAXp7bYFDzE2n
Y7pOlpmQMqtsMklZilQvBLhSjWBwzmEiILhdNsGuBEGX4iNN8fEcTpEQSkya
ZuFHBxU5PF+y1t2Q7I8lOyQcyDbLHn645aVr1kqmEhDFtos2CC7HIXt35Fjt
hJEtf+PCAUiloMRoSUA1x6PY0JNNGX4cduPgZZk1K+PJSvKoD33nU8tRd7OT
mASReEGyPK/L8RWHAHPuJKI9kKwjPsHKjVgCtUFpkC7G3Y7meSXtiaNtFZ3U
Pm79gCEEpSQhOy0UC/zQ41T6o5HGpCRT7L8Um7lNvcNi3/qE6d+R8H984ROo
auyT3KkbydbskS1kl4ftKJl+QDuRRq/sdLM043aSHuLKAucdMGSf5X1wA1sl
caRCkiiWRYirmdRGRGmrOh4vIIo9dF12jE8hFql9womZ9o5VswZs4TFwBYjM
kVRERB0VMs38fQrfyOCCAYQ1JDTwpH/3L7h/81BN6IvjLs4vLqJLIS6utK6g
FuMfbfE/BGbAO1r1KW+9/v77P80F3JqAyQTiigVHhJH9KFhc2ngVZBmy5JX+
+2e9Q80E+RfJcJKFvpdikWed0WApQ82ZbaD4XacY4g87v3PUrcKxRNRTk9QT
TzIEAjQukWtCjgvl/tJDolEqMPBX/MXEB018N858DHbN/l+QsHlOM46AwlzU
rSQM3JA4kl5jstf4jUv9SS2GpfVtSQSCm84s0liDgYh5DQpGQ81qkFDRvLk1
50LGVd1v47zR+XIKr+9klxpQEZyhAB5xEg3McmxXeB4lI7Twq/dZt15WQ1Kc
ygsvhcE4pyJOIXStuC+B9g8tw7fOF1n4Gq4abDtwUelXi5rnk0ImTEAL9KFB
5XpfGkVSXg/Bd0kLaYrTx8ejPWxfvrz0OFkEJq2pKLTrEAzDGQoTg+CK9k3P
gKJi4XF+exoYT1yENCaufEUr5GY5cTfCCR9ZqTyXLNWXfwwch0/rtoZNz7iQ
Rv/r5883Wlmi0cXwE4EP2/owYMwEe588i/uwhLFykrNXhy0LQ8eggyh9raEA
TkLexjQucdsuEzUUwD/I9aun7X+2v8YcHqfKLMtYKJfluLOkcZ5IRcxxVlBJ
I7dV0BayukbdSg2rsUN1jGKTrKpfiiJYJ5fjMdVQPxN/EjEPsWM8YWs2SbRi
LpsyKae1XR/CHLSqsY1hX9EWp2r5uDAJ5pYWRDt+qdhdiiG7NQRNRBvtkyLY
P+9IGt7U63pAB5U0xflOuOIUz70k6uBf2DSD/qtJ4w8qd2mRaJKcS3yZuzKb
CIdXUo3SS5VgLDli5Vfp3FxRBBx1E+NbXLW1qZdSPCZ0rUaGBjgAYX0fdZTw
eUXMo7gS+aFjGUUxJKTrSS2yZkEnDbPXkIhyjRwFQ0MOZWmeCJkIn+Y8xFqC
ewaRAivWDwpc9XAuEtrJkIblXB5jjT1AaQotdm5MtoRX+rFR4iSoNcbCvGOo
wVSLCBsaOiT0IL7itCHBxwRS/x+6gOsu5FBRqMw2BsffOMkzxaaEM+n3zU00
G0rOn3pjDeIZ38BT+zjCCnGVoouNEiIEmmahoX31D7/T2BUjQomQJ2fEW0Yt
SqEhO36ME9RZi4c39MlYocpu2SnPeLeFUXs4hRpgWYSBt3txdpFCilYaUMUY
wvLlqaN058Y3nmHfh+JuJD4foz3TRquMt+Qb2b81QHWTtq2sHlyfVgqqunhz
84toi2dbjklP0D9RTUy7NDM7l4dQJypF9Yg4/4P5rWu7rcTeWSJW7JgytAcn
AToQazrkXAs+qNqFcs/qMknxSogTadlYEMrOqsSfWMcMoZeQTsqNvXpA82Ai
wTPBRtKPKOS0uyFTPb1dj+q5RY1C9Pvxzc1tKJJ++zfAlStuyZCDJd5BHZMq
EnF1RR1EqyjFPaGRyvdDIY6Ic4rgUFM5D2bPzqe+4BKTLv6Tn0J9QULarMNI
9e3dcc0FVXXG7e0C9WDGQw37KO4Oi8ZUChWSySlC5aCxSUvUkrIREzO/7IG3
Ik9eUF2XVFmp4i7YWrqkVAOOkJwMxyJ88X9f/IPMtavq8oAL+d2l6k4FkLL9
RNHmQXQNlLaHEpgk53xgAg5zUiKiaa5QrYItCcHSrCQrZjr6AlKRy0ze+gFV
uvCFIYqsVMmyT8UFwLSlD7VWFomAHxqvgFoSHyiqwJGjz3miK2jNgHwyaDPx
ybrY9eBNDPuzXJ/D6uaaIMZbwif/QtN+cSovQQnx7QFQQ9FScqUTdNJBx7x4
5ucCXYQPUQZ5eGFA7zWU9j8w9pC6j5JRWp3cRsGs5KFXfu+IJjqCzN++eSeF
IppUz4Qp1HzHDAyP2iBReYlt0esGi5G0HwfH//r54wcpcnfF//l4Ew8vtLdt
bVVLeXkQJvYTdSckUuS9SdG7RFRqTkxanxkoybMLdf8RpRxNJUsWOZEZTVoF
W2lw3oGILsVs3KqLAAcvUSqy7ETItclgl6LGNC+mbWIJjpwK/aq30qaXNk4w
K8BT0U7uyu6aDmLSfQX+0Zrv635IEpeytbRlUCnH6FIc+XaS42ThfKjhvSDw
chmE3RddB9XM/ACYsfehy8A0W9PfjTvvF2ZpJs5YPHiRZ3vJBags4Bpm9aEL
OkhNFP6gsTuwg8ibdh64wIK+kshrPxLwEASANdXAsCqWubBIBgwUFabOU65u
AoLiKHG/DbkC5aGgTf4IlAJaJRJy9WaaxD2iKHyBEvSID+79wJ+ICLa+t1U8
EJCxqiVexccMMofAuW8zxl0Cd6Lz5NYMQVlfvVuDxElu+XgabKVXYiicyko/
HPcgp6VAPlNutFeEOxhsr+zCsSuWkgWtfgF9sthKCZY+znCEO2AkyDP3QSCv
fyOyouF2XetCiqtPNstv09o40kOLukJ8h1b6Jy9Pb//2jQse6yfpGv1InG7R
+bLb82p8X869Dc1JvvhJ+0x9PcC8+HWototkBb/OC/UOXoNnzkmV7kIpIdrO
tzuiWNROACak+bTi1PB1TL6xZp8lV1Cu7xvwVP0yr3HWBtXtbQywBqWcC4fs
y0Vhhv5CDNNHZE/kUE5iRDYLPmqlchL+cer4LGJ229sLnBrkRTwXJ74vl1XL
yJnimysLF2VTb5cawZSNE3UbcjWB0mKvHaKb3BOgjVfikIeE9aXqpSxyTBSX
OHSMnj/d8xqA7cEBe3HQkiVEinJkxTWuYqpRKjuf+upZIRQXqezxXBg1rSGd
1CGCi/0ZcSO4qmCEwOCh5OhsnpYf+tDR5wOu+AO6MnqbMcSUit0TIabY0smF
DKHludIidDoRX0NYcY2gOj2inTnWS/RY41Q4vBJr9OoheNDCOCqpwgctYsJq
hlm8fDk5eVPw2ujhv6CA/U44nMt8JDygSkkquLngYi6I1HF9jdQHwrUR99mn
2l5k1/fEv0nVxtuEpKrPTPyBGGlhtaiAKFhhNDxp5z+dJ6L8XOyv+iNcw0Se
B2c0l+oOmX+ggEpiyLZdc/Q55dIJuPVGBQqH8Op6EkDytz6wS9SHSypEdV8W
v+o1R6T7fuXQLK5Wwwftn/wgP9/QL7/O44UfAFdpDC5JAcIKZp3lktGAH86d
yV5bpoFgb3vXwN5EgZbZhNONwCvh0pKseEULQFwRb20SfkUvLyarm2aEl+hL
QTjbopdfJJo2a7slveVTutMLoNL0Ge5JMeGJ2FfH2/A3xnRFvGgEVnHY76Rr
poDglN7OkSE5SSp9d5veSPacMQUqwrJrPlpmdFS1SAI/2b3HQYzijA/ehYKR
p3Nx8zw1y7atjmkxiTwR3lu3nNP08zAniV5WZzZvfk1SHIdulQ4yV8WTa/Ch
6yDoITroF8UaweXh0F47JvyquPnMl91IANx5vJmERpMsOCEheo6xtRliwNBT
xaBwgL3pNmroQhL3iAgZLjnmTFre35bzxdca2mPSOoDUWCLH9Qokb3oPSLRI
nMyUsDNUQKK/kPqK+xUFxV3CpEPYbZC6jDCSiiLXhyK1IsSWOKMURcj1Nv8k
PY6Kvlih7cO6or7gengsj3tvEswSCipRy8517KTQqmnV7hFjiLo3b9DYKu7Z
mkVVyEY2sH2eTTW+oZ3hBzCm9r7qHTdc8SqgAqK9JBmRCwiya5i+zJUXpXI1
IS0KXdKOK3ngwPnP3OJj94f4mGu8rk1jr8n9bQGiiYZ/fNTb5rC83MIMkzeP
3PymlYZJtQIdy/tPPxev//zdt/8xl1SLdwEXPpKW2MBJPDZW6ul9A2Sko11K
KrMg0dLRddQmVSU/dylf/DpP1W4abJHAknda0NpUiw8akut5pXwYOBo90lDj
chFUfDKR0aBxEGJ1aDuoYmSpY+CB6+26pCMoxE9CT72G3xJljQWJKz3PzomV
LWK3oGGINQXfTFDnEZs7QbKaUwipuGlAMJZPJJrNhyFIHkbN5nITXSiUCso4
VGgf0FQ2gNiNhG2Cwff6GXWWuc3IhffAGvyQxSsMh20WXCoXHX4aNFyl5w44
KF5rhXqTJE9HemU19gm2yi2iBJrHpInUZ4fcMJZ3vvjON7Wybv0mxKsQKY8H
q1ZqPdaV0YAXR3U65GF970/Nui4NR3BYWqiJeIvnTaG/Trzm7oV0sYxB1Edo
Ow8BJCfgryND9RVbQc2Z+u4SHVQ7C/A0ozI87rLUav+82g5AeBGUlroS8zTC
fOrTFdbcqXLEYYbdxvDSSx+EnpoCJZVKyB+JAkm0+eLmSjTsv33/5OMj/hXv
YGx5/4mbjJKoqa8cPcgYV2IovEjy/rQI3UwM00jHhxY5pFVKrZ2GL5nTk2YE
NTy8EJ8ChgskT+cJQE3xYFvs4Llpd4s6cRyrJrRTr6zcpmHyhP5cj5BZ6ViT
Gz8FoeBmOWncrrh6oSAxQDfYD7JswBK+IEYkkqDDJrieoVs6roRb0hb2vpbr
KULOqIUyBJxhHsicguR6k2wsvYZG+t00+S2Nw5qEntCOM1iweUmFaEi3qJgE
aCKxR8EKmqeHJtSa7qQd3iPVfC5k9iyyAb33V5LGIi66OX18TLobv7zk2he1
b5Jy52Pxjn3WAHSs1zDvRvy3uh39ufcK0pjLUl7kmyRkxxom8mEPi8wgB8i5
FZ/fwUZMs3owfOVoWFqag/IZ9lgsxqyLYrNqsp64vfxrFm298UgyF3NVRMMT
jxM05Av7+iSYJ7Nu0C7Q7ouQrvOU4YLaK8cUUUvhy+HQqox9zX2ODvV3COWI
DGp3pDgGaUuH1PjpcpSMscwBsTqpwCdLVYmoxepE/MoN3ezhtHxPLx8j+XOk
pn0vdWxU9XYxumsHhRhcg6CltsUnXzxFyhaelIaPDq7B0uq75EI6VQNJL1go
+xXZUpczlHPq1VjJjVkPdS+5ODOEDrpQfCslG/YhvBpvMMD+sW4bmVI2UWab
UKYD63uI66scJ3fD+e3Bxqd9Boh+yxUHWkE/bTqYNuz5iwnAA4keOFABqtFo
72sWaJFsFp6eZEpuXJWM26DVT97D4qCVSLa/8+JINettBLyhycf7Ogwz09sh
s3x3rYW0cp2cOGtz757j2n7NM3gXsluqr4Ps2qX2NU7ur5knAfDD6luPh6UC
9wepVgspNMUsLAXcL9rg2qgHYgobUqO0y7cM4qKxDeaePchQpv8FV9WgJIFV
3sZo001MRjDCkDPX+48EdmXKRWtK8jIB9uSTS3EF0nBnpdYeBKEHS1tt+kf+
y9+hWREZyLxXHGjv7bYjeBngvpl2xUudKWdg5bqJtGM2NIvARoDMUr4niJ7T
z71iEODMHfeaAPrZVixAMpUWLeFbDR8o32n4LDB+VjOJHg/p79Vig5QVNcHJ
+FfCgf5W0VAgfNJ22ZVmXgBO+IhOkp+YUJn0nAAEWufrCdJm+4PdaQYs0quV
9owcwACxS7exj1T45HJS2h3czaSSO7mmBJjpd40QZzKp14ClrZjpTRr5tRvy
SdJKHjDFWwnmeXhj0r8RAh16iUnX+dTKwQUDco1BX6mqKeV+gKbztbjch7r3
Wes0EsMTSBdmKiBSChx9Rr/2eOMO4YzQpxKuB9nYUW4X4GtmyBphs+x40HFw
jrWRHulCS6jyHjCXd5Ie70KcJ7XIf+jGSyKoCyXid9A1K8Osu+80WSOenkBE
39wT4wQwyWy8QIgx9CL5PgvGr0cOhL9PTyUtsxPDII1vQmtt63KD9bDOE3Vp
N+a+Jn7/gbYC6Gp6ScyU+D+40ZSc4/p/EpmRI8g+zHJvkx4/PazD6zL1wux4
z6GUUpAc7lCXZ/1+1U8OfY0e2JsQD8CN6ahxhsLVHaVtgRhnaVzt4k2pqXl+
Uby/+unqK+hGZEee1DJmuQGx9DeeMSfMHi+l7dVW/3myIsVtT7TtSwwahy7u
XHFjq74rfiZL8XvxaSRM8fu8eEsnWXyqt76/4HoDru522OG7Bm1BeifAwD0K
Pakd++B8c1tyiazwFz3ixvWa0AGQp161g0XjOnvksWb/D8dUCyYHagAA

-->

</rfc>
