idnits 2.17.1 draft-ring-analyticstxt-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 17 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A field MUST always consist of a name and a value (for example: "Author: Jane Doe jane.doe@example.com (mailto:jane.doe@example.com)"). Each field MUST appear on its own line. Unless specified otherwise by the field definition, multiple values MUST be chained together for a single field (for example: "Implements: gdpr, ccpa") using the "," character (%x2c). A field MAY NOT appear multiple times. -- The document date (22 April 2021) is 1100 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Ring 3 Internet-Draft H. Niefeld 4 Intended status: Informational Offen 5 Expires: 24 October 2021 22 April 2021 7 A File Format for the Discoverable Use of Analytics 8 draft-ring-analyticstxt-00 10 Abstract 12 Internet privacy has become an important feature for users of 13 websites and services. This document proposes a way for websites and 14 services to declare and disclose their usage of analytics and 15 tracking software. analytics.txt aims to be an elaborate file format 16 that describes the privacy related characteristics of analytics and 17 tracking software in a non-biased way. An analytics.txt file is 18 understandable for a non-technical audience, while also useful for 19 the automated consumption by tools and software. 21 Discussion Venues 23 This note is to be removed before publishing as an RFC. 25 Source for this draft and an issue tracker can be found at 26 https://github.com/offen/analyticstxt. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 24 October 2021. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Scope of this proposal . . . . . . . . . . . . . . . . . 3 64 1.3. Definition of the term "analytics" in the scope of this 65 document . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 67 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Comments . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Line Separators . . . . . . . . . . . . . . . . . . . . . 5 70 3.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 5 71 3.4. Field Definitions . . . . . . . . . . . . . . . . . . . . 5 72 3.4.1. Author . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4.2. Collects . . . . . . . . . . . . . . . . . . . . . . 5 74 3.4.3. Stores . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.4.4. Uses . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.4.5. Allows . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.4.6. Retains . . . . . . . . . . . . . . . . . . . . . . . 9 78 3.4.7. Honors . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4.8. Tracks . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.4.9. Varies . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.4.10. Shares . . . . . . . . . . . . . . . . . . . . . . . 11 82 3.4.11. Implements . . . . . . . . . . . . . . . . . . . . . 12 83 3.4.12. Deploys . . . . . . . . . . . . . . . . . . . . . . . 12 84 3.5. Examples of analytics.txt files . . . . . . . . . . . . . 13 85 3.5.1. A site using analytics . . . . . . . . . . . . . . . 13 86 3.5.2. Specifying required fields only . . . . . . . . . . . 13 87 3.5.3. A site not using any analytics . . . . . . . . . . . 13 88 4. Location of the analytics.txt file . . . . . . . . . . . . . 14 89 4.1. Alternatives . . . . . . . . . . . . . . . . . . . . . . 14 90 4.1.1. link Tag . . . . . . . . . . . . . . . . . . . . . . 14 91 4.1.2. HTTP Header . . . . . . . . . . . . . . . . . . . . . 14 92 4.2. Precedence . . . . . . . . . . . . . . . . . . . . . . . 14 93 4.3. Scope of a file . . . . . . . . . . . . . . . . . . . . . 15 94 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 95 5.1. Incorrect or stale information . . . . . . . . . . . . . 15 96 5.2. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 5.3. Multi-user environments . . . . . . . . . . . . . . . . . 15 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 6.1. Well-Known URIs registry . . . . . . . . . . . . . . . . 16 101 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 103 7.2. Informative References . . . . . . . . . . . . . . . . . 16 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 106 1. Introduction 108 1.1. Motivation 110 User tracking and the utilization of analytics software on websites 111 has become a widely employed routine, visibly and invisibly affecting 112 the way the user facing internet works and behaves. Yet, there is no 113 well-defined way of accessing information about what software is 114 being used and what kind of data it is collecting in a standardized 115 way. Legislation can only ever cover a subset of the range of 116 existing technological implementations, creating incentives for 117 software to find workarounds, thus allowing them to hide their 118 presence from users. Automated audits are limited to aspects that 119 are possible to detect in clients, but cannot disclose other 120 important implementation details. 122 1.2. Scope of this proposal 124 This document defines a way to specify the privacy related 125 characteristics of analytics and tracking software. We aim for this 126 information to be consumable both by humans as well as software. For 127 example, search engines or browser extensions could make use of the 128 provided data and display information to users, but it should also be 129 simple enough to serve as information for inquiring users as is. 131 The file "analytics.txt" is not intended to replace the requirement 132 for complying with existing regulations, but supposed to give 133 insights beyond the scope of these regulations. 135 1.3. Definition of the term "analytics" in the scope of this document 137 Analytics as referred to in this document involves the collection of 138 usage statistics in order to generate reports that can help the 139 providers of websites and services to better understand and optimize 140 their services towards real world user behavior. This can also 141 include measuring different content against different groups of 142 users. Analytics or user tracking as referred to in this document 143 does not refer to the identification of users in order to deliver 144 customized advertising or content across websites of any kind. 146 2. Conventions and Definitions 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 The term "implementors" refers to the providers of services and 155 websites that wish to use an analytics.txt file. 157 3. Specification 159 This document defines a text file format that can be used by 160 implementors to signal information about their usage of analytics 161 software to both users and software. 163 By convention, this file is called "analytics.txt". Its location and 164 scope are described in Section 4. 166 This text file contains multiple fields with different values. A 167 field contains a "name" which is the first part of a field all the 168 way up to the colon (for example: "Author:") and follows the syntax 169 defined for "field-name" in section 3.6.8 of [RFC5322]. Field names 170 are case-insensitive (as per section 2.3 of [RFC5234]). The "value" 171 comes after the field name and follows the syntax defined for 172 "unstructured" in section 3.2.5 of [RFC5322]. The file MAY also 173 contain blank lines and comments. 175 A field MUST always consist of a name and a value (for example: 176 "Author: Jane Doe jane.doe@example.com 177 (mailto:jane.doe@example.com)"). Each field MUST appear on its own 178 line. Unless specified otherwise by the field definition, multiple 179 values MUST be chained together for a single field (for example: 180 "Implements: gdpr, ccpa") using the "," character (%x2c). A field 181 MAY NOT appear multiple times. 183 Implementors SHOULD aim for authoring an analytics.txt file that is 184 easy to understand by non-technical audiences. 186 3.1. Comments 188 Any line beginning with the "#" (%x23) symbol MUST be interpreted as 189 a comment. The content of the comment may contain any ASCII or 190 Unicode characters in the %x21-7E and %x80-FFFFF ranges plus the tab 191 (%x09) and space (%x20) characters. 193 Example: 195 # This is a comment 197 Implementors SHOULD make deliberate use of comments to make an 198 analytics.txt file more accessible for non-technical audiences. 200 3.2. Line Separators 202 Every line MUST end either with a carriage return and line feed 203 characters (CRLF / %x0D %x0A) or just a line feed character (LF / 204 %x0A). 206 3.3. Extensibility 208 Like many other formats and protocols, this format may need to be 209 extended over time to fit the ever-changing landscape of the 210 Internet. Special attention is required for defining the allowed 211 values in enumerations to ensure they are a. extendable and b. do not 212 become obsolete too quickly. 214 3.4. Field Definitions 216 Field names are case-insensitive, yet implementors SHOULD use the 217 capitalized style used in this document for consistency. 219 Field values are case-insensitive. Unless otherwise specified, 220 implementors MUST refer to the allowed values for a field given by 221 the specification. 223 3.4.1. Author 225 This REQUIRED field holds an OPTIONAL author name and a REQUIRED 226 email address providing information about a person or entity 227 responsible for maintaining the contents of the file. The field MUST 228 contain a valid email address which shall be used for inquiries about 229 the correctness and additions to the data provided in the file. 231 3.4.1.1. Example 233 Author: Jane Doe 235 3.4.2. Collects 237 This REQUIRED multi-value field indicates which potentially privacy 238 relevant user specific data is being collected or used in session 239 identification or other procedures. These values MUST also be 240 specified if a property is not persisted as-is, but stored or 241 processed in a hashed and/or combined form. 243 3.4.2.1. Allowed values 245 3.4.2.1.1. none 247 No analytics data is collected at all. This value MUST NOT be used 248 in conjunction with other values. 250 3.4.2.1.2. url 252 The URL of a visit, including its path, is collected and used. This 253 MUST also be specified in case URLs are stripped of certain 254 parameters or pseudonymized before being stored. 256 3.4.2.1.3. ip-address 258 The request IP address is being used. 260 3.4.2.1.4. geo-location 262 Geographic location of users is determined and used. This could for 263 example be derived from the request IP, or from using browser APIs. 265 3.4.2.1.5. user-agent 267 Information about the utilized User Agent is being collected. 269 3.4.2.1.6. fingerprint 271 Browser Fingerprinting is used. Such mechanisms usually try to 272 compute a unique identifier from properties of the host Operating 273 System, allowing them to re-identify users without having to persist 274 an identifier. 276 3.4.2.1.7. device-type 278 The user's device type (e.g. mobile / tablet / desktop) is being 279 determined and collected. 281 3.4.2.1.8. referrer 283 The Referrer of a visit is collected and used. This MUST also be 284 specified if the referrer value is stripped of potential path 285 fragments. 287 3.4.2.1.9. visit-duration 289 The duration of a visit, either on page- or on session-level is 290 measured and used. 292 3.4.2.1.10. custom-events 294 Custom events like conversion goals are defined and used. This MAY 295 be left out in case the analytics software in use offers such 296 functionality, but implementors chose not to use the feature. 298 3.4.2.1.11. session-recording 300 Detailed behavior like mouse movement and scrolling is recorded and 301 can possibly be played back when analyzing the analytics data. 303 3.4.2.2. Example 305 Collects: url, device-type, referrer 307 3.4.3. Stores 309 This field is REQUIRED unless the only value of the Collects field as 310 per Section 3.4.2 is none. The multi-value field indicates whether 311 data is persisted on the client during the collection of analytics 312 data and declares the browser features used for doing so. In case no 313 data is being persisted at all, the value none MUST be used as the 314 single entry for this field. 316 3.4.3.1. Allowed values 318 3.4.3.1.1. none 320 No data is persisted on the client during the collection of usage 321 data. This value MUST NOT be used in conjunction with other values. 323 3.4.3.1.2. first-party-cookies 325 First party cookies are in use. There is no differentiation between 326 session or persistent cookies, just like HTTP and JavaScript cookies 327 are considered equal. 329 3.4.3.1.3. third-party-cookies 331 Third party cookies are in use. There is no differentiation between 332 session or persistent cookies, just like HTTP and JavaScript cookies 333 are considered equal. 335 3.4.3.1.4. local-storage 337 Data is persisted on the client using non-cookie JavaScript APIs like 338 "localStorage", "sessionStorage", "WebSQL" or "IndexedDB" 340 3.4.3.1.5. cache 342 The analytics software leverages browser caches to store identifiers. 343 For example, ETag headers can be used to identify users based on 344 their browser caches' contents. This value is not required in case 345 the analytics software sends static resources with cache headers, but 346 does not make use of the request headers on subsequent requests. 348 3.4.3.2. Example 350 Stores: first-party-cookies, local-storage 352 3.4.4. Uses 354 This field is REQUIRED unless the only value of the Collects field 355 Section 3.4.2 is none. The multi-value field indicates the technical 356 implementation details for how analytics data is being collected. 358 3.4.4.1. Allowed values 360 3.4.4.1.1. javascript 362 A client-side script is used to collect data. 364 3.4.4.1.2. pixel 366 A static resource - typically a pixel - transferred via HTTP is being 367 used to collect data through the request parameters. 369 3.4.4.1.3. server-side 371 Collection of usage data is happening on the server side at 372 application layer. 374 3.4.4.1.4. logs 376 Usage data is being calculated from server log files. 378 3.4.4.1.5. other 380 Other techniques that are not described in this section are in use. 382 3.4.4.2. Example 384 Uses: script 386 3.4.5. Allows 388 This field is REQUIRED unless the only value of the Collects field 389 Section 3.4.2 is none. The multi-value field discloses information 390 about whether user consent is being acquired before collecting 391 analytics data, and if it is possible for users to opt out of the 392 collection of usage data. 394 3.4.5.1. Allowed values 396 3.4.5.1.1. none 398 The software does not define a way for users to opt in or opt out of 399 the collection of usage data. This value also applies to scenarios 400 where only a subset of data is collected by default and could be 401 extended by opting in. This value MUST NOT be used in conjunction 402 with other values. 404 3.4.5.1.2. opt-in 406 No usage data is collected before users have given their consent. 408 3.4.5.1.3. opt-out 410 Users can opt out of collection of usage data using a dedicated 411 feature tailored towards the user audience. This value is only 412 applicable in case no data at all is collected after having opted 413 out. 415 3.4.5.2. Example 417 Allows: opt-out 419 3.4.6. Retains 421 This field is REQUIRED unless the only value of the Collects field 422 Section 3.4.2 is none. The single-value field indicates the duration 423 for which the analytics data is being stored before being deleted. 424 The value is either a duration as defined in [RFC3339] or the token 425 "perpetual" in case data is retained without expiring it at some 426 point. Implementors SHOULD add a comment providing a human readable 427 value to this field. 429 3.4.6.1. Example 431 # Data is retained for twelve months 432 Retains: P12M 434 3.4.7. Honors 436 This OPTIONAL, RECOMMENDED multi-value field indicates which browser 437 level privacy controls are being honored when collecting data. 439 3.4.7.1. Allowed values 441 3.4.7.1.1. none 443 Data is collected even if any of the browser settings listed below 444 are in use. This value MUST NOT be used in conjunction with other 445 values. 447 3.4.7.1.2. do-not-track 449 User-Agents that have DoNotTrack [DNT] enabled will be excluded from 450 the collection of analytics data. 452 3.4.7.1.3. global-privacy-control 454 User agents that have Global Privacy Control [GPC] enabled will be 455 excluded from the collection of analytics data. 457 3.4.7.2. Example 459 Honors: do-not-track, global-privacy-control 461 3.4.8. Tracks 463 This OPTIONAL, RECOMMENDED multi-value field indicates the coverage 464 in session and user lifecycle tracking. 466 3.4.8.1. Allowed values 468 3.4.8.1.1. none 470 Each event that is collected is anonymous. There is no way to 471 connect and group multiple pageviews by user or similar. This value 472 MUST NOT be used in conjunction with other values. 474 3.4.8.1.2. sessions 476 Metrics that source from a single browser session can be grouped and 477 distinguished as such. 479 3.4.8.1.3. users 481 Users can be identified across multiple browser sessions. 483 3.4.8.2. Example 485 Tracks: sessions, users 487 3.4.9. Varies 489 This OPTIONAL, RECOMMENDED single-value field indicates the usage of 490 content experiments like A/B testing. It MUST contain a single value 491 only. 493 3.4.9.1. Allowed values 495 3.4.9.1.1. none 497 All users are served the same content without any changes. This 498 value MUST NOT be used in conjunction with other values. 500 3.4.9.1.2. random 502 Content experiments are performed by grouping users randomly into 503 buckets and serving them different content. 505 3.4.9.1.3. behavioral 507 Content experiments are performed by grouping users into buckets 508 based on their behavior and serving them different content. 510 3.4.9.2. Example 512 Varies: random 514 3.4.10. Shares 516 This OPTIONAL, RECOMMENDED multi-value field indicates whether data 517 is shared with select users, the general public or third parties. 519 3.4.10.1. Allowed values 521 3.4.10.1.1. none 523 The data collected is not shared with any party unless directly 524 affiliated with the implementor, e.g. employees. 526 3.4.10.1.2. per-user 528 Users can access the usage data that is associated with them in a 529 non-aggregated way, isolating all data that is specific to their 530 current means of re-identification. 532 3.4.10.1.3. general-public 534 Usage statistics for the site or service are available to the general 535 public. 537 3.4.10.1.4. third-party 539 Data is being shared non-publicly with third parties. This MUST also 540 be specified when datasets are aggregated or pseudonymized 541 beforehand. 543 3.4.10.2. Example 545 Shares: general-public 547 3.4.11. Implements 549 This OPTIONAL field indicates conformance with existing regulations 550 and legislation. Values for this field SHOULD use all lowercase 551 tokens with whitespace being replaced by the dash character (%x2d). 552 This field SHOULD only be added if it makes the setup described by 553 the file easier to understand for human users. 555 Example values are: 557 * gdpr 559 * ccpa 561 3.4.11.1. Example 563 Implements: gdpr, ccpa 565 3.4.12. Deploys 567 This OPTIONAL field indicates which software is being used for 568 collecting analytics. Values for this field SHOULD use all lowercase 569 tokens with whitespace being replaced by the dash character (%x2d). 570 This field SHOULD only be added if it makes the setup described by 571 the file easier to understand for human users. 573 Example values are: 575 * google-analytics 577 * plausible 579 * hotjar 581 * matomo 583 3.4.12.1. Example 585 Deploys: google-analytics, hotjar 587 3.5. Examples of analytics.txt files 589 3.5.1. A site using analytics 591 # analytics.txt file for www.example.com 592 Author: Jane Doe 594 Collects: url, referrer, device-type 595 Stores: first-party-cookies, local-storage 596 # Usage data is encrypted end-to-end 597 Uses: javascript 598 # Users can also delete their usage data only without opting out 599 Allows: opt-in, opt-out 600 # Data is retained for 6 months 601 Retains: P6M 603 # Optional fields 604 Honors: none 605 Tracks: sessions, users 606 Varies: none 607 Shares: per-user 608 Implements: gdpr 610 3.5.2. Specifying required fields only 612 Author: John Doe 613 Collects: url, ip-address, geo-location, user-agent, referrer, device-type, custom-events 614 Stores: none 615 Uses: javascript 616 Allows: none 617 Retains: perpetual 619 3.5.3. A site not using any analytics 620 # analytics.txt file for www.example.com 621 Author: Jane Doe 622 Collects: none 624 4. Location of the analytics.txt file 626 By default, an analytics.txt file SHOULD be placed in the ".well- 627 known" path as per [RFC8615] of a domain name or IP address. 629 4.1. Alternatives 631 In case implementors are unable to meet this requirement, other 632 options are available. 634 4.1.1. link Tag 636 Implementors MAY signal the location of an analytics.txt file in the 637 context of a HTML document using a link element of rel "analytics" 639 Example: 641 643 4.1.2. HTTP Header 645 Implementors MAY send an HTTP header of "X-Analytics-Txt" with a 646 response, sending the URI of the applicable file. 648 Example: 650 X-Analytics-Txt: https://example.com/resources/analytics.txt 652 4.2. Precedence 654 In case multiple of these signals are being used, the precedence 655 taken is: 657 1. X-Analytics-Txt Header 659 2. link element 661 3. ".well-known" location 663 4.3. Scope of a file 665 An analytics.txt file located in the ".well-known" location MUST only 666 apply to the domain or IP address of the URI used to retrieve it, and 667 SHALL NOT apply to any of its subdomains or parent domains. If the 668 location is signaled using the HTTP Header or in the document markup 669 itself, its scope SHALL be limited to the requested resource only. 671 If distributed in non-standard locations, an analytics.txt file MAY 672 also apply to products and services provided by the organization 673 publishing the file (e.g. desktop or mobile applications) and which 674 cannot be mapped to a domain name or IP address. In such cases, 675 implementors MUST add sufficient commentary describing the applicable 676 scope. 678 5. Security Considerations 680 5.1. Incorrect or stale information 682 If information given in an "analytics.txt" file is incorrect or not 683 kept up to date, this can result in usage of services under wrong 684 assumptions, thus exposing users to possibly unwanted data collection 685 and handling. Not having an "analytics.txt" file may be preferable 686 to having incorrect or stale information in this file. This 687 guideline also applies to field level: in case of ambiguities or 688 uncertainties, it's recommended to omit a field or a value rather 689 than providing incorrect information. Implementors MUST use the 690 "Author" field (see Section 3.4.1) to allow inquiries about the 691 correctness of the given information. 693 5.2. Spam 695 Implementors should be aware that disclosing mandatory author 696 information as per Section 3.4.1 in such a file exposes them to 697 possible Spam schemes or spurious requests. 699 5.3. Multi-user environments 701 In multi-user / multi-tenant environments, it may possible for a 702 single user to take over the location of the "/.well-known/ 703 security.txt" file which would also apply to others. Organizations 704 should ensure the ".well-known" location is properly protected. 705 Implementors can instead use other locations as per Section 4 in such 706 scenarios. 708 6. IANA Considerations 710 6.1. Well-Known URIs registry 712 The "Well-Known URIs" registry should be updated with the following 713 additional values (using the template from [RFC8615]): 715 URI suffix: analytics.txt 717 Specification document(s): this document 719 Status: permanent 721 7. References 723 7.1. Normative References 725 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 726 Requirement Levels", BCP 14, RFC 2119, 727 DOI 10.17487/RFC2119, March 1997, 728 . 730 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 731 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 732 . 734 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 735 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 736 May 2017, . 738 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 739 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 740 . 742 7.2. Informative References 744 [DNT] Fielding, R.T. and D. Singer, "Tracking Preference 745 Expression (DNT)", n.d., 746 . 748 [GPC] Berjon, R., Zimmeck, S., Soltani, A., Harbage, D., and P. 749 Snyder, "Global Privacy Control (GPC)", n.d., 750 . 752 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 753 Specifications: ABNF", STD 68, RFC 5234, 754 DOI 10.17487/RFC5234, January 2008, 755 . 757 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 758 DOI 10.17487/RFC5322, October 2008, 759 . 761 Authors' Addresses 763 Frederik Ring 764 Offen 766 Email: frederik.ring@gmail.com 768 Hendrik Niefeld 769 Offen 771 Email: hello@niefeld.com