<?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 3.4.9) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-vaughan-machine-readability-01" 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-01"/>
    <author fullname="Thom Vaughan">
      <organization>Common Crawl Foundation</organization>
      <address>
        <email>thom@commoncrawl.org</email>
      </address>
    </author>
    <date year="2026" month="July" day="24"/>
    <keyword>machine readable</keyword>
    <keyword>usage preferences</keyword>
    <keyword>policy expression</keyword>
    <abstract>
      <?line 119?>

<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 resolves the term into two core criteria,
parseability and interpretability, which are properties of an
expression itself, and three further dimensions (discoverability,
actionability, and verifiability) which are orthogonal to the core
criteria and to one another, concerning as they do the expression's
place in a transaction rather than its content alone.  Together these
determine whether an expression of preferences or policy can be
reliably acted upon by a non-human agent without human intervention.
This document applies the framework to 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 136?>

<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 whichever property is cheapest to provide, typically parseability, while failing the ones that actually matter for automated action.</t>
      <t>This document separates "machine readable" into five named properties, of which two are core and three are orthogonal to them.  The core criteria, parseable and interpretable, are properties of an Expression itself: they can be assessed on the artefact alone, they are defined in <xref target="core-criteria"/>, and they are where a claim of machine readability is actually won or lost.  The remaining properties (discoverable, actionable, and verifiable, defined in <xref target="dimensions"/>) concern the Expression's place in a transaction: whether an Agent can find it, whether it settles the Agent's pending decision, and whether its origin and integrity can be established.  Each can be present or absent independently of the core criteria and of the others (<xref target="independence"/>).  The purpose of the framework is diagnostic: it allows a given mechanism to be described in terms of precisely which of these properties its Expressions provide, rather than asserted to be machine readable as an undifferentiated whole.  The framework defines no conformance threshold, and must not be read as one (<xref target="no-threshold"/>).</t>
      <t>The framework is general, and nothing in it is specific to any subject matter: an Expression conveying bibliographic records, sensor descriptions, or recipes can be assessed against it as readily as one conveying policy.  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 distance between the core criteria and an actionable outcome 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.  One boundary is worth stating explicitly: non-deterministic processing, of which interpretation by a language model is the current example, is out of scope as a means of satisfying any property defined here.  The framework concerns what an Expression makes deterministically checkable, and a process that can return different answers to the same question determines nothing; <xref target="requirements-for-legal-terms"/> sets out why such processing also fails, on its own terms, at the scale at which Agents operate.</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 structured information.  This document is concerned in particular with Expressions that convey preferences, rights, terms, or other policies about a Resource, but the framework does not depend on that subject matter, and the Expression may even be the Resource itself.  The Expression is the artefact rather than the assertions it carries; a single Expression may convey one statement or many.</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>
        <dt>Mechanism:</dt>
        <dd>
          <t>A specification or convention (a protocol, vocabulary, or metadata scheme, for instance) under which Expressions are produced.  The properties defined in <xref target="criteria"/> apply to individual Expressions; a Mechanism is assessed indirectly, through the properties that Expressions produced under it are able to satisfy.  Statements of the form "TDMRep is parseable" are shorthand for this.</t>
        </dd>
      </dl>
    </section>
    <section anchor="criteria">
      <name>Criteria for Machine Readability</name>
      <t>Machine readability, insofar as it is a property of an Expression at all, rests on the two criteria defined in <xref target="core-criteria"/>: whether the Expression is parseable, and whether it is interpretable.  These are intrinsic.  Each can be assessed on the artefact alone, without reference to who consumes it, how it was obtained, or what its consumer intends to do.  Interpretability presupposes parseability, since a term cannot be fixed against a vocabulary before it has been recovered from the artefact.</t>
      <t>Three further properties matter in practice and are commonly folded into the same term: whether an Expression is discoverable, actionable, and verifiable.  These are defined in <xref target="dimensions"/> as dimensions orthogonal to the core criteria and to one another.  None of them is intrinsic to the artefact.  Discoverability concerns the path by which an Agent comes to hold the Expression; actionability concerns the relation between the interpreted Expression and a particular consumer's pending decision; verifiability concerns whether the Expression's origin and integrity can be established.  An Expression may possess any of them, in any combination, at any state of the core criteria, and <xref target="independence"/> illustrates how they come apart in deployed mechanisms.</t>
      <t>Assessment against this framework therefore yields a profile rather than a score: a statement of which properties an Expression provides, and for which purposes.  <xref target="no-threshold"/> makes explicit that no particular profile constitutes a passing grade.</t>
      <section anchor="core-criteria">
        <name>Core Criteria</name>
        <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.  Parseability is a property of the Expression and its grammar alone, and can be assessed with no knowledge of the Expression's consumers.  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.  Like parseability, interpretability is intrinsic: it is a property of the binding between the Expression's terms and their published definitions, not of any particular consumer.  It neither requires nor licenses interpretation by the Agent in the natural-language sense; where meaning has to be guessed, inferred, or modelled, the criterion is not met.</t>
          <t>The division of labour between the two core criteria is an old one under new names.  Parseability and interpretability stand to one another much as structural interoperability stands to semantic interoperability: the first is agreement on form, the second agreement on meaning, and systems have always been able to exchange well-formed data that they do not understand alike.  <xref target="RFC3444"/> draws the same line between a data model, which fixes how information is encoded concretely enough to implement against, and an information model, which fixes what the modelled things are and what they mean independently of any encoding.  In those terms, an Expression that is parseable but not interpretable is one whose data model is shared while its information model remains private.</t>
        </section>
      </section>
      <section anchor="dimensions">
        <name>Orthogonal Dimensions</name>
        <t>The three dimensions below are not further degrees of the core criteria, and they are not ordered among themselves.  Each concerns the Expression's place in a transaction between a Declaring Party and an Agent, and each can hold or fail independently of the others and of the core criteria.</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".  Discoverability is a property of deployment rather than of the artefact: the same file is discoverable at a well-known location and undiscoverable behind an unadvertised path, without a byte of it changing.</t>
        </section>
        <section anchor="actionable">
          <name>Actionable</name>
          <t>An Expression is actionable, for a given Agent and a given pending action, if the interpreted Expression determines a definite outcome for that action (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.</t>
          <t>Unlike the core criteria, actionability is not intrinsic to the Expression: it is a relation between the Expression and a consumer's circumstances, and the same Expression may be actionable for one Agent and not for another.  "Training forbidden" is actionable against the action "train" and silent against the action "index".  The scope of application is part of the same relation: an Expression may determine an outcome for a Resource as a whole while determining none for an excerpt or a derivative of it.  An Expression that says "use must be fair" might be interpretable, but it is actionable for no Agent, because 'fair' is not a checkable condition.</t>
          <t>"Copyright in the US has run out" is an example of something that is interpretable but not necessarily actionable, depending on what you are trying to do.  This ties to verifiability, since one would need to verify such a statement in order to take any action at all.</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.  Verifiability is independent of the rest: an Expression may be signed and bound to its Declaring Party while remaining prose no machine can act on, and a perfectly interpretable Expression may carry no evidence of origin at all.</t>
          <t>There is a weak, implicit form of provenance short of this.  A Mechanism served from a well-known location, like robots.txt or TDMRep's <tt>/.well-known/tdmrep.json</tt>, carries some evidence of origin in the act of publication itself, since placing a file at that path is something only a party controlling the origin can do.  This is an assurance about who is speaking, to the extent that control of a domain identifies a party; it says nothing about the clarity or validity of what is said.  It also attaches to the act of serving rather than to the Expression, and so it neither survives redistribution of the Resource nor detects alteration.</t>
        </section>
      </section>
      <section anchor="no-threshold">
        <name>No Conformance Threshold</name>
        <t>This framework defines no conformance threshold, and it must not be read as one.  There is no number of satisfied properties at which an Expression becomes "machine readable", and none whose absence makes it not so.  The properties describe what an Expression provides; what an Agent requires depends on the decision before it.</t>
        <t>The threshold reading can be abused from both sides.  A Declaring Party may claim machine readability on the strength of the cheapest property, typically parseability, while failing the ones that matter for the consumer's decision; the survey in <xref target="existing"/> and the discussion in <xref target="requirements-for-legal-terms"/> are largely about that direction.  In the other direction, an Agent may disregard an Expression on the ground that some property is unsatisfied even though the properties its decision actually depends upon are met.  An unverifiable reservation that is discoverable, parseable, interpretable, and actionable for the pending action still communicates the Declaring Party's position; the absence of verifiability changes what the Agent can prove about the Expression, not what was asserted.  <xref target="security-considerations"/> discusses both hazards.</t>
        <t>Whether an Expression satisfies a legal requirement of machine readability, such as the reservation "in an appropriate manner, such as machine-readable means" contemplated by Article 4(3) of the EU's Digital Single Market copyright directive <xref target="DSM"/>, is a question of law on which this document takes no position.</t>
      </section>
    </section>
    <section anchor="independence">
      <name>Independence in Practice</name>
      <t>Real Expressions satisfy the properties of <xref target="criteria"/> in patches, and the patchwork is the point of assessing them separately.</t>
      <t>The Robots Exclusion Protocol <xref target="RFC9309"/> is highly discoverable and parseable: it is fetched from a fixed location before any other resource, and its grammar is defined in ABNF.  Within its own vocabulary it is strongly interpretable as well, since allow and disallow against paths are terms whose meaning the specification itself pins, and two conforming crawlers assign them the same meaning.  What it lacks is breadth rather than rigour.  The vocabulary is confined to access control and carries no shared semantics for what an Agent may do with content once fetched, so for a usage decision there is nothing in it to interpret.  It provides no formal verifiability, and trust derives from the authority of the server over its own domain, which is the weak provenance of <xref target="verifiable"/> and nothing more.</t>
      <t>Conversely, a cryptographic provenance Expression may be verifiable and parseable while saying nothing about usage permissions at all, and so contribute nothing towards actionability for a usage decision.</t>
      <t>The value of the framework is diagnostic in that it lets one state precisely which properties a given mechanism's Expressions provide and, more importantly, which they do 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="criteria"/> are general, but legal terms of service are where the distance between the core criteria and an actionable outcome is widest.  Terms are easy to publish in a parseable form, and may even reach <xref target="interpretable"/>, but in most cases they are actionable for no Agent: 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.  What works at that scale is low-context communication: an Expression that carries everything the Agent needs, fixed against shared definitions, rather than one whose meaning must be recovered from surrounding context at the moment of consumption.</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 which of the properties of <xref target="criteria"/> their Expressions provide, 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 narrowness by design: complete on discoverability and parseability, strongly interpretable within a vocabulary that extends no further than access control, and silent on everything beyond it.</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 carries AIPREF past parseability to interpretability, 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="interpretable"/>.  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 its Expressions go furthest on interpretability, and furthest towards actionable outcomes, 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 in interpretability.  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="criteria"/> 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="interpretable"/> 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 profile against the other properties is 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 or other kinds of assets, developed as a technical response to the reservation contemplated by Article 4 of the EU's Digital Single Market copyright directive <xref target="DSM"/>.  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 answers the crawler's question most cleanly: its Expressions are discoverable by fixed convention, parseable, interpretable because <tt>tdm-reservation</tt> is a defined term rather than a guessable field, and actionable for the Agent's purpose because the 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 its profile is much the same.  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 is parseable and nothing more, 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 verifiable dimension.  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.  Nor is a manifest confined to provenance history: the Creator Assertions Working Group defines a Training and Data Mining assertion <xref target="CAWG-TDM"/> through which a manifest can carry usage preferences, stating whether an asset may be used for data mining or for AI training, including generative training, inside the signed envelope, and this brings C2PA's verifiability into direct contact with the kind of usage signal the rest of this survey describes.  It is worth being precise, though, about which part of verifiability it delivers.  Verifiability (<xref target="verifiable"/>) as defined here requires 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 anchor="the-fair-principles">
        <name>The FAIR Principles</name>
        <t>The FAIR principles <xref target="FAIR"/>, under which research data should be findable, accessible, interoperable, and reusable, are sometimes offered as a neighbouring frame for this document, and the correspondence of names (findable and discoverable, interoperable and interpretable) invites the comparison.  The two are not functionally equivalent.  FAIR states stewardship goals for data and for the infrastructure that holds it, directed at making datasets reusable over time; its principles are aspirations for an ecosystem rather than tests of an artefact.  The framework here asks a narrower and more mechanical question, whether a specific Expression supports a specific automated decision, and it can be applied to a single artefact in isolation.  A repository can be exemplary against FAIR while every rights statement in it stops at parseable, and a single TDMRep file can satisfy both core criteria and be discoverable and actionable while participating in no FAIR ecosystem at all.</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 properties with one another 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="criteria"/>, 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>The converse abuse is dismissal by threshold.  Because the framework defines no conformance level (<xref target="no-threshold"/>), an assessment that an Expression lacks some property is not a finding that the Expression may be ignored.  A party wishing to disregard preferences could otherwise hold that nothing is machine readable unless it provides all five properties, a bar that no deployed mechanism meets.  An Agent that declines to honour any Expression short of, say, verifiability is not applying this framework but exploiting it.</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, Christopher Flammang, Alissa Cooper, Henk Birkholz, and Carsten Bormann for their reviews of this document and their suggested additions, and the participants in the discussion of this document at IETF 126, whose observations shaped the reframing in this version.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC3444">
        <front>
          <title>On the Difference between Information Models and Data Models</title>
          <author fullname="A. Pras" initials="A." surname="Pras"/>
          <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
          <date month="January" year="2003"/>
          <abstract>
            <t>There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models. This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin. This memo provides information for the Internet community.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3444"/>
        <seriesInfo name="DOI" value="10.17487/RFC3444"/>
      </reference>
      <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>
      <reference anchor="CAWG-TDM" target="https://cawg.io/training-and-data-mining/">
        <front>
          <title>Training and Data Mining Assertion</title>
          <author>
            <organization>Creator Assertions Working Group</organization>
          </author>
          <date>n.d.</date>
        </front>
      </reference>
      <reference anchor="FAIR" target="https://doi.org/10.1038/sdata.2016.18">
        <front>
          <title>The FAIR Guiding Principles for scientific data management and stewardship</title>
          <author initials="M. D." surname="Wilkinson" fullname="Mark D. Wilkinson">
            <organization/>
          </author>
          <author initials="M." surname="Dumontier" fullname="Michel Dumontier">
            <organization/>
          </author>
          <author initials="I. J." surname="Aalbersberg" fullname="IJsbrand Jan Aalbersberg">
            <organization/>
          </author>
          <author initials="B." surname="Mons" fullname="Barend Mons">
            <organization/>
          </author>
          <date year="2016" month="March" day="15"/>
        </front>
        <seriesInfo name="DOI" value="10.1038/sdata.2016.18"/>
      </reference>
      <reference anchor="DSM" target="https://eur-lex.europa.eu/eli/dir/2019/790/oj">
        <front>
          <title>Directive (EU) 2019/790 of the European Parliament and of the Council on copyright and related rights in the Digital Single Market</title>
          <author>
            <organization>European Parliament and Council of the European Union</organization>
          </author>
          <date year="2019" month="April" day="17"/>
        </front>
      </reference>
    </references>
    <?line 302?>

<section numbered="false" removeInRFC="true" anchor="change-log">
      <name>Change Log</name>
      <section numbered="false" anchor="since-draft-vaughan-machine-readability-00">
        <name>Since draft-vaughan-machine-readability-00</name>
        <ul spacing="normal">
          <li>
            <t>Replaced the ladder framing.  Parseability and interpretability are now defined as the two core, intrinsic criteria (<xref target="core-criteria"/>), and discoverability, actionability, and verifiability as dimensions orthogonal to them and to one another (<xref target="dimensions"/>).  The former Separability section is now <xref target="independence"/>.  (IETF 126 discussion.)</t>
          </li>
          <li>
            <t>Added <xref target="no-threshold"/>: the framework defines no conformance threshold, Agents should not dismiss Expressions whose relevant properties are met, and legal machine-readability requirements such as DSM Article 4(3) are out of scope.  Added the corresponding dismissal-by-threshold hazard to <xref target="security-considerations"/>.  (Issue #3.)</t>
          </li>
          <li>
            <t>Made actionability explicitly relative to a particular Agent, action, and context, including the scope of application.  (IETF 126 discussion.)</t>
          </li>
          <li>
            <t>Generalised the definition of Expression to structured information in general, keeping usage preferences and legal terms as this document's applied focus, and noted that an Expression may itself be the Resource.  (Issue #2.)</t>
          </li>
          <li>
            <t>Added Mechanism to the terminology: the framework assesses Expressions, and mechanisms are assessed through the Expressions they yield.  (IETF 126 discussion.)</t>
          </li>
          <li>
            <t>Added <xref target="FAIR"/> to the survey, distinguishing this framework from the FAIR principles.  (IETF 126 discussion.)</t>
          </li>
          <li>
            <t>Corrected the TDMRep description to cover assets other than web content, and added a reference to the DSM directive.  (Issue #1.)</t>
          </li>
          <li>
            <t>Noted that crawl-scale consumption requires low-context communication.  (IETF 126 discussion.)</t>
          </li>
          <li>
            <t>Noted that the core criteria correspond to the structural/semantic interoperability distinction and to the data-model/information-model distinction of <xref target="RFC3444"/>.</t>
          </li>
          <li>
            <t>Acknowledged the weak provenance implicit in publication at a well-known location (<xref target="verifiable"/>), and tied the Robots Exclusion Protocol's trust model to it.  (Issue #5.)</t>
          </li>
          <li>
            <t>Reworded the "use must be fair" example ("might be interpretable"), and rewrote the Robots Exclusion Protocol paragraph in <xref target="independence"/>: its Expressions are strongly interpretable within a deliberately narrow vocabulary.  (Issue #6.)</t>
          </li>
          <li>
            <t>Added the CAWG Training and Data Mining assertion to the C2PA section.  (Issue #7.)</t>
          </li>
          <li>
            <t>Stated explicitly in <xref target="introduction"/> that non-deterministic processing is out of scope as a means of satisfying any property.  (Issue #8.)</t>
          </li>
        </ul>
      </section>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6V9WXPbVrbuu34FSn6wVEXKspPuTuTqqqvITlp97ERlO8m9
TzcgAVI7AgEeABTNuPLfz/rWsAcAkp0+XdUVi5j2sIZvjXs+nx/1rq/Ki+z4
VblytavX2dt8eevqMntX5kW+cJXrD9mqabOfu3xdZjdtuSrbsl6WXZbXRXbT
VG55yF5/3LZl17mmPj7KF4u2vKdXTrzp+GiZ9+W6aQ8XmatXzdFR0SzrfEMj
KNp81c/v8936Nq/nG3l23oZn5+fPj7rdYuP4O/1hSw9dv/7w/ZHbthdZ3+66
/sX5+bfnL47q3WZRthdHBX3r4oiG8tXRXXnYN21xcZTNM313Ju+uSvy249lt
w+zw41YmV/rJHd2X9Y5emWVr19/uFjRJ+k9dlO22afpn8WB5OsdHR/muv21a
fJeeyrLVrqpkvscfbptN9ovM95gvNu06r90feU+fusiums2mqbOrNt9X2fcN
fYYv8J3lJncVf73Z/J8l37jEfWf0Cvoolrbd0O33PNh331999fXXX+s/v/3q
/Fv883r+6syV/WqeO8x7ft8s88XUhbzvacUujujST6/evbngEfR5uy77i+y2
77fdxbNn+/3+bP8Vvv/sw7tnTdFW801TlNUzuVupDM9n1zY6mt1b3JO9OHsh
K+BXi/83z2Sp3pV13jfZdV7XZVXlg6vvsWN59oujS71c5I3PXpw//2Z+/mL+
/G/8Y1e2ruywNPb+X7+6wsuxfqWtLl16dfPLZ+eIZ3Y1bTRt+rZp++5Zsb1f
rp9d/TD//vrHyzdz+nP+4vzF1+ffnD9P1+AVjZL4yN3nRFu/YNF3Vd4eshP6
7uljy/CvvO1u7/O2IILJ/n2W3RADun5w03dl3rfuj+x115f3IOPk6g8lDT67
Ocv+q23WyVK9+Hp+/g1Y7JGlurJJZz+0zW6bfe/qvKIFxAJg4a6u3r3+PHkE
Hu6eEcN+8+z8RbpAyyVek324LYn4S6ZiZYYue+fWt30XyZvsTV6vd8S8j69c
lV0uyqpT9omXq84uC1cMieqtuyuzN66+6+7zQ9kOrv6Y99iD/1e260ov2jpi
Eb+hnX9sHd+WkE/Ze78QWLwPr96+e33zHxBeX2zon4Hy5G8hvr89P0/Xlr5C
G0bjuhf+u2mbvlk2VXaC75fbRwnwTb4jVuuzNyVNYdeO6Odv8+ePzvtz9PP+
6l+v317Of3r3w/QydMtbEny8DCSYy7ork7mFyxeZXieJ3mzLFopnalp863v/
GDP/1YfX796+f3gfit2icvWyaUuh5m25dCu35OUkKcBX57j8rFhu3Lwv2003
EABXb69pAXtSFiQJPuCGR4b3it9Ia9eW4aFrWkXHnJFuwjlx8MPEhw9PCbyr
FzeX0xNevtjmU9NM5nPV5KTyQE3ACVekm0EkRFmkLXPSpQwULmlu9LNbYvtP
8MVTmvrytqZ3Vtn7+PWPLMZf/hRP7/LXH+ZE3g9MMd+vz1zzrG9zBkBzesUc
izzf8N8D/tG7+EMsyd/K35cdrffnRg9pRuP293bZr017h8eZITDY7y+v300P
tGgcb8Xz87Pn519986zDIM9Iyf397Pk36SBJcuI92Q87V+DtpG3qpdtWBNqw
bt3SYX1ovTOmpk1ekwDdYCkxLdIce9Iy3a3bPiYN3ubtXfbqLPvVVTSFsWh9
64ixKqJfEty9G8nQ6393ixaf+zdJ0su8IonY0f/XQwGdk8gpCCfUXara/z4/
/+ph1f7qJ6L06ZUCk79/gBhIqs2r8uMZ/bchyi93z8rKPStcS5rq+bfP/vHt
+bPm95SZXVsuWUWdvP75NLPbsmaVERVmr/GikmZ4k7eVy/0a6+UrgnVLV2VE
0Mtme2ih3fh6WxKYKem/ou9IAOD2V45wJ9iFNrUqeQfK/hGCe+jr/rODQf5c
G8D0y/zt/Pzr+fN/HB3N5/MsX3TEJksS1iAxiLbseIimjzPXZXtHsO5Aw75v
7mgWe+JHmqBwK0Ptowhqz3SWMx5bVa5phiw2M9p7Q9/0FpAuTbPZYGWO6HXd
brMFG82yxa7PXI8vt/QMfbmAOYMvE07PyrohlA10v3SMGQhMLsojmgj9gTGf
kfq9pYfJGNnxItEXm4rgEy8Pz9PV9FC/bzKI9mzZOvrV5bOjLYGy0uwkjJ9u
JHOgJUktP85o9sQJPBfVRkSrWPq8PgqmBQ2/K6uVrEF/25Yl2Qotfb7NCkdj
YryUnRSuW5Kwa+3lfhL6LTxNl4m39afT6POkZm+bdQOli8nQ1DCZI5uMfLoh
YoQcbfDtGXZtWbYi8ng5aG3l2TD2p93RtspJ+hKZ5mSJ5XUnw6Ld4BkwWqIJ
ehrIK/oIVr0h9pM7CJQcFSXWGtREFMO/03PRGtGiRXRD8zETbUn30Y7S1tO8
afvp87T5uy09s6C/srqp57c7knMZ0R59H2TREM3Ib7xl9xCJTX12lFJCvt1W
Tglh1RILkRl5h1UaWYyBeo+Eemm0AFqERM6OhH82rijI3jx6Qgq8b5tiJ6v0
6YmL/vzz6CjAW37LbbP3K7fJDzRT+jrND1Mzfsi6A8lt5RmS9sSOHaTEIdsC
QHS3JUgTPET3FGVHm76gn2hPxxxMG/MT0Sl0FX+fTUsSzyK5ZF/8dy+xoJ5V
S154Wh4jVNnZCLATm8fbnPdCVFv80mNLaYgLVwgp0z7S/4lKC54L8+mjgsck
zqot/3tHA2MhRF9wSnsf+xl+6Hp6O3Rchu3kn4SSZsrD2EjXVfl/Kl56MlRB
vG5DWheERCvhaTpbk76oYyOG5rnLK3pxt9syqo8WWFjpTGRu4VaktncVCRsH
oqTlm1gIqM6OiA+CosJW9EQRfSx++EnsmTgP6Mu0PCvWOWfZZTI2pTjoWAJf
ndBRTkvYEr2SQQDSq/v8oyxd1/DNQFMk02kvASVEdOP7a2IhrA+LTRaNFe4m
2x0DuC8PEDSQPSxw/BPgb9ACOJqI4FL0w7xZzZXDAsOyJGIhuKDd28hg//3+
px8xKLy1c6xQO1JR+ILIbxpFSZ+vaIFku03wM+dvSDRDG/DNNDyaYt+bXMOd
HS14BuqSz+3LBd27hoT7lReaV7cBza+FYWizmD06bGNuQyNeYwFSYm1oFdJl
JquO9oQeFtONNchBVoolnQh6olNdLfr6FdaUxlwxYU/sakuPiLxUVZgdSlrm
OuiZioZCu0cDvHdMovElvds0jmhSttlpUBOEmfNkBb0syPprD95Cy5pFt6R5
dioxQOkeIICyRELgBa/KZZXzghGuoSeJnugH2uv0g6KTG92hnt61Jm6lZeOF
AnOEj0M+3Jb5tux6Jk+yKIg+Zll/2MJAgRiNFL0R7iqnP2kY+AApNGMrY2bi
X1BJgltido71TFfSB+iGKXks4GMFkAnOLiJGnvn5MDgRjm7LCEVMKv6NStIU
zETMMEAyIIIpABNTlACYCxHnopBpvzvBbroLtF3lioU6AMBM7sWLTaAS+3z6
hFHNbVR//mmYSG8lMYoJ6pbTMKZ2HVxl27AHs7RZ1XS9TruF/5QxTTShk5Tm
A0ukqAp/J6MN8OzPP08NLwmujhBSNo2QLmKkI5IBS0evp7f3M3/VgUL6vlIk
wnfipWQbYRqFqh4ZangIGIlshtrv57rF6ujuELHnig1oYV7TMtoVFTRYNsL8
+BcNqMTXRKeq4ZCQT2zXMEigJf30KTy3LGl9dAO2u3bbEJPr7QFYgSVcvq5p
r9zyAtOmLWz2nVeam3JJQtd1GwHxEZSBnjfcJboYmlp4Q77TJQTsEj9iF3g+
Bq05m+oCaehrQ9ZkgVazvBRpBa8MGzyNWhXx5IRsOigQ1QfsswCfdvSAYp7N
jmQQhP9CvoNvAJLTYtbN3N+MxRRMkKweEQaUvrzKFKmrFb6YGwfTIeVBcGPx
O0E2lVQXA44OGnnhiE6gire0nKy7CDvNiCTJ7m91D9gU61hZYPVJlI6kQL4m
tusYS9GkMDkH5SPzC18TKDYyygyKO9ayJKt6IKG8zcwyy+kzFwPbBFs/huqp
SKadX+Lueu1FzeANsVEawXrZ4ErEPPAYVB/m2dMTrG1YQgCLupZhYDenT8/5
deIahHhblMucAL3/CsEI+jzxhzA78BsTCqGOfVnWD7CeKH1T42TdELQjiiVO
yrrbvN0KfFZIo+iPjARWn2ojjJAdaJRvjPH0hobWOXwEVKSobMqkYt0xqe2K
htmgV5agj977QMgMQ1BEabCRfdSKzZmQBRxtxWhSKMTRQAb0IKI1PGo04+vo
a+B+iB2Zf43QHmPjdSRWiF7xzzXLxGu1WUnC7Bh0CVor+ZM8did+PKNsETf+
tRjwaoe1DF8YsQXMLVqDBYf4WtZde2hsWCn8FiKGCt7M6nDBlqzZT/jIMqFe
DwbS9RcjuNJIScaBObEfaLK7lp365ccctsoMv2MfQeZLEpaC2TZlLrZoRy/s
VgeZXITeTCVCOY8EnyrFTuy9IRC9K7ssmRJrbYJjy7ugfnObp2welpBmtyNN
60Uv3dftoXbUucGgnKi24yXwRmdnYvHlZ1kTOy2rsb+FsFzeRqtNmomMHUBA
CD3xbzR7VUKzTAxbWsMcasIoQ63lhs1r+AWeMEu6uqma9eHoiK9fHF2QiRN8
FsnM8yWPmL6gP5cic4kRO+FEcxU0ggCIzJqlqKUyUnfGrySyaL6EYZRzC3Fo
qp0FS0bN/xlLTVA5hNFZ7KWQAWOXaU8ilHcSP0HahXAN9pOAdoH3IQxWFHBk
VM3yjmexsQiH6JhT3W1WDV0smVwIIo8UhRj7oDiBBZGqYIM91vrR+7NJn6Ru
J41NPB+snKCG8gWWL0c4rdm1y8hujDR+kHMAQQKD6YOp3g1aZ2CglUA8i5Iv
2WcUZyuPxfi7SyF2DGP4Qog6sI3Ywmf+Mthjg2/rmkAzQw5JeAA7RGxPm2/D
wdaLJeGJDh9iK0o9jwm7Q1pAVNIrBmacvQkgCr5UGS7LmegF9Nxbk6RCdklo
Ct/nkbMzLzuJtUesYmJS47hhmZL3acZpHTqFmGDUDCK9w5Kb0WwAlakd400Y
xi6saQkPkyFdkGUSvxXb4KfFSsYgE+4HQ8KCJ+zHnqY+/SZT1ADJ8vB0Dk50
fa4aWyU4jf297WvngTj0/bGEgjEMbxAe8ysIeLagJ3HowKvGEuzKYAh+ncof
+vTELwVt39hcgwOua1Y5aEcVfB45BoaWZs5WwQxeegxdyJsRoA3kMXMymFz9
iIH8fIeGlPgWI3tYtr4r1d8K/03nlgMz6nPmb5DBKneEa9g86HYbxrozdv/S
CPbAyQswT1kwAbMyVa867m55hHXBCrBoAF8GsQi26+Bh7Mpu4NAgIYDwqfhW
afhqgKzcxwi3xzCNrq6AQWlktzSyBYCpOrXY/9pskikzBIyjGhEBq58EkhrR
Jadx3MQ9uSKThzc0Vu4YbGJBp7v5pQZ9spcP2vagzSgUMx1MyR4JptBnfsSf
wmsbJSkhHHuHX64se5WGegKIYvYn4Q5U50Ws+g4aEA29CxbigL5fZkmsKH0f
xxsZKUY2hid4Wo6Y/QSOBaVq9DfhkHiZRqNiJDjFg0//isNi7KaGYQKgBGSq
q8y+ffxNSwOPozj0Ff6zYpt0ZgiJDN0XmauqHXzb8NOBLcXXBTsrx3rgW3R/
1RxoxQLgJ9q/5IGJGavMxEGJKKQE5MwcdXBlVagEBGBKHRJA5S2DqUgtG+yP
mGqgdsW5oa7UVWOaTR0xHS3n0L2gyNyMD1EzdRNvvA0QBEBKe4dlAWUIPl63
BPOgIJ5I9opXE6QOEpGMW54ABKjz8dMTL4fp2uWQrYOX0q1Y/om1yByvzMtQ
vf+c693LkYed7CzHbPJMVrwVo3fum11VaGSC9tbUo/wO0o3oHUKTHVq09xta
Rc7IQA7SwIocq6f7vHIF4/qa/zkb2000hps4JD1SpYO3iknd+cGoZsLPQyXG
2JkI4K5uyB4o1uX4dU+DMuo+E6cRAFqM4zM84l1XrnYVu3QUaOuaNOqehHtP
fD38rAVvwioFneWnRnOC1//wJSTxUDRIA0fOP5OxehI/YLPNyd7Uicz8gvmN
5uVyLcxEhIZaQoXqhO7UNRxoG4Aaur4NRgQY0sAffJkpWGF6M6P+NocmJe5i
FwE7gZpVD/8pnEl3pSRQTXnO2dwX/6Xw5XUMeyRWHf6e4s/kBvAoRgQHgoa4
QG48dtqOSvEnROEAasBpBaTjCklWQlAvQvCBxSUrI91RRtBuHUXnbAAxftDP
T/CtCxqqBKCTHJBOE0MMSueRD0jG4jq1z2xt59HwTypklebZz++uxbPVIsjc
E0HSLe3hNBH0iDPzgtWJxx8eBtJiu5asdu/QYZzPMW16wszhAQ2EAFNH+kr8
wjoe5qAVtE4GGUIjPSZt+v85I+44OyFi6ML6OfHicPgsZ8qhf6x37Ig4FXl5
eX3z7vX3T+EPpTfMc4c4xuAdRPi1uNXz1IKj4b/BsFJ4OsyqScDTxaTNgFVb
OIEjMapJpJXmGYn5TZwZkiUi757EYtXJOIF7xMtYl453T11KYNnW8lC7CYec
31XL7hptK9zr5UsNeNnaAWyLFJRFB4fUZD60ahWwc6/CHywIRMcKY7IMKXuf
SnDvvH8bMrZNlmmU68QrTHdXBYNasS3rci/ZBkO9M5UKJWkXA1ScbcDIeXDu
EKDmB9lHFj/I8+5ITyK3c3SPKIOVazuhhTUZGwKOJOtF1qMjoQ34Gl/VldX8
BU2juc3vaYjVPj+obWM8X34U93C2p2WGyxABWfYj9D6ZpWh4rQNb0puIphlk
aTEG4auizfeRxqkgiW0Hcs3MxGZaBhkEpMDOyPmFuRI4bWAcmQOuOlhOChwO
loFionVm0YL4LRMfstwcT1EZCw3xgIh1bPPFCo4jhOxgx9BEKF2Drtj7rg7S
RG+Y9AwKEHoXqzhQJxIsEnkS1oiDW6wwNDQvSR6DCWrgFx4Sd6/+1yfZT8GS
exXsu09PIuNPEx7ZgI1swAVBhD2vBwbq8/VKUFf3iF3hY9ksV9qCTeacDN11
lG3ifQmxnfYFIeWIhoaJErrxLHVkJKV5K9hgRPZV7qrpYK/GdKMobzIzRQuv
4uwQrGH4cworJMkkbpVGwasG1WIQ7t6dEJytGKt3MmgMiF3jlpARbjU3C/0f
UHSBKQQQG8dE8dxg0c4MG0xB+WHIPt2imSS+SuCaYWI8LtpAjw1aNao1egsp
fduIPdE2i6bvzvqPPXvP2bpipx+gHsZ1IsAJHoFZtir7JbQXy8HTAME5HQki
5o69UXCoYPFycfrPfTx71TScsoKohno3jx9dvmPkYSB4qbgA8rHaFWOYccw1
awTsGWRB21zeXMvgjie8HSN1Lna1ZOdGMElJ0fwmF0Ge8moNSYwtQpbcmIGS
mNlBadoTbfWtE4bZ1XlxD7u68wtti5KTKhcfApzq0AyQdsILlyEc++lJcD9N
8UHsnJJkOaEaoS8lDv7FPCzyxMzw9QO+mijq5cFqCA4L3JWUJXaXy05JphW9
6XiWHUs6JhHqMfPccFehThklEXBZkLVWzBtCfHMfvZv7G45PI3/nkgigUwzN
JDiBwZePM9wm3z428waeQvYOGH+nK8eLui45HCmBQ9q1n2ue1ZTYTnxnCqZG
7rsoJOYx6aRrbeROi3xoS9eSjSxxiC7Ehpioxxl8UcyfGasuI6JhtQRy8h7I
UMESNjYlwMhBZW/PjtUWYIREfJW4scJd0Bsfj1VuSPQYYhl5G0uPVthRpmzL
c7IFGqafYIIhVRi8HpFtiLtFFqvqfu8U4VzSWh9AJjkp0q3EqOgmxgBIqmPm
HTkUJVAH/HcM+cZpOQvO+WuPyYxGpcaizAZJciFTeLAvdWNq17I9nuJNT0My
g2eZzLMMUeTxla8LUTPh5/dsA7Q7XpBjheUavucQvWdRb5ImEMqAVV0ifEyq
LkkAnWmsUm1PlumHZsdwhYxUNaE5vMBmpoSgmtTPa/EEhmrMxnUp1h7fprH0
2IXpagFCzEnwcwA9GqdyvEeF6i/ebU9CNfjwp4RquDqCFt6TrGvUQ/XuiM6A
d9gDzaayKsmtoCcusWEdQINkZ0wUUxUvVQo8hHXl/dgzCaoAmlU9MN8XCj1z
GEZJKmrXDkQJZ3XF45wCgOCOJQdWeyKZshV0/kvipmea8RjQuBXxtikmRcK3
W8Ocx/s5jyVT4TscgDBokn8pGdXmirJMb8tlzBExXnEAdEDGw3h13rYHvKmE
o5uJb+WDCUZAH8Ji7sscif8b9W5z5JMzB30tIUc7Ze5OvJkhRAt3poW5JgHF
TPRjhN5ohyWwSiL+t2dn4Rmt4D37vWvq32YWmWc2npqMigHFvOywMOGqJUTC
e7AOJIuekVCuTmyOHLkYnokDU4mcs52aKqQ1y0exLYHnReQQ8ZO1zmFD9dA2
mmOY37E93VuhEGcGWKYFXs9qgV4IMggouLNRvOR8V4heXwrguYvpCZCwFUev
E3i4V1HX5U4StyQ9R3oXlD4nSFeNvdH02iRHYqjCfUGDC84dmvG9QykAcS9c
d5YXphzidVLNaZFgtE6Y3fLgSIL92CAv36d/frCQC8mzJAKjSXN/NX+URvtA
CqkoZmEAeoe0yQhJXS7JLA85SynDL0oJMo7T1C3n1JvnnDq8LDWQ5GRIXTOV
NSFJvFP5YRa5eukvmste3WwipnwegEUeQ3z6LFjvss6ceEq7bwGOBVdTMS8T
t95m8PALww/FFwuav1JqIM54LSwwc+Y/KyuIqgkEn3rAGIKt/Hki0fIg8WtL
RET0WmEkTJydqsjPJ6ey2q9QJQsZoUxIg4mzxK7r4B8IF2ZhqxjIua6lF7fF
YHt1zZCtacqSBV9cmbGrA4FyShSsiHEeDPSN332f/W/kwalxOTtSFevFdSvQ
bb4pgsGmNH8gCrcMKyPqYgj3eGipvWFVTtwDYcnwYsLdALdO0zH6k+00JiJi
GoTS2Q0Z+ekCumElFsnMWKaBB/kR5JNYejt7JrtyuYNohckGFhCZBSJQmqGP
MX/c5n+gdo746tfJ1AvbLchzyWmOiOyBig0N6OSWjhB245gD+LAiaKtbJDIi
B61G2pw9knYLqsRZ3h1LUhppeE5+XByyS7ju6fLXJ1+d+uDlz7Tkk4XVUUl2
4au8P3169f4tkrYZRPjsUvah7zNfhdUnCYk9C0DEznVrz6QGNOQWgBdvLPkF
MbYo7QDJdmm6mOVwDTmARpFknXHuIxxCkRnJP1i1AP/QONkVCfSq4Nn4gFF1
UAH6jrEMjWNZ7XifffMQ9mqjrxC+2WW3tGbDQjGu4DIOMuPYe6sERokjy7tk
VICHqHubAOs4au2SzLvL7378HvFVB+zg83Kj1CUthiAkwhWyKa4kegI28ylR
Fft4AZxdp3+o6QsoJe5w8bGlQS6WxUluokYGt662/Ugjl6HO1scuN6MAptUU
0hwI4N0xGFuA8Ikxk/ihW9Niqa6N584helkrzt/n1GLDZRL3FwBK9KoudQu6
dJo5EuthFu6NxLp9EigWTjd3BgQlFrvUYXgR3QcsEpepcJKkboggOYMAGBGj
nmpobfJiogOYmPVmubH8FGsoxAQZuhPsubcKqX2tSNTiH8oYsBBie4C5K7I4
/0xqbDboCHN0lFRc0o4etr2vm4neNbagIl2U8IrVyOZpaSzLdi1sgbPDslM1
NVKRq69dKP2TfcPNPQYOrakNUrYnlL37XKWWGCVKlZwzb2nDo1KsGGEOa7qe
TlZkYTIzXl+uPWn7vOZ0WJ8lYwG3qdIt7waJzWfHvQPU8/JAmeqDVV0Q3e8i
0MRr94bVnFTXfHryKKaSVX1EakOg+DIuOGumq4+iYsj+f1slpC07pEAytN6Y
qg4KhClRVS5Zs1z1luNJSJuLc0T+VL9YLYkoXKcVYmAPOMpCIakaMlFPh+B8
l5qFWGSw1GTw7tWv+Sh8gBmF9sCbs1GukCRiKf8kNn4UKYiQluk4fYIhXgOi
EaKTG4N7w5fuKJ/D7WyGJ1jG4wkXlRHf5l0kmWJnuCJLdTgK3FP3GRyt5sZH
/mEv2kXrUcTVVMpGcDJBTuYg6TfroWRWXp4tWBu0ApllPlK9ItC2bTqTlguO
9u6wEZ3X1dy7RixNb8fcscyat76iIc2NIBIfpUJY8tUKbS1US5sjmRWNwRZO
soXokfS0XKe9dduyMv+SmMQP56bRardYOEmSEhKTRBcJf97n4gdlymBJh6CK
bmPNPSaI/5d3Pg6PVHXtTGI/sKKFYZgE6yF6C+FnnhXTcVTyyqYXlHHRGcT0
BSZqQudcAcf0JbkMWgOn1zvPNGYFh44DLWFO6SUCmUCaoXLagQT1QZ0hD7y/
8/4kISgaCiGjufbYiKycCb++FnAJyOCEPPNWmw0DZzHRfJoRplgkyctJIoHe
72AIzFz2g7R0MpDZ2mTIpQP2qQ5mokTthYh9rnvvMsNKWCFhYaqFLeRhgd3J
mzdvT9Whu6yk7pAke76d+bXvfV6hX0np/gQ1hxuGDVJQtbETnwwbRBC3qben
ciYlQbypRhenxmCYEQklbVnyqKeGtF7waAzVJZ0UqsJS2ywqr2a9gDMfADuk
+BudokT1l9rbsYpi6rCyuSWZt1uy/13yERYtW8s8dEXI8ikBmKzKaYKVBjm9
C27CG6PJIk87vwHi8ZXw9YbdlqIhGRR7pCqMvuu35v5QjcJAWrMk9jAmfOKs
bgfHdCIa5gHJ8EyH4SdOSk25Ugs+QMos1IkkkO0Rp432PhN0smzX/AO1rzlw
FtLf4xVSshx5NTR25ekBjddU0QxzX6PWWQKHJIKHlnEY7Gurf0V7O8JD3g0l
2CcqhRVnFaxzTqVh+JAXBUSF+oGiaCFNlr64GRjXDEm7yPmoz4MaWBtLcO9D
aDVhHQPE/ojaBgRuKxpNcQrdAx6DbD0nD052E8BKYv/ymnP8N5pQDNuKCwjy
Uc2gl9S+jJh/j2UdwQ5z77N/88mTh63zv2C8z3xjJOvz8+L8xYtgS0WVdW+R
Bvl7nf0XITqpPLKiM3rq+bfffj0TQyD3cFXMAVlRZMCq9awtTYyzwVmm+q4f
tfAtcK4PEnwghXIvjuZHHQoeL/j2OWUF9See/i/xX4ggdER0i8Oo7ndsUHN8
V4NyqVyciHHsI/lSsE57yLKWUUTWemyrtlH1jOe3WbpmnKEL5SGGt5TTYX+5
x5XJTzaXn3axIa19vdRsttXQ8EyZ40U+IG3ttzy/MrwjDbyvsU4LeGjh7bgA
aKAHepbcgz538fKbu3Dae7MXp09SqdZLXpLUxsGHoIl6YiYm+zWLUxxoHBE8
WZSHhndN+E2SnIW50HiAVujyOumPnnQiyE7kgVOhZC4ukOiclNavpHBVNpmW
RsrYtWDbao0c+INlTvXZRnCzQeUzPkADtDanyl5mypM4cX2UORit3smnT5Ot
wv/889TMEgtMhQLqTPu8cyDTHLuaDa7GVd4yjik03VSnp9AtsshiF5rPXZW4
nlh3Hh5PjFTui4ZqpeSSihr3BLHqWnr7vz58uNEqdfWb+ktMRhZsD9HdST/b
Pga6sv1I3+sTSk6M1ygQxDnfMJcFwoFF8gpOy2YrkemLSPh5wwtr95st9D/r
30JliyR/M2f7fmMLtqG5tuGBBP2ZVD2K+58bm4yMewAzmZsbVosl3RE13RUK
QeIMQ7nkUk9f4uITGRPq/zofkUXUGfXmeUx9tSW2iUDf1SHhQkTViapdbnwA
zU8DoomfqvkktajNGsynScKv3r0RZv9pSxxiAQPtR25NyLMT3HdKi4T/cusq
tL4e9FxWzzL602scQb2aHpmDWa1ZgzXEYdxxzyE2+TbX2XPifXAAcleIW7cw
A4n91jvxtsHXIuFw9fxK4grS0BXi5vV0tY1oMRbaIm244A9U1kfs7VBEzyiV
MwW1tBDdTawEaAz7BIINOjGtTUR3LIPH3CFtVfSOoUMzuLW6kGyFT4SesnHx
Saj4GMwXj7S7SlcuQtfBo2mGuzrES7hKucMzu4bElh92fTSfTeyfgfBgFSVr
cI+gzF7wOWcxcGTTd348k3MYUvDgfHjBYIR0SdMGqc78PCuOszahG6VwiGY/
RYm4/ExVrhiraqVG2ECeMtKJNRFEGj5wZVfSR9MgSPQu33dh0ShBmXnF1oXf
Be5uJ5zC031x9iIGO7Xk7on2hKpMM7rimefWEBzzHsuCnLsgRt64Ud1KHOBV
oc3zL3PgzSmskoZqbQVVlry6+UVEyaNHQSDUePNLkCHD7vlpbCmtEU7ljQoZ
cVL0+cembjYSDmGOWPkWXgsuMCKsQaTZcUEEb5TrfK+Z4sKXDM/UL42s39CN
ho3qrcWO0T7FerzTTnW7Vi210MwCNOOVaqcNh7d9Ipfacr1TCzMJE//w6uad
D2y+/hn45nLZ+40l2kEqukoZMclFHATNKdmJvlutNZ1tuHzi5peoqYzA4X3O
4UN7oIswgFh29gnLmWu4GAVy8cC+0CFxnfGBI4IKNYtOOHUnJhgzxZD/FL3J
/kHYoKuD1hdElZZ5SCWVMnjhJGPRrjFeCfJcelF0UXWjFhaVW8030859bfY7
afGucONOz/zsQqVmVPyT4KNRrLrXtLIR90VhX3OewKj3impmrsEQeaVJyZLF
aoWFcstR+kGkaJDpATE6t3JKRV5ZFEnmnACrU/SpL2OtFuBMZJkF8cdpuIMQ
oZeYHhIlmGdgKTahP6GpF59Rq4X3hD1eE3D5CwepZCfyEAQQn+gCERS0JGdb
Qx6NTjERf8G5YBqhRFSxjA9xaU06aSM+BiVSUrDUZIhQuMXEZJhslOiB+zy/
v3v1vdQgaJ5rwk6+2VQImfFbK4SLLzAtejzHYCRgysz6rw9v30h3rS77v29v
wub5/sGbsnCaYWnshFfbTIipyNSTblvi53Ec0i0tarMkM9C3mgsIZVD0ZqY4
jjQZAXCfChe6uNAO+rXsYkzHjeDgfeGRhjb3Mbdre7ttjCrjiKa2441w5pD7
V6iTk2bboWWf+NdRSCWHA/hGGc1n4CGN+d61fQhC69Ti1sy6gNaQIva3atuu
KE+syzZwDF14tj8Mkwilax0yis3R6slnk7d3u63v6h8HAzmutDfmZ60pbVTB
6uoUNtcKbanGeF+ap5HGLZxnDTY9MVqZiMlBYnXvO4BOTROXZ4+knkT2VSp4
PI5in3a78ZENJaMoU//zgAqYVVoY0pSjCPyEyLDqB0gUcz6+5L9oEUp3XxZh
Q7CMhRN/mtY+9sHNbx3dcULFnUg/ybcWrPXZk4+IseQMpochV3xgkYIqImW3
KCVPitiPXV5Rnr7v0GMneSABtWyVXNi3xowyPHXGbmdQwk34Qn81Ieg7x/S6
UjNwZk4lE9EBeNF3tk3d+QhlnFz3YIbc/y49zrfOtGx77TEXMmB/64vNPBrJ
b7NMjYjnmOM5Sd2tlJVxdQp8g7SkQYK9kbw1LUfJ+WA96853SGJFK14op63Z
LRd+ugrQy++Ue2R+XeB2yDg4Yc2lfCy7dhxcyon3VFuBRG6lTu2jeUhSMNWS
a8a4GDid2M+RHzIRjjOl8cz3voQP1rt3fT6BJF6QwVKjiejQ4OawSFL6eFDf
efD4P5wA6yHvaE+NRTTbDH6mFHdxCwNR5Gg/8WAqre93rejTvtj7/CTfNGlU
5DgoVANh23ZxRFvFNRxrnVZtBEw3i+uIDK9/GBHIF8jVYJ8Gj1XMiQ94rKL6
P25TaF1AC234QjtlxUAFZxKrmSSSnEUGrccau8XemnDShOu9zS00pEwbOeeH
GaJO3D2w8+jm79As5s5XkJhDQQWYNEvhFJqZ4NiOE6n42z2MISFZCyI+SQ5i
C/8mkRLOhZP80nxgRwTfzFwaMTCM8hqb+N4OZKD9RMRCmuiJKPEH6pHFwrFa
bc2xyX9Huau4qUuU9ZYpzhlAYlNAkD1cyZ+6nOwwjtCYlEWCiPmL7DdtFEJi
8Dd2+OKQTPyh7V7fyOUbuvKbkITRZ+LSi4Kb0JhJYzuJzsBy595jJjhj97Lp
6TUQO3f65NQWCCRgG3+WTJKOpCk9XRbO3xN6RdNpfMw3TYsKZexMkkjoxjEi
bo1h7bUHR/nFoUAcX5P7O0K+NU/DTu5psnD+C5J7QvEFGGdpqo90ynFUsre9
bXPJC2D8weWl8ekrNRM68pQkNSGavWEmRny+7tWnAD0cV/RdJ3W7oOZCr1Yr
J14265rjs/YdpiSR176XSdzMNIqijI0xfclsqsklrR2qdb7z/kQbFEuELnWg
ttqdyEbFHQcskUr86Z1h08iZGsX3CTXRfYzDLbsILkZbFa5ZcKHjp+AgSUmA
DynnIkFcGTQ1SOnisyUvPgDvAW3IeeRMDOI3PZ4lcjljynyJgXAkv1zStzh0
igEElKLFNCdTWZETchGwkcUWz6Ske8ipQ/+NHrJI4Rv1+hfxBTPFcD+OI4rg
iz8pxnfuRFNXQ/ChV+BIGSKT0RSaVvJCmwVRyErWk30aGc6t8zqDEcDOvrO0
gpXWyG8EbIC1F6hh4RKl5HSsPy04tigZDUUtobu0u5ncMHIZJMb01IEt5qUN
B2+qtzY6idOjNZHwBHvl3FAML9Uw/eDJiTM8NXc0yrygbbl+/1P2/G/ffPV3
OXnF9waZGwaKdODAgxtyL7ULD2wFr5einLPW2jxN66RiyfddyA+/zWKxG7to
xB1lBg7aiGkDT58okFZu+BcHpZejJfZ81E0+DyVEnonV+G0gihEID34KKUyP
Klu918W+b067SFhjQGJ2z5J9kiLhXDoZeQ+Vt+MEdU7o3AHC1SiEj+wN3Yih
lsV8FyDjnbZ/ROGHB6kB7NKQRmsoA4ZrR7w6XsGbPEambKojUmYdSf+XiS8j
Z6/OnJP+ks6j/vDGbkQxoX0vcmXcQJYOqyd8dgqnXobmjBY76vrd8s5SCK1Z
JMvRp96VBW962ETVSOudK3L1hbG3p9mWtS+Pc9LfLXJTsOtaVhJ+GKNDWXv9
8JqrTOLBxm0u6sbUvUQM7EQ4pM6xxtNwq1U26Uu1agN3MwKTc1LiqGz7uIj2
oHc+6G4uARrzQZ9YMAMVLiIIsZF+tsHtdGpu6qHY16VSbvgS75D4o1/cXIo0
/Y9PDf70Cf8VS2An/Voi6xipXEMTOQSBg7+JYe88ShnAsTUymeC+kWoaTZOI
s6vqcujZZCqPKkxUyUgtrgaIg4UeFfv4dmJnchAzm3PdsHZITTb2ZxO2cSs9
qCxPswFmuolMTFO9KfiutMtyWXDqQ0aM0DftQYuIAUL43BLhSQIKt97Q9H1I
w0i4k8RcuhX0UWSphugDeAlF8KF7mPdoJe/SqmypntfguPQc0CD1ILjKcS5o
uCjT1YdklFG4KqDVLhr+Q1EZXLS5ug7SSepzRzb71Kc8e/BoaL8RIF09i5pz
RiUAag7CZAEEGI4OLpr5M2GipucSfo/zwRgPcG88GUEzSv+aaXCURRkDCwYi
8eXOKhGU7EJHXN9tdgGp1THZPh24SaRTuzjOpJftsg/6mLfLn8zkjU9pMWLJ
ysY9YzwuvmXBd5qNAW2mlRVRu2CzLgZD69ltey9NitPOJydpid8p5z9FZ9uE
vgOW9RGF0KZ6vKRdYP6jLjPGuG0fiYlYnEjXS56s+vjMSyXtLlHvxk0++BnM
JK9WpJdmcd1eHGi0FIqQPshEgPTDYjCeML30Z5bOepKSxKVmvvPQ9O2E5Dlf
uo3csPLVW9Tr1NoGVIENr4y0bfIUCGVvCZJwFvZ8foIGYrlUvvGdaqSPg9XD
h5oqae+gw9FlDHksldsspBSEwEahFfo+MRZXZ9YHhc8xqWQbuSeK92aGBkEG
bYJ1Pcq04SQTn3WK0fDR7uFId1Gn/OM2nPP+6RN+gTkSH2QCjxw7tAQa3Fqz
IfjI7ZQEzuIIXl5psWq+ibbcdeE4yFAQwzVvBpTqkhQpGspKkVTuO81FLp7g
1yR9JREK3+hGjq89sUFZ8XUUoU9G5lONPHI9RYN0Zx0WOHZAHKUnBZX+pExp
2ileKFawYG1CedISmleUgQ3wTclJZqhvWDcgLi9i87rwG0tGUZt7i1TIGAEf
OcdDhKFkUWqtCd7AZ0zZuqrJRGv6Uo0Cv6NsBXZbZx5ea2q2bCTjNw3CytEo
3PUqOlPiQ1JpICli3Z1k4XMylmTAbJpwYBkiSBZGmEXZbN6jFDd+8KcXh8sh
MTk9pNJ5TS+OOusFLYEif1IK7CViNnMnXHJtVOegof2pEB85ggVHirr6eesk
oioN38cwtfY+/yzvhx44PwwNrsghB3nt+y5wG4xxce2iHDv3Is+OjEiEqtuK
HndsLPCAw06GhmfZe0uWvUqacmSfnjzUrmN01p4ilD6cM6aTjOq3PVGIjtXd
82UFeoJSdCzf3rWSfZH3oU+SFYFIgl6594+GRu/cwnm584fE+WTgdBaqgaAH
/ZGqmgSftnwJAKxNq98QzJRO8Mprw1K4YcM46/oCqRDh8xEgUKqjua9Zu4ua
Z02KJrxyiLkkV/SaCGvesUXos2VnA0xUVbwLzgpfcmt+KnZ+Jo1r4jie04IO
RnDqaJuZa7Um2KHxZHP/2XFCnEhxoU0ABg1nrW/2dBVI2kDhpSQu+1QJtUFZ
JXLD+ArZ73siitInw6DNMfNoMJ68+TbsYYQGjtte8A/3Qb+V1ESNKbPFKHuu
qk3M6ARpaAZhmhjGXtjonHnRqVHrnYAAQNKl9iVEnoMdS13QMvCJJ9jlttw0
pEi862Z0NJGUIXCyjXVZGTc5ZsCIZZZMbtFxnHBkRS3wG2y5AhKmfDlqEm0p
qj6G6ulOQx+e8JP0eVQeSoP/0B/oMsp0YQwHf4aEcuygbl8/clw3SQsvYwBp
IHocXeKFSrjnGEZ92VkGWdzxcDQ7TWgI61VL0WBqjsIDI505zMs8LujjZYm7
0jt/kEOu/Y5G7MjE1SUtEeK2rklGupO/JDHALN/QFXKWeqUHuZGz4KHWlvJN
Y7HyUYsyAVptYf38uGZlWzVWk7HOt6BQTU2KXej8AWmIEHOHVIYE55+NPhxL
gu7vaReqp/AD7+TkCW5ns9swNbMXSblrqZ1SpP+a9tuCJxc5xaBvbdeGAFQU
7v9sO7wKeTATpyXPzFbWc5gm7DdpqDPqPyYeo5XvuZkPu2qZ8U2mRWNtPU3M
dxZqDR3Q4rIYKQ9nmttD2enBXXzUkgZ0fH+rcOy0skicYgpHFR8RHx8Oz75M
e93E0VT0LykhSSnbl1PzSWI1mnXD/IqRnvbGnKEKYTa0r3XJkJIsK5a0MYQV
qCTpC1g5s0rOOGQfhjTUiuvUu7TLx3SHiFlUq/RFRy/nRdH5erI7aJ5VzoKM
a/3EI1H5iVkBcvD493beLThj5+ulkzaXExzKv8dsGqfYC0yQ4nxhPi09J2xo
Fr9x2aK8ze8dbdDLjFuUo52vHJ/b5qtek246pk8i3x3Hgi1gcl9GfQiUpscn
NCumDyegMpnCWbVFTr41yzYvuO854RuF+nJL+ljHRgJKqmVGcesCvGeRd64L
jqEYrD3Jri9/vBzA4CHWFXEqd2p9Ez96ubSG9UwJR58upCVJWfzzeEVqvDzW
0nSBN2xDkSS4KYu2wfkQ7o/s/Y4Q5h+z7DXtZPbebWDHXN1CxDVbzO77CoXK
AF6XFYQYjRR8OMv+VdZ32XeuvSPW/kOk9hUpDETFv2OZVZv96LBG967cd94F
Fg4/r+2Imm63XhO0hB1ZFHGdF6s0My74UCXtiBk6Po5f28up2c9f/N0O6WkW
PimJz9TYlsYIYGEfYpZYivaJms/nnD7Dp4HK8ShvmvXEMqvCd3W7Wv7zGC6W
4z8l+YczlwtQ7fw+363pJfM0dMssOD8/n968OdIykRMqg61obZD7JyP+osNp
xCOwj2OP/W04B2cWdXv3Rt/J6HTR09nAXWEla3H5UHoApT9367HTJTeyxenR
OSfpCZWnZuHjUJqWTEdASztBp/R1Z5jk8GRDevLECCEimLNTWthLBvNDfXrx
Zdo4ak6bQnPuOCIKfwJukNQt79H6Im4XJnF3WTwJCk9QSJKq7quFXr1/m3Z/
xMviY86hA3meqUuKnTQGS+aLQ1gBRYXYkkdaZ/K6Evwpsydf8WK+hYWQ1pKF
4921Ff69BpYj96sd2eJbqxbWuib25Eua4Ljt/mO7+4OkFYjD+baMTzSjl6Rg
e/r87SiXfZbdleU2WNtJAbDfNc0+6FJZBONSPUEr+sl39Oh9m51R43FF6IMT
sqM1fxERcGjerWZD5BAZErOeeZhQprY6C55Zccjp4Yjx2czp+eLlQZJTv4TF
xGfrz6hjO3imyXLrnWHJFE55s3HgAn7se1cg8GWvW65eLkE1W6u60YI4zi5X
tzS7FqNsdLVBePB5eooxp70Q0/nU8GhXnvMYfgw7ywnLc+l/FDVeCrGWB3tL
PTbJ6APK1JG7LrC4X21vBj178JCxJG8xD89K5j4Q27OIMebaYCl6hi07fwTY
GbbeQxMrdRi0nfQt6l2ddHt/MIl96LFSdOD0/Q92gvHtQGTYXM8b7drfeFHf
gehMTk4cjGFtP06Op4/IOD61QEJwAz3cmwYKjCPglggW66zpPPbP9QVJCjbE
6x2lUkXz/XvEmRwKvvz1hy8J8ipJsJOq802y7a3/4LfyyetFLPknEt3Mbqvn
ySmvcaUtwHKkxCT8Iqkavq37QVvdeJM2Gs03NJr/AUZn47AGogAA

-->

</rfc>
