<?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.17 (Ruby 2.6.10) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-colwell-privacy-txt-01" category="info" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.21.0 -->
  <front>
    <title abbrev="Privacy.txt File Format">A File Format to Aid in Consumer Privacy Enforcement, Research, and Tools</title>
    <seriesInfo name="Internet-Draft" value="draft-colwell-privacy-txt-01"/>
    <author fullname="Nick Sullivan">
      <organization>Cryptography Consulting LLC</organization>
      <address>
        <email>nicholas.sullivan+ietf@gmail.com</email>
      </address>
    </author>
    <author fullname="Louise Van Der Peet">
      <organization>TU Delft</organization>
      <address>
        <email>L.VanderPeet@tudelft.nl</email>
      </address>
    </author>
    <author fullname="Georgios Smaragdakis">
      <organization>TU Delft</organization>
      <address>
        <email>g.smaragdakis@tudelft.nl</email>
      </address>
    </author>
    <author fullname="Brien Colwell">
      <organization>BringYour, Inc.</organization>
      <address>
        <email>brien@bringyour.com</email>
      </address>
    </author>
    <date year="2024" month="June" day="26"/>
    <keyword>privacy</keyword>
    <keyword>file format</keyword>
    <abstract>
      <?line 87?>

<t>This proposal outlines a new file format called privacy.txt. It follows similar placement on a web server as robots.txt <xref target="RFC9309"/>, security.txt <xref target="RFC9116"/>, or ads.txt <xref target="ADS-TXT"/>, in the / directory or /.well-known directory.</t>
      <t>The file format adds structured data for three areas:
1. A machine parsable and complete privacy policy
2. Consumer actions under their privacy rights
3. Cookie disclosures</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        The latest revision of this draft can be found at <eref target="https://www.privacytxt.dev"/>.
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-colwell-privacy-txt/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        draft-colwell-privacy-txt Working Group mailing list (<eref target="mailto:draft-colwell-privacy-txt@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/draft-colwell-privacy-txt/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/draft-colwell-privacy-txt/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/https://github.com/grittygrease/draft-colwell-privacy-txt"/>.</t>
    </note>
  </front>
  <middle>
    <?line 96?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Consumers in many parts of the world have extensive privacy rights under laws such as the GDPR (https://gdpr.eu/tag/gdpr/), the CCPA (https://oag.ca.gov/privacy/ccpa). However, without some formalization of a service's privacy policy, it is difficult or often intractable for consumers to exercise those rights; enforcement to verify compliance with laws and develop effective monitoring; and researchers and technologists to develop tools to allow greater adoption and success of privacy practices.</t>
      <t>Consumer data originally gets into the cloud by connections from consumer devices to web servers in the cloud. To be able to audit and technically enforce privacy it must be possible to track the privacy policies applied to every byte of consumer data entering the cloud. However, currently the association between a web request and the privacy policy is tenuous, leading to the possibility of incorrect or unverifiable consumer data usage at the very source. This proposal fills that hole by associating structured privacy data with every web server. Just like HTTPS security can be technically enforced, this proposal makes it possible to technically enforce privacy by verifying that the structured privacy information exists and is in good standing before sending data to the server.</t>
      <t>This proposal outlines a new file format called privacy.txt. The file format adds structured data for three areas:
1. A machine-parsable and complete privacy policy
2. Consumer actions under their privacy rights
3. Cookie disclosures</t>
      <section anchor="general-file-format">
        <name>General file format</name>
        <t>The file format is UTF8 text <xref target="RFC3629"/> and lists <tt>Field:Value</tt>, one per line. <tt>\n</tt> is used a line break. Excess whitespace and lines that start with <tt>#</tt> are ignored. All field are NOT case sensitive unless mentioned otherwise. Each field <bcp14>MUST</bcp14> appear on its own line.  Unless otherwise specified by the field definition, multiple values <bcp14>MUST NOT</bcp14> be chained together for a single field. Unless otherwise indicated in a definition of a particular field, a field <bcp14>MAY</bcp14> appear multiple times.</t>
        <t>Implementors should be aware that some of the fields may contain URIs using percent-encoding (as per Section 2.1 of <xref target="RFC3986"/>) and mailto URIs (as per <xref target="RFC6068"/>).</t>
      </section>
      <section anchor="file-placement">
        <name>File placement</name>
        <t>For web-based services, organizations <bcp14>MUST</bcp14> place the "privacy.txt" file under the "/.well-known/" path, e.g., https://example.com/.well-known/privacy.txt as per <xref target="RFC8615"/> of a domain name or IP address. For legacy compatibility, a "privacy.txt" file might be placed at the top-level path or redirect (as per Section 6.4 of <xref target="RFC7231"/>) to the "privacy.txt" file under the "/.well-known/" path. If a "privacy.txt" file is present in both locations, the one in the "/.well-known/" path <bcp14>MUST</bcp14> be used.</t>
        <t>The file <bcp14>MUST</bcp14> be accessed via HTTP 1.0 or a higher version, and the file access <bcp14>MUST</bcp14> use the "https" scheme (as per Section 2.7.2 of <xref target="RFC7230"/>). It <bcp14>MUST</bcp14> have a Content-Type of "text/plain" with the default charset parameter set to "utf-8" (as per Section 4.1.3 of <xref target="RFC2046"/>).</t>
        <t>Retrieval of "privacy.txt" files and resources indicated within such files may result in a redirect (as per Section 6.4 of <xref target="RFC7231"/>).</t>
      </section>
      <section anchor="valid-value-formats">
        <name>Valid value formats</name>
        <section anchor="name">
          <name>NAME</name>
          <t>A string of maximum 50 characters. The string can contain any US-ASCII characters except for: control characters (ASCII characters 0 up to 31 and ASCII character 127) or separator characters (space, tab and the characters: <tt>(</tt> <tt>)</tt> <tt>&lt;</tt> <tt>&gt;</tt> <tt>@</tt> <tt>,</tt> <tt>;</tt> <tt>:</tt> <tt>\</tt> <tt>"</tt> <tt>/</tt> <tt>[</tt> <tt>]</tt> <tt>?</tt> <tt>=</tt> <tt>{</tt> <tt>}</tt>). This field is case sensitive.</t>
        </section>
        <section anchor="countrycode">
          <name>COUNTRY_CODE</name>
          <t>The country code <bcp14>MUST</bcp14> follow 2-letter <xref target="ISO3166"/>.</t>
        </section>
        <section anchor="languagecode">
          <name>LANGUAGE_CODE</name>
          <t>The language code <bcp14>MUST</bcp14> follow 2-letter <xref target="ISO639"/>.</t>
        </section>
        <section anchor="consentpresent">
          <name>CONSENT_PRESENT</name>
          <t>A boolean attribute, using 0 or 1 representing false (0) and true (1), whether a consent banner is present.</t>
        </section>
        <section anchor="consentplatform">
          <name>CONSENT_PLATFORM</name>
          <t>String attribute can be set to:
1. Label of consent platforms according to <xref target="MANAGERS"/> (extendable)
2. <tt>non-specific custom</tt> or any identifying name if it is a custom banner
3. <tt>non-detected</tt> when there is no banner</t>
        </section>
        <section anchor="duration">
          <name>DURATION</name>
          <t>An integer attribute of the duration between 0 and the maximum duration. -1 can be used for session cookies.</t>
        </section>
      </section>
      <section anchor="a-machine-parsable-and-complete-privacy-policy">
        <name>A machine parsable and complete privacy policy</name>
        <t>It is currently difficult to associate a complete privacy policy text with a service for a number of reasons. First, even though it must be linked from the company webpage, there is not a canonical URL. Second, it is common for services to use client-side rendering, interactive elements, break out links for addendums, and server rules to prevent machine parsing/scraping.</t>
        <t>This file format proposes two fields for the privacy policy. One or both can be used, depending on the policy format.</t>
        <t>Both privacy policy fields can be used for multi-language support, the default entry is the default language of the privacy policy.</t>
        <section anchor="issuer-information">
          <name>Issuer information</name>
          <t>Mandatory, single entry</t>
          <t><tt>Entity: NAME</tt>
            <tt>Entity-country: COUNTRY_CODE</tt></t>
          <t>The legal name of the entity issuing the privacy policy.</t>
          <t>The current and historical mapping of hostname to entity can be used as a canonical key to associate privacy reputation or enforcement actions similar to a certificate authority. This proposal does not outline what a privacy authority would look like.</t>
        </section>
        <section anchor="privacy-policy-text">
          <name>Privacy policy text</name>
          <t>Optional, single entry</t>
          <t><tt>Privacy-policy-text: URL</tt></t>
          <t>Multi-language support:
 <tt>Privacy-policy-text-[LANGUAGE_CODE]: URL</tt></t>
          <t>A complete privacy policy in a single UTF-8 text file that can be downloaded by any user agent or machine tool. This <bcp14>MUST</bcp14> include all addendums in the text file. It <bcp14>MUST NOT</bcp14> include links. Information about contact and consumer actions are covered in this file format and do not need to be linked to in the policy text.</t>
        </section>
        <section anchor="privacy-policy-url">
          <name>Privacy policy URL</name>
          <t>Mandatory, single entry</t>
          <t><tt>Privacy-policy: URL</tt></t>
          <t>Multi-language support:</t>
          <t><tt>Privacy-policy-[LANGUAGE_CODE]: URL</tt></t>
          <t>If Privacy-policy-text is present, this can simply point to the existing privacy policy, in whatever form it currently exists. Otherwise, it must point to a machine parsable/scrapable static HTML file that contains the complete policy on a single page.</t>
        </section>
      </section>
      <section anchor="consumer-actions-under-their-privacy-rights">
        <name>Consumer actions under their privacy rights</name>
        <t>This file format proposed fields to structure the consumer actions described in the privacy policy and commonly required by law. Currently it is difficult to get even an email that can service privacy requests from many top-100 site privacy policies. There is currently no law about how easy it should be to take privacy actions, similar to the US CAN-SPAM Act <xref target="CAN-SPAM"/>, which led to an industry standard one-click link for marketing emails. The spirit of these fields is similar, to make it as easy as possible for a consumer to exercise their privacy rights.</t>
        <t>In this section, a <em>one-click URL</em> refers to a URL that can process a request without requiring a customer password or login. The URL should take customer identification such as email and verify as necessary to complete the request.</t>
        <t>It is allowed to have multiple conforming Action-* values for the same action.</t>
        <t>An API standard to make privacy actions more toolable is not covered in this proposal. This proposal could be extended in the future to allow some well-defined API actions given there is at least one other non-assisted option available.</t>
        <section anchor="privacy-contact-email">
          <name>Privacy contact email</name>
          <t>Mandatory, single entry</t>
          <t><tt>Contact: mailto:EMAIL</tt></t>
          <t>An email contact for the privacy office must be given. This email must be able to handle consumer requests via email where there is not an applicable <tt>Action-*</tt> field for the request. Responses can ask for additional verification but should not require customer password or login. If <tt>Action-*</tt> fields are defined for all applicable consumer requests, this email does not need to handle any requests. This proposal imagines companies would build self-service one-click URLs for all consumer actions as the most scalable outcome.</t>
        </section>
        <section anchor="actions">
          <name>Actions</name>
          <section anchor="account-and-data-deletion">
            <name>Account and data deletion</name>
            <t>Optional, single entry</t>
            <t><tt>Action-delete-account-and-data: mailto:EMAIL|URL</tt></t>
            <t>Email or one-click URL to process an account and data deletion request.</t>
          </section>
          <section anchor="personal-data-deletion">
            <name>Personal data deletion</name>
            <t>Optional, single entry</t>
            <t><tt>Action-delete-personal-data: mailto:EMAIL|URL</tt></t>
            <t>Email or one-click URL to process a personal data deletion request.</t>
          </section>
          <section anchor="opt-out-of-third-party-data-sharing">
            <name>Opt out of third-party data sharing</name>
            <t>Optional, single entry</t>
            <t><tt>Action-opt-out-sharing:mailto: EMAIL|URL</tt></t>
            <t>Email or one-click URL to opt out of personal data sharing with third parties.</t>
          </section>
          <section anchor="list-of-third-parties">
            <name>List of third parties</name>
            <t>Optional, single entry</t>
            <t><tt>Action-shared-list:mailto: EMAIL|URL</tt></t>
            <t>Email or one-click URL to get a list of all third parties where personal data has been shared.</t>
          </section>
          <section anchor="opt-out-of-marketing">
            <name>Opt out of marketing</name>
            <t>Optional, single entry</t>
            <t><tt>Action-opt-out-marketing: mailto:EMAIL|URL</tt></t>
            <t>Email or one-click URL to opt out of marketing.</t>
          </section>
        </section>
      </section>
      <section anchor="cookie-disclosures">
        <name>Cookie disclosures</name>
        <t>Common privacy laws call for transparency in cookie storage. In order to audit and enforce transparency, this file format proposes fields that describe the cookies used by a web site, following a previously published format <xref target="GUIDE"/>. A web browser could technically enforce this declaration by refusing access to undeclared cookies.</t>
        <section anchor="consent-banner">
          <name>Consent banner</name>
          <t>Optional, single entry</t>
          <t><tt>Banner: CONSENT_PRESENT</tt></t>
          <t>A boolean attribute, using 0 or 1 representing false (0) and true (1), whether a consent banner is present.</t>
        </section>
        <section anchor="consent-platform-name">
          <name>Consent platform name</name>
          <t>Optional, single entry</t>
          <t><tt>Consent-platform: CONSENT_PLATFORM</tt></t>
          <t>The consent management platform name, which can be set to <tt>non-specific-custom</tt> or any identifying name if it is a custom banner, or set to <tt>none detected</tt> when there is not banner.</t>
        </section>
        <section anchor="cookies">
          <name>Cookies</name>
          <t>Optional, multiple entries</t>
          <t><tt>Cookie: 1_NAME, 2_DOMAIN, 3_DURATION, 4_PARTY, 5_OPTIONAL, 6_HTTPONLY, 7_SECURE</tt></t>
          <t>The field values are given as a complete septuple with each field defined by the sections, taken from <xref target="GUIDE"/>. From these fields, the most important cookie attributes related to privacy and compliance can be derived.</t>
          <section anchor="name-cookie-name">
            <name>1_NAME Cookie name</name>
            <t><tt>NAME</tt></t>
            <t>The name of the cookie. This identifies which cookie is set. The website uses this together with the value to identify the cookie.</t>
          </section>
          <section anchor="domain-domain-name-of-the-cookie">
            <name>2_DOMAIN Domain name of the cookie</name>
            <t><tt>URL</tt></t>
            <t>The domain attribute of a cookie specifies which domain may receive the cookie. If this is the same as the host domain, that means it is a first party cookie.</t>
          </section>
          <section anchor="duration-duration-of-the-cookie">
            <name>3_DURATION Duration of the cookie</name>
            <t><tt>DURATION</tt></t>
            <t>The duration attribute contains the storage limit of the cookie. This is in the form of the amount of seconds the cookies will remain on the user's device before it is expired and deleted.</t>
          </section>
          <section anchor="party-first-or-third-party-cookie">
            <name>4_PARTY First or Third party cookie</name>
            <t>This is a boolean attribute, using 0 or 1 representing false (0) and true (1), that indicates whether the cookie is a third party cookie. Thus means that the target domain is different from the host domain. It is placed on the website by someone other than the owner and collects data for that third party.</t>
          </section>
          <section anchor="optional-optional-status">
            <name>5_OPTIONAL Optional status</name>
            <t>This is a boolean attribute, using 0 or 1 representing false (0) and true (1), which indicates whether this is an options cookie or not. Optional cookies can be refused by the user, using the consent banner. When cookies are not optional they will always be placed on the user's device when they access the website, with or without consent.</t>
          </section>
          <section anchor="httponly-httponly-status">
            <name>6_HTTPONLY HTTPonly status</name>
            <t>This is a boolean attribute, using 0 or 1 representing false (0) and true (1), which indicates whether the httpOnly flag is set. This means that the cookie can only be transferred via HTTP, and therefor the cookie can only be accessed by the current server. This helps mitigate clientside scripts accessing the cookie data.</t>
          </section>
          <section anchor="secure-secure-status">
            <name>7_SECURE Secure status</name>
            <t>This is a boolean attribute, using 0 or 1 representing false (0) and true (1), which indicates whether the secure flag is set on the cookie. The secure flag causes the browser to only send the cookie over encrypted channels, therefor securing the communication between the user's device and the server.</t>
          </section>
        </section>
      </section>
    </section>
    <section anchor="other-records">
      <name>Other records</name>
      <t>Other records that are not part of the privacy.txt protocol may be included. For example, a regulation-specific record like <tt>action-fcra-freeze</tt> could be added to comply to FCRA obligations.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Following this file format makes it easier for consumers to take privacy actions, similar to one-click unsubscribe. Removing the barrier to actions makes it easier to make mistakes. It would be reasonable to allow some grace period of undo in case of a security incident.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC6068">
          <front>
            <title>The 'mailto' URI Scheme</title>
            <author fullname="M. Duerst" initials="M." surname="Duerst"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <author fullname="J. Zawinski" initials="J." surname="Zawinski"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers (IRIs; RFC 3987) to the previous syntax of 'mailto' URIs (RFC 2368). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6068"/>
          <seriesInfo name="DOI" value="10.17487/RFC6068"/>
        </reference>
        <reference anchor="RFC7231">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7231"/>
          <seriesInfo name="DOI" value="10.17487/RFC7231"/>
        </reference>
        <reference anchor="RFC3629">
          <front>
            <title>UTF-8, a transformation format of ISO 10646</title>
            <author fullname="F. Yergeau" initials="F." surname="Yergeau"/>
            <date month="November" year="2003"/>
            <abstract>
              <t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="63"/>
          <seriesInfo name="RFC" value="3629"/>
          <seriesInfo name="DOI" value="10.17487/RFC3629"/>
        </reference>
        <reference anchor="RFC7230">
          <front>
            <title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
            <author fullname="R. Fielding" initials="R." role="editor" surname="Fielding"/>
            <author fullname="J. Reschke" initials="J." role="editor" surname="Reschke"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7230"/>
          <seriesInfo name="DOI" value="10.17487/RFC7230"/>
        </reference>
        <reference anchor="RFC2046">
          <front>
            <title>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
            <author fullname="N. Freed" initials="N." surname="Freed"/>
            <author fullname="N. Borenstein" initials="N." surname="Borenstein"/>
            <date month="November" year="1996"/>
            <abstract>
              <t>This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2046"/>
          <seriesInfo name="DOI" value="10.17487/RFC2046"/>
        </reference>
        <reference anchor="ISO3166" target="https://www.iso.org/standard/72482.html">
          <front>
            <title>Codes for the representation of names of countries and their subdivisions - Part 1: Country codes</title>
            <author>
              <organization>International Organization for Standardization (ISO)</organization>
            </author>
            <date year="2020"/>
          </front>
        </reference>
        <reference anchor="ISO639" target="https://www.iso.org/standard/74575.html">
          <front>
            <title>Code for individual languages and language groups</title>
            <author>
              <organization>International Organization for Standardization (ISO)</organization>
            </author>
            <date year="2023"/>
          </front>
        </reference>
        <reference anchor="RFC3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <author fullname="T. Berners-Lee" initials="T." surname="Berners-Lee"/>
            <author fullname="R. Fielding" initials="R." surname="Fielding"/>
            <author fullname="L. Masinter" initials="L." surname="Masinter"/>
            <date month="January" year="2005"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="66"/>
          <seriesInfo name="RFC" value="3986"/>
          <seriesInfo name="DOI" value="10.17487/RFC3986"/>
        </reference>
        <reference anchor="RFC8615">
          <front>
            <title>Well-Known Uniform Resource Identifiers (URIs)</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <date month="May" year="2019"/>
            <abstract>
              <t>This memo defines a path prefix for "well-known locations", "/.well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
              <t>In doing so, it obsoletes RFC 5785 and updates the URI schemes defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI schemes that support well-known URIs in their registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8615"/>
          <seriesInfo name="DOI" value="10.17487/RFC8615"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <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="RFC9116">
          <front>
            <title>A File Format to Aid in Security Vulnerability Disclosure</title>
            <author fullname="E. Foudil" initials="E." surname="Foudil"/>
            <author fullname="Y. Shafranovich" initials="Y." surname="Shafranovich"/>
            <date month="April" year="2022"/>
            <abstract>
              <t>When security vulnerabilities are discovered by researchers, proper reporting channels are often lacking. As a result, vulnerabilities may be left unreported. This document defines a machine-parsable format ("security.txt") to help organizations describe their vulnerability disclosure practices to make it easier for researchers to report vulnerabilities.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9116"/>
          <seriesInfo name="DOI" value="10.17487/RFC9116"/>
        </reference>
        <reference anchor="ADS-TXT" target="https://iabtechlab.com/wp-content/uploads/2022/04/Ads.txt-1.1.pdf">
          <front>
            <title>Ads.txt 1.1 Specification</title>
            <author>
              <organization>IAB Tech Lab</organization>
            </author>
            <date year="2022" month="April"/>
          </front>
        </reference>
        <reference anchor="CAN-SPAM" target="https://www.fcc.gov/general/can-spam">
          <front>
            <title>CAN-SPAM Act: A Compliance Guide for Business</title>
            <author>
              <organization>Federal Communications Commission (FCC)</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="GUIDE" target="http://resolver.tudelft.nl/uuid:64b40236-787d-4ae0-8700-60cfe1598bfe">
          <front>
            <title>Increasing privacy-related transparency on the web using a self-disclosing standard</title>
            <author initials="L. V. D." surname="Peet" fullname="Louise Van Der Peet">
              <organization/>
            </author>
            <date year="2023"/>
          </front>
        </reference>
        <reference anchor="MANAGERS" target="https://github.com/privacy-txt/privacy-txt-tools/blob/master/data-collector/data/consent_managers.json">
          <front>
            <title>Consent Manager List</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
      </references>
    </references>
    <?line 350?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAq5fWYAA8Vb6XbbRpb+j6eooX+0nSFIUZZlm0knobU4mqNttPRMTjrH
KgJFEi0Q4KAA0WqP32WeZZ5svntvFQAutuNOT3fOYUyAtdy6y3e3UhiGQZmU
qRmqzkgdJ6lRx3kx16UqczVKYpVk6iDPbDU3hboskgcdPaqjbJIXkZmbrOyq
K2ONLqJZV+ksVjd5ntpOoMfjwjxgTTelV74v26t3gkiXZpoXj0PsMMmDIM6j
TM9BRlzoSRlGebo0aRouZH6I+eHOILDVeJ5Ym+RZ+bjA4JOjm2Olniid2hy7
JVlsFgb/y8pOV3VMnJR5keiUHk5Gb/BPXuDb1c1xJ8iq+dgUwyAGIUO1u7O7
F+7sh7v7QYTjGpzYDgOc4HmgC6OHwTIv7qdFXi2Gwb15xFM8DFSoHH30dULH
m/DxggeTVQYDlJuiFNOLf+c6ST9zyB8TU056eTHFUOIqr5GUs2o8VLOyXNhh
vy/PvSif96dFUpaPU1BoTf+Ti2KNFKe0ZbPGcrnsuREY0IvNQxDoqpzlBR0L
E5SaVGkqIjlPont1jUeMz/g3EKiz5K+6hCSG6qB4XJT5tNCL2aNoS1om2VSd
nh7waCOHzpJolqfa9qxb6l/psD9O6Vc6zebGp3mVWKP+pDN1SPpnTLll+5tb
/JpOyvZepz1Mik1BU34sq5h+72Xp5hZvDRZLcquu57rQ01jfJ/Y37jHt2WbO
Zzd5UySG7Igls2V1/J5Nf86roqtOsqjX3mRMU38c04BHDGA+BRlrWfLAGnV1
fLC/s/+Kvj6hh1d7gxfu/cvd5wP39fn+7uvm7Y77uruzt09fT64vng/2+StU
1eHBQR4bSxqtyplRhVkUMPWsZJpVPlF0NktforzKStBpGQIwOCkULDVOHhIy
VQvjuNRFqQZQFR76iClYu8Pb1Qa4I7vrYmrWNDWxOdlE35bYQBdx/+Xu3qvd
3qycCzdrzeX/QuIusCErTZExtTpVFy2G85mu3Vr+3VPw4JmwYv/5601O8CQA
DA4VV1gw1dm00lN3aP8kBr9+sudfcbK9Fy9f/H+cLCCcXVWb1893vE68HgxY
+qPD6/DmP29Wjz+KLQP4oDdQ1wsTJZMk4qU7n6Fx9EbdmGimTvW4xYwRQCcl
luxuZUmixyUmpVrgbbkAnOGwWdmvFmmuY9unqf2dvb6jKQRNvUU8wWoHo/Pw
+nJ0tiY691aNIuwzggLOF2mis8iot1XixPqmsklmrP3MeY4N0ATcxvx5lbnz
W34Uh6SeHh8cPPukoCdR1JvmD/2pyWidfqSz0C40QE+9vT05PBpu3Vrgo7MF
BzsrpwRqkA8g0PW4XxjCfJhjoTNsVJgMnhtkki0vzVhVPForC9QK48RGac5v
vCZ+UYVxMABCnj6YoteAX78CV4f7e+M9zNkPX756GYd72uyEr17u7IT7O9HE
DF68fjWeGCx4NjofvT26ul63NnLApTrTGSyqUKeJ9cddY2zLE7bcXft7WFJA
0h+n+bg/1xZ208eRNHnJ1ESIDvixLz6/fDeXLW3vLzbPgiAMQ6XHFiyMyiC4
mSUW7M0XuYUi5FWZktKAhZlZtr2/ijQWj70kSE176qTEr2maL62yyTxJdaEW
qZYgisSiWSjWFGCn0lYV+Tgvxew+fHC2+vFjFyOiCk7/sfULTJd+gR7r2M9w
dkzvE5F5X8VJwUd+pKH9HkcJ91m+zJpfenRKs3IYHccguSyqqKwKnIr45ZxC
YYyi6AiR0qAH25rraAaWKGib1WMsQcgYkcGZ0nh2qEWeJoiYdntNYAn2sjVV
5LKdA/HDi2Q6K23wnIbn94lRTldBjBUJzZM4Tk0QPCFgLPK44tWCwC9viQWQ
7CMRVrLHYiPIizRWM/1glHkPjLEAxrVdHUGpJqlVADMIhqa+Pby8Uk9rLYwX
Rc9U/VJP+Xv/WZdHHRxcjppRuZ72Is0Y4DbpR9FCP+upn/KlgdS7agl1hlop
m88d+1OP4aBZs3YkkfmDXeMlZFwq6GacTIDMCL5IwPkEZ8LJWXlZGiS0qOYJ
4nvz3hQRAQu2xf/lzN8q04T3NAqkJZNHkaMAJ9EpTCEBI3Y0ab5QZjKBEhET
53nGgXc2/ZZHFC5FoG05QgDEZ3maT2HYTIhfgo2VXmiyFEVxbUnqEecL5gJN
hhwiQDVxpOYCHRGMsb1G6KKnIGKawEmmjwrAQYqAxUk20KAqVmM6VpYZp36T
Ip/XHCKiaE0ipzFN682JF+gh31Fj6Dmxl8iukHE0R0wi3tnxsyYXQ+aVLWki
oMQmbjIJ6p7XXpEuh1ULsJ6wHDIDEY8gHAbFkVf7tIbiAsLwFoG1cgE24ANK
0EO/amvzKBHdGptyaYyHoML8V4VUwYdya6pGaga9qvLKdlVqdMzbCU/lMEkK
dCLakizKC8IV0sYqYzVKmFOrVFeW4ibKOLEGn84i0I0MmLsCuAAlUo4ZRiKN
MCS8+hTst2qI8iTz8qyswrVGjD31bySBNLk36qebm8vrGlcB3sSRbQKMyazb
FM31PYQDca6I8TOSB8liTSIkd+YtlNexGsRj3rOZkDwSVr9pnsfipmmZscFQ
LGLkkc/sBOLO+js91+93COE/0CE8eYKUjkOslYR8w62BIbc3x68gLvaX/+JS
pI8fJZxnlt8dJyaNh3/SaWXu4GDJtZE7wJF66u7P2R2tUlnwQPNLJGtG3/fU
0XtGqOUsQdK9gJN3axLPWeoQHtIh1sy7J3fEMpVMkdQZGOwoJcqxL78+v7iB
UCzL1yaMrlWW0uoEz+ARNs/Bn2IJHMfOYLibfXZ7fUPAAeSl+CIhxwdXL8Sr
W1mknqqsxPWGQbFkZtEqsZkkAHNs1AVoIa2H6NQDMcTKDkQgzCWa6SRjhALO
Yk1WCHgsqGTq1uptbkrpVMRRakLw02wm/o7cNfkznIBX6OKdO9zoZ3+2mqoy
mbMHOCH1Iu7kQGsLh4rxhNFL4qewn/yriwJ4PXBTsysocQp1e3ViXXgMcUdY
KUTwnLN5PUUEQDpwLT5D7SIlwkpOgV6/QiT2jKVN2TvMkNfyk2QUJesYBUpJ
WbkoVkeCQXAMvgGnwrEmvXIe33ZXCgaO9TyLD9FpGWxH1Ly2HNVph3r9Drha
zrrK9Ka9bh1Im/eauMaRdHt0a121cohX+4MXsBUWU5zPiW2UqxDUn1wSRMAY
bY+qffASUzJbMntQL/6BJLmF6DmZNvtFOlrsnUKZL8KUQgSmnfaApXDIuiGP
/d5eIw8qf5A8HBx+NZcQtU+2E8pwytUQ0lxE6oiHcpcTSvBHYOFChW1LiwRx
UoKPdtTt32uOcsCDh0Szi0L2vcMxvpqBS6CaohG2S++peb7Mk2Uq69SDxdxR
FiEYZLSpwy97uytc2yH9pJSFl+EQWRM4UyYe3jwu2Ho6BJ19SCrJOoJltBds
WFMECkAorCnJhqEXFMXREyTRqcpJ+KqzQcUeEvnnDRVUmRIruTJUW3ogxzXZ
IgvrQ0wOGmwLU4gmiIADdxlJVo6RRB8DzlepkTNYeIMkFgh0voS9zhN1Pjo7
CoIRuUZCCkyf6/fJvJqrFzvMDjg1Si3ZobpBFGx42KEE5fY6HF0fnJy0xsP/
R2ZB2WMx5LFFnrZ/froxYUdVFEqr5wNmzdrvarD78hkpkjUkm5KSgtZq7K+g
wnpc61Xz81DdPb1Td8/w+Q6f7/H5EZ8uPt/iM8Tnz/h08Onj8ws+v+LzAz5/
xOcDPh/vnrnATpAcX1b9W0+4eXBxe35z9fO7g4vDIzGPqFU6FMWUhFrtAhzK
kqHJ1TE/fnSrnI7O396O3h61lqkrdV9YZ//563qZg4vz66Pzm3eXV0f0L0l5
jFTFQHq6hCTHVQmeictgIx005VJ6N9Epjvh0R1wDQic8DJAlLmfiLLVyBQg1
1khHiha+rFNwOro5vrg6C4Jr0aB6fx+4iplxAHaqxyb1aQKtDmMtSWctwURe
+OD9wwdfiAGkP+VkOKZw7RnFZHdZTpUqqfohi7BlPr9jIIK+JtRqcfEs438y
cbmodkPdiShc45ViYAF0Kb6jwzM+FgynWe5H8nkPb69GNycX52A1J7GGCkHN
WZ3zjqtiNYXZqZXW254f0lPhwLOIQ7YJm4CU7iIOJC3z+mvrGMEJn7dJr5os
nDJCl6EYlvHWFSQEZQCtU3wXPkmPik5LQTWECI+aFLbsUkJDzMur6aydTyK6
u6ezUSLLpktON+PMZwGd77b5XRJJGjKhZAWBymmP4C/PYl9OwOS5Kyn7OISO
RF4lQjoKV2CpgFpQw410scuC4lycaioShMEdclRMWQeTJx0FRAiYVs2tuC9X
9yqqVPaA8j+QwrYlgR36Nir0Al98TtOO6CW/ofnL3Id1vnmxyvGeusg4VGHH
3VKKrpL+IeN35pJalpHsgW3f0JQ1AbrN1rWLI9OwxhtbLRZ5UXZX3KRhSEvs
yst6ilPzNerFQk6srQgpmkwxCM6odEt1vK6PvHn9ILg7gpmWj0N2Unf+MXSQ
OlxB2zuHkwjbUhfUCRmGJ4FYW/kiwwZlDNRiCixYCIkqQRFny4uFc4yz3Ja8
MhU0ZNU287RdUc1787hqSnUmaBaVb0cVK2Urnz/6UitNV5FBOsGtC+MK7VRH
XasyxLkR43BZMmCKct56z3qiWnJmkQI6uI7gxHK5adtBcLGQXs2GWNzoUEaH
NHpIpggZnG3VnmGgtk0Kf1nxdL/6RUafBB2Ofxw1SIRDlwmzQXGS5AQSI2al
zoskhoQlEBHsd8p166K2UCrdOV6yT02yKK2ADhrpbG3sPiKut2qCTMoj/RyG
CfzUKoLoMeEHh0pR6fB4rVZA6V2UA0YknSzX8YFrlTnLNjNSTGsQEw/JisET
idtFCs5+ztJWpfMlaW6owCcEiURki9hbcYKrTZHUoPSLlMhNpIDLtktFpFZ7
qKkcZ6zhVCBjRhH2N75Mak/AS5+yd2tvUy+vN/ylwDR7Tkv2GSGBOTtt65aE
vLb2UaKhwt+8pZnktFzc/TW1oU86h9hjNeiuS1iOirXlY4NTJGOvTBsG5GIC
eMj0kYumSSE2kuplTx3ULFwvzWPnKUI0duAQFrf5G4vz/r+BOK7Guto0NzEo
Gx7s7IBF61ZNIQxlF+LhGykitgJRzoZmiHQRTDBhTXWE1ETfN+s5LnTbCEpM
uL1W7Y4qQkf/SK2m5SxBrpWKPWkK3GKoClV0XVOR0uIQwUN0z4YnblIX94Z1
k3nhE6RFApR1rsfWdZqkxvQu7UEVWDoIPAafidI4X4uVEKqW62q/Y1NpqHLk
UMNKFkhFim8agmGI30AeE9c80fSiERwUjBNvXRfQfTdHdEOarRITg5oFvBld
IiIIpUZIJqemJZ1QWBz1eBdou75z3YwS7SFVdF0avMsMEaILdpq1cckVDqas
52NW7rKIsDjHr0tpYBrZDdE8YlaE3/iin4+oLLlv0ZIeB+mjy5NGzF40a+qk
5lSqJlfB4ODC0HXQ9r543TVHXlklQ2ksc1KJGfu+Edf3uOTCFUUMJOI8DdPk
oZ14QH5I5GzJFRsuTSrKUyAfQB9VV13r6QGcJqrXnIJ3SSyJz/mFAxk4dJXB
4dHZ6IRdtMcAv9J6zJoTcpg6xGfyHWtkov/Fd6FmoKHdZakxhEpJMmXJp19N
BjJpM0W8zJ2X+53L05trQKJDdO9vQWml+Bxt731cn7h7KdLwcQo7rmq0oc0c
Xn7WHuDy1qkQJ++FyvtReNGQvXFm5xbl1HVs5/2/4xShqp+wrnTJXE+5cC+p
FHXjJPAbV0kay+0JD9orWGFr+jYjFXF8c0TByiLCZdIBFdjCq5ccXCpL9MSR
uoQw1G6JkV1xyP/JyNJxjgeaUMsCIRYIaYFVLfxviTGOmEnUOm6fQ9IxB26Z
0p8ipYUuTPMlcJL14G8ieOFm/y5q1WIrDeuUgiTOTtnXJEVM7arSdQ/tTBN0
f5FsoESINUI3fugIVr+N4ryhYJVkt5wvr4I4aYq4WgVVuBLbUO5//CK5tK6J
Q2pzfSWpFLto7o9x8T9NV3d2yLJ6ihkUfkzlGdl2C9/rGOA3M7qe8ZXKkW/Z
tI4wN9uJB1ID8VjMlx6oSSp42L5alfgykqKMl+JWJDAgIZbYo7ka4JvC7dnd
zXSlLmf4iJUiDR+UupCVq1aSM1NyJg3uhGqRUtKUoIOKKUleWcoJqjFENxPw
pF0+fODbZx8/UruWpo+LfEkJnjjbbc1spjQ2Uap98Y3Qc+Luk0n7gcpEmYwx
8Up5TQL5ptT5aYG/4d+H68XXu39G9XWtfsplkU9T7oaHfvhwo3x750vasq5c
O5tvbOEj6pXS7mpFNvxbK7Jd6QHUK5Jf/VRp1nOmZgfLs8WAOnI0chGYmUCD
hmrwjmpOXbX77vACFnreVc/f+epuV+29uxxd3fzcVS/eXVzSq9FpV+2/o4bX
xfkp3r98d310cHvlq1ISjLhYlIIBieakYuRjXWsWZUXUyN2PpifuIwfX4nZx
PgUJCFYzybFaFnHsyqh1+tFt/DZybCTwOiu91deqaFV99TJvAmBfQZYbVL64
ghDpgQFREFF45YGIlSy4k5Idn75djZNtXbji0wMGYNYYWYKTGXeHA9bNKWPF
NVKaVTfr6+6dtLWoGOLUqL2VI9ILUh22+75tokC0wDBt67rDK7V7XUOlu3Xg
yXaDpU8XGaojt896MhHCXb1UchD5TiVFN70rWDkHQNha9ydUN1fi2VfP06ij
OvT9hPXj+BH+TH5cq/vSLmk4DwA3Oa9z2DWB1bUwNnY3RM85tsKT5Uq8XcH5
ZQK/UxjmkKtOUy3uD9ZdVfNXgeTI5v2CKxJyRY/sona8zuikl0AwcFO78Mf6
zJ5M/fcBWxaJ783aGnub88le5QYlxLDKOmnWd6bkJrDXF1dgMVx2rpsfLZXg
OiPButwraK5Bs0WMHzllbBJAbCMj8iX5AzFevjBs29edmJaaXs/dBsmUB0gu
g1X2785UMZptXHXbZC59tZ7JOWW3AISaMq9cDpHYkTcISfrlCStbDsu5A/Uf
5Cj8EgTHXDn3a2PGo2itTpf60bZudmzVX+92HuswohGS3I4l+n1dxdHi2d44
Db4uwWW5fzjbDd+ouaC9J6metvA32VBhJxFiPBM7diEh1Lho3fuo73cUxufg
W2bW10Wc4HwPxl93ZAJmJl2ADCToU+qBSBOPe3gUVS5K65ZppC0BMTTec9m7
Y2oVUs3ln8BhKzu3+Ou1qQGM1VGRdj7P1OEtZQKsIcZfcnD2QXVwROT0F20U
uc5I0VPbbQQgF0VrDrX+GqTuQm9qtu9K1zcyn0hJnbwcUgQwcOVRlMTbE6HL
WiuQL2QhQyhz4BK7y7Hx7ZNYrl25K11drkhOq1RL4ucb+bKT3IC9k8JEOIkK
HU4KY/5q7ppqG3Vv4rqWyFXF44OrkcqRSkzlyhMfCFHvg9xJlCs5h/VtPite
k/p4Sz5eh1o+9EeZvvVD36+O/v325OrokL5f/zQ6Pa2/BG7E9U8Xt6eHzbdm
5sHF2dnR+aFMplbSyqugczb6uSOG1PHg3KnrjXEeVdI1lCIis7I0BfS05G5k
sNILeHNw+b//M9jz95QGA7o06m7FDV7u4YFwTHZjHZNHwrXA3VmkeIgKQ3qR
lJq0S/NNxWWmSMvAzW9+Ic78OlTfjaPFYO9794IOvPLS82zlJfNs883GZGHi
lldbtqm5ufJ+jdOr9I5+Xnn2fG+9/O4H7rCGg1c/fB9QDCyoQs1VSqES+osr
pz/HdT67kSjXt7DpD6DczdOVP3P4YmOjKRJUmDYWWVOFc54/eEsf66JIXCrv
i9lrG/ui9zyxtKXloGPpzUhucNR/KdAUqqcFXeNcIBXIYzJzJM7cjORrUe7v
PhxXYOEcmHPCoE5G56MNRt2saDRVXrJcRjqyaS791cxYR/e0yiiie4mpiad8
XSP4MJRbJyb+Y4fhufMx+D/DoHFeJj4AAA==

-->

</rfc>
