# drafts

name: draft-han-rtgwg-codeployment-pfc-fgfc
rev: 02
title: Use cases and Requirement for Flow Control Collaboration Across DCNs and WAN
time: 2026-02-28T10:56:30Z
group_uri: /api/v1/group/group/1027/
expires: 2026-09-01T10:56:30Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:12.944625+00:00
abstract:
  The demand for lossless network transmission and the application of
     flow control mechanisms have expanded from DCNs (Data Center
     Networks) to WANs(Wide Area Networks).  To mitigate PFC - related
     issues in WANs, the fine - grained flow control is proposed.  This
     mechanism aims to achieve precise control at flow / tenant levels,
     limits flow control to specified paths and slices, and provides
     intelligent congestion backpressure.  As current DCN already adopts
     PFC mechanisms, the fine-grained flow control in WANs needs to work
     with PFC in DCNs to achieve end-to-end flow control.  This document
     describes the use cases and requirements for the collaboration of
     flow control mechanisms across DCNs and WANs.

full_text:
  RTGWG                                                        Z. Han, Ed.
  Internet-Draft                                                   R. Pang
  Intended status: Standards Track                                  Y. Yue
  Expires: 1 September 2026                                   China Unicom
                                                                   J. Dong
                                                       Huawei Technologies
                                                                   Z. Ruan
                                                              China Unicom
                                                                  Q. Xiong
                                                           ZTE Corporation
                                                          28 February 2026


  Use cases and Requirement for Flow Control Collaboration Across DCNs and
                                    WAN
                  draft-han-rtgwg-codeployment-pfc-fgfc-02

  Abstract

     The demand for lossless network transmission and the application of
     flow control mechanisms have expanded from DCNs (Data Center
     Networks) to WANs(Wide Area Networks).  To mitigate PFC - related
     issues in WANs, the fine - grained flow control is proposed.  This
     mechanism aims to achieve precise control at flow / tenant levels,
     limits flow control to specified paths and slices, and provides
     intelligent congestion backpressure.  As current DCN already adopts
     PFC mechanisms, the fine-grained flow control in WANs needs to work
     with PFC in DCNs to achieve end-to-end flow control.  This document
     describes the use cases and requirements for the collaboration of
     flow control mechanisms across DCNs and WANs.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 1 September 2026.




  Han, et al.             Expires 1 September 2026                [Page 1]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction and Background {#intro and backg}  . . . . . . .   2
     2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Collaboration deployment scenarios of PFC and fine-grained Flow
             Control . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Interworking between PFC and fine-Grained Flow Control  . . .   5
       4.1.  PFC to fine-grained flow control  . . . . . . . . . . . .   5
       4.2.  Fine-grained flow control to PFC  . . . . . . . . . . . .   6
     5.  Requirement of collaboration deployment . . . . . . . . . . .   7
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.  Informative References  . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction and Background {#intro and backg}

     DCNs are typically characterized by a limited network scale, short
     path and predictable traffic patterns, so flow control mechanisms
     like PFC (Priority Flow Control) and ECN (Explicit Congestion
     Notification) operate effectively.  With the growth of AI LLM
     distributed training and inference, lossless transmission of massive
     data between geographically separated data centers is required
     [I-D.hs-rtgwg-wan-lossless-uc], and the flow control mechanisms need
     to be extended from DCNs to WANs.  Unlike DCNs, WANs are large-scale
     with complex topologies, long paths, and diverse traffic type.  PFC
     based on port-level feedback ensures lossless transmission of RDMA
     protocol, by pausing/resuming specific priority queues to prevent
     congestion.  When using it in the WANs, the backpressure from PFC
     will cause head-of-line blocking, deadlocks, and congestion
     spreading, which degrade network throughput.  To mitigate these
     issues in [I-D.dong-fantel-problem-statement], the fine - grained
     flow control is required for WANs.




  Han, et al.             Expires 1 September 2026                [Page 2]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


     Fine-grained flow control improves upon the coarse-grained port-based
     PFC mechanism.  It enables precise control at the flow, tenant, or
     other granular levels, limits flow control to specified paths and
     slices, and provides intelligent congestion backpressure with
     granular parameters (pausing time, backpressure bandwidth, flow
     identifier etc.).  These capabilities collectively contribute to
     achieving efficient and refined flow control in WANs
     [I-D.han-rtgwg-fine-grained-backpressure].

     This draft focuses on the scenarios where PFC is employed in DCNs and
     the fine-grained flow control is utilized in WANs.  Usecase and
     requirements for the interworking deployment of PFC and fine-grained
     flow control mechanisms are described, achieving end-to-end flow
     control through coordination and policy mapping between DCNs and
     WANs.

  2.  Terminology

     PFC: Priority-based Flow Control

     DCN: Data Center Network

     WAN: Wide Area Network

     RDMA: Remote Direct Memory Access

     RoCE: RDMA over Converged Ethernet

  3.  Collaboration deployment scenarios of PFC and fine-grained Flow
      Control

     +----------+                                        +----------+
  -- |   Data   |                                        |   Data   |--
   ^ | center A |                                        | center B | ^
   | +----------+                                        +----------+ |
   |      |                                                   |       |
   |PFC   |                                                   |    PFC|
   |      v                                                   v       |
   v    +----+ ----> +----+ ----> +----+ ----> +----+ ----> +----+    v
  --    | R1 |       | R2 |       | R3 |       | R4 |       | R5 |   --
        +----+       +----+       +----+       +----+       +----+
          |                                                   |
          |-------------------------------------------------->|
                   fine-grained flow control over WAN

       Figure 1: Codeployment of PFC and fine-grained flow control





  Han, et al.             Expires 1 September 2026                [Page 3]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


     As shown in Figure 1, there are two data centers, A and B.The
     internal nodes of data center A and data center B employ the PFC
     mechanism.  Because most DCN NICs today are optimized for legacy
     protocols (e.g., Ethernet, DCB) and lack SRv6 processing
     capabilities.  This limitation prevents the direct extension for
     refined flow control.  Hardware/firmware upgrades are needed to
     enable fine-grained flow control deployment.

     All or some of the WAN nodes R1-R5 support fine-grained flow control
     [I-D.han-rtgwg-fine-grained-backpressure] to mitigate PFC
     backpressure issues, enabling flow/tenant-level congestion handling
     with granular parameters for precise and intelligent backpressure.
     These nodes also support HQoS (Hierarchical Quality of Service)
     queuing mechanisms and slicing.

     Edge nodes R1 and R5 support both PFC and fine-grained flow
     control[I-D.han-rtgwg-fine-grained-backpressure] , interworking DCN
     and WAN flow control mechanisms and ensuring seamless end-to-end flow
     control.  The NNI ports of edge nodes R5 and R1 can establish
     multiple slices, each corresponding to a tenant and supporting 1-8
     queues.

     Based on factors such as distance, number of users, network topology
     and node capabilities in WAN, the interworking and collaboration
     scenarios of PFC and fine-grained flow control can be classified into
     the following two categories.

     1) Single-hop direct interconnection without intermediate node
     participation

     In this scenario, Data Center A and Data Center B are directly
     connected through edge node R1 and R5 with a single hop, without any
     intermediate devices in between, or intermediate nodes (R2, R3, R4)
     are legacy network devices that whithout flow control capability.  In
     this case, intermediate nodes do not participate in the flow control
     process, and a tunnel is established between R1 and R5 to transmit
     fine-grained flow control packet.

     2) Multi-hop interconnection scenario with intermediate node
     participation

     In this scenario, Data Center A and Data Center B are connected by
     WAN via nodes R1 -> R2 -> R3 -> R4 -> R5.Intermediate nodes R2, R3,
     and R4 (or a subset of them) support fine-grained flow control
     capabilities.  These intermediate nodes actively participate in the
     flow control process.  The WAN nodes can adopt either hop-by-hop
     backpressure or cross-hop Backpressure mechanisms
     [I-D.ruan-spring-priority-flow-control-sid] to handle congestion.



  Han, et al.             Expires 1 September 2026                [Page 4]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


  4.  Interworking between PFC and fine-Grained Flow Control

  4.1.  PFC to fine-grained flow control

     tenant traffic
   |------------>
  +--------------+
  | Slice ID = 1 |
  +--------------+                                            Congestion Occurs
        |                                                           |
        |                                                           |
        v                                                           v
      ---->  +--- +  -2/0/0  1/0/0-   +----+  -2/0/0  3/0/0-   +----------+
             | Rx |  -------------->  | R5 |  -------------->  |   Data   |
             |    |                   |    |                   | center B |
             +----+                   +----+                   +----------+
                      <- - - - - - - -|        <- - - - - - - -|
                 fine-grained flow control     PFC backpressure
                    backpressure packet              frame
                            ^
                            |
                            |
                     +--------------+
                     | Slice ID = 1 |
                     +--------------+
                     +--------------+
                     | Slice ID = N |
                     +--------------+

                Figure 2: PFC to fine-grained flow control

     Edge node R5 responds to the PFC frame sent by the data center and
     transmits fine - grained flow control packet
     [I-D.han-rtgwg-fine-grained-backpressure] to the WAN.  The process
     follows these steps:

     1) When congestion occurs at the incoming port 3/0/0 of data center
     B.

     2) The data center B sends a PFC backpressure frame to the 2/0/0 port
     of edge node R5.  The PFC frame carries the queue priority of the
     traffic to be backpressured, which is af1.

     3) Edge node R5 needs to support responding to the PFC frame and
     buffers the traffic with the priority af1 through the 2/0/0 physical
     port.





  Han, et al.             Expires 1 September 2026                [Page 5]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


     4) The 1/0/0 port of edge device R5 has multiple slices.  When the
     buffer queue corresponding to the 2/0/0 port of edge device R5
     reaches the buffer threshold.

     5) According to the port, tenant traffic, and slice mapping
     relationship, the 1/0/0 port of edge device R5 sends a fine - grained
     flow control backpressure packet to the network node Rx.  Rx is the
     upstream network node with fine-grained flow control capability, it
     can be the intermediate node or the edge node R1 in WAN for different
     deployment scenarios mentioned in clause 3.  The packet carries the
     tenant traffic information to be backpressured, with the queue
     priority af1, sliceID, and pause time, etc.

     6) Based on the congestion handling situation, if the RX node fails
     to resolve the congestion:

     * For multi-hop scenario mentioned in clause 3 , the RX node sends fine-grained flow control packets to upstream WAN nodes as needed;

     * For the single-hop scenario mentioned in clause 3, where RX is edge node R1, the RX node sends PFC frames to the DCN as needed.

  4.2.  Fine-grained flow control to PFC

                                    +--------------+
                                    | Slice ID = 1 |
                                    +--------------+
                                            |         Congestion Occurs
                                            |              |
                                            v              |
                                      tenant traffic       v
                  |--------------------------------------------->
     +----------+  -3/0/0  2/0/0-   +----+  -1/0/0-     +----+
     |   Data   |  -------------->  | R1 |  --------->  | Rx |
     | Center A |                   |    |              |    |
     +----------+                   +----+              +----+
                    <- - - - - - - -|         <- - - - -|
                 PFC backpressure frame   fine-grained flow
                                         control backpressure
                                                 ^
                                                 |
                                                 |
                                          +--------------+
                                          | Slice ID = 1 |
                                          +--------------+

                   Figure 3: fine-grained flow control to PFC






  Han, et al.             Expires 1 September 2026                [Page 6]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


     Edge node R1 responds to fine - grained flow control
     packet[I-D.han-rtgwg-fine-grained-backpressure] from WAN, then sends
     PFC frame to the data center.  The process follows these steps:

     1) When congestion occurs in the traffic of queue af1 with sliceID =
     1 at the egress port of network node R2.

     2) Network node Rx sends a fine - grained flow control backpressure
     packet to edge node R1.  This packet carries the tenant traffic
     information to be backpressured, with the queue priority af1, sliceID
     = 1, and the pause timed, etc.

     3) Edge node R1 performs traffic control and buffers the tenant
     traffic with priority af1 and sliceID = 1.

     4) When the buffer queue corresponding to port 1/0/0 of edge device
     R1 reaches the buffer threshold, port 2/0/0 of edge node R1 sends
     backpressure to the data center according to the standard PFC packet.

     5) Data center A performs standard PFC backpressure and stops all
     traffic with priority af1 destined for port 3/0/0.

  5.  Requirement of collaboration deployment

     Requirement 1: Edge node needs support the coordination and
     bidirectional translation between the fine-grained flow control
     mechanism in the WAN and the PFC mechanism in the DCN, enabling
     seamless end-to-end flow control across WAN and DCN domains.

     Requirement 2: Edge node needs to respond to PFC frames from the DCN.
     It includes the following capabilities:

     1) Learn task flow-to-port mappings to identify affected traffic;

     2) Configure appropriate buffer thresholds;

     3) Generate and send fine-grained flow control messages to WAN nodes
     with granular parameters.

     Requirement 3: Edge nodes needs to respond to fine-grained flow
     control messages from the WAN.  It includes the following
     capabilities:

     1) Use established flow-to-port mappings to determine target DCN
     ports;

     2) Configure appropriate buffer thresholds;




  Han, et al.             Expires 1 September 2026                [Page 7]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


     3) Generate and send standard PFC frames to corresponding DCN ports.

  6.  Security Considerations

     This document does not introduce any new security considerations.

  7.  IANA Considerations

     This document has no IANA actions.

  8.  Informative References

     [I-D.hs-rtgwg-wan-lossless-uc]
                Zhengxin, H., He, T., Shi, H., and T. Zhou, "Use Cases and
                Requirements for Implementing Lossless Techniques in Wide
                Area Networks", Work in Progress, Internet-Draft, draft-
                hs-rtgwg-wan-lossless-uc-01, 2 July 2025,
                <https://datatracker.ietf.org/doc/html/draft-hs-rtgwg-wan-
                lossless-uc-01>.

     [I-D.dong-fantel-problem-statement]
                Dong, J., McBride, M., Clad, F., Zhang, Z. J., Zhu, Y.,
                Xu, X., Zhuang, R., Pang, R., Lu, H., Liu, Y., Contreras,
                L. M., Mehmet, D., and R. Rahman, "Fast Network
                Notifications Problem Statement", Work in Progress,
                Internet-Draft, draft-dong-fantel-problem-statement-05, 2
                February 2026, <https://datatracker.ietf.org/doc/html/
                draft-dong-fantel-problem-statement-05>.

     [I-D.han-rtgwg-fine-grained-backpressure]
                Zhengxin, H., Pang, R., Ruan, Z., and X. Yi, "Fine-Grained
                Flow Control Backpressure Mechanism for Wide Area
                Networks", Work in Progress, Internet-Draft, draft-han-
                rtgwg-fine-grained-backpressure-00, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-han-rtgwg-
                fine-grained-backpressure-00>.

     [I-D.ruan-spring-priority-flow-control-sid]
                Ruan, Z., Liu, Y., Han, M., Han, Z., and Y. Liu, "SRv6
                behavior extention for Flow Control in WAN", Work in
                Progress, Internet-Draft, draft-ruan-spring-priority-flow-
                control-sid-03, 27 February 2026,
                <https://datatracker.ietf.org/doc/html/draft-ruan-spring-
                priority-flow-control-sid-03>.

  Authors' Addresses





  Han, et al.             Expires 1 September 2026                [Page 8]


  Internet-Draft  Req of PFC and fine-grained flow control   February 2026


     Zhengxin Han (editor)
     China Unicom
     Beijing
     China
     Email: hanzx21@chinaunicom.cn


     Ran Pang
     China Unicom
     Beijing
     China
     Email: pangran@chinaunicom.cn


     Yi Yue
     China Unicom
     Beijing
     China
     Email: yuey80@chinaunicom.cn


     Jie Dong
     Huawei Technologies
     Email: jie.dong@huawei.com


     Zheng Ruan
     China Unicom
     Email: ruanz6@chinaunicom.cn


     Quan Xiong
     ZTE Corporation
     Email: xiong.quan@zte.com.cn

















  Han, et al.             Expires 1 September 2026                [Page 9]


name: draft-ahc-green-smartpdu-yang
rev: 00
title: A YANG Model for SmartPDU Monitoring and Control
time: 2025-10-20T21:15:11Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T21:15:11Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Data formats/interop", "Policy/governance"]
tags: []
fetched_at: 2026-03-03T15:50:12.944656+00:00
abstract:
  This document defines a YANG data model for Smart Power Distribution
     Units (SmartPDUs).  SmartPDUs extend traditional PDUs by
     incorporating telemetry and remote control functions that enable
     detailed monitoring and management of energy consumption.  Current
     SmartPDU solutions are largely proprietary, exposing heterogeneous
     APIs and data formats that complicate integration and automation.
     The proposed YANG model provides a vendor-neutral framework for
     configuration, monitoring, and control of intelligent power
     distribution systems.

     An initial version of the proposed YANG data model has been developed
     during the GREEN Framework and Use Cases project at the Hackathon
     performed during IETF 123 (July 2025).

full_text:
  GREEN                                                          O. Abboud
  Internet-Draft                                                 A. Hecker
  Intended status: Informational                       Huawei Technologies
  Expires: 23 April 2026                                   L. M. Contreras
                                                                Telefonica
                                                           20 October 2025


              A YANG Model for SmartPDU Monitoring and Control
                      draft-ahc-green-smartpdu-yang-00

  Abstract

     This document defines a YANG data model for Smart Power Distribution
     Units (SmartPDUs).  SmartPDUs extend traditional PDUs by
     incorporating telemetry and remote control functions that enable
     detailed monitoring and management of energy consumption.  Current
     SmartPDU solutions are largely proprietary, exposing heterogeneous
     APIs and data formats that complicate integration and automation.
     The proposed YANG model provides a vendor-neutral framework for
     configuration, monitoring, and control of intelligent power
     distribution systems.

     An initial version of the proposed YANG data model has been developed
     during the GREEN Framework and Use Cases project at the Hackathon
     performed during IETF 123 (July 2025).

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 23 April 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.



  Abboud, et al.            Expires 23 April 2026                 [Page 1]


  Internet-Draft                SmartPDU YANG                 October 2025


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Functional Components and YANG module positioning . . . . . .   4
     4.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   5
     5.  YANG data model for SmartPDUs . . . . . . . . . . . . . . . .   6
     6.  Security and operational considerations . . . . . . . . . . .   7
     7.  Informative References  . . . . . . . . . . . . . . . . . . .   7
     Appendix A.  Implementation status  . . . . . . . . . . . . . . .   8
     Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     Power Distribution Units (PDUs) are a basic component of both data
     center and network infrastructures, providing power delivery,
     protection, and monitoring capabilities to connected equipment (e.g.,
     routers, servers, etc).  With the evolution towards the notion of
     SmartPDUs, which integrate advanced telemetry and remote control
     functions, operators can achieve finer-grained visibility and
     management of energy consumption across their technical facilities.

     However, current SmartPDU implementations are largely proprietary.
     Different vendors expose distinct APIs and data formats for
     monitoring and control, leading to significant challenges in
     integration and automation.  The lack of a common data framework
     hinders interoperability and makes it difficult to achieve consistent
     energy management across heterogeneous devices.

     Furthermore, without a standardized architecture, real-time
     aggregation of energy usage data across multiple PDUs and vendors is
     cumbersome and often requires custom software adaptation.  This
     fragmentation limits the ability of infrastructure operators to
     automate energy-saving policies, perform coordinated power control,
     and support sustainability objectives.






  Abboud, et al.            Expires 23 April 2026                 [Page 2]


  Internet-Draft                SmartPDU YANG                 October 2025


     To address these challenges, this document proposes a YANG data model
     for SmartPDUs.  The model intends to provide a vendor-neutral,
     structured framework for configuration, monitoring, and control of
     intelligent power distribution systems.  It aims to enable
     interoperable management of SmartPDUs, support real-time energy
     telemetry collection, and facilitate integration with higher-level
     management and analytics systems.

     The proposed YANG model aligns with ongoing efforts in the IETF to
     promote standardized network and infrastructure management through
     YANG-based interfaces.  It is intended to serve as a foundation for
     consistent, automated, and energy-efficient power management across
     diverse networked environments.

  2.  Use Cases

     A number of use cases justify the convenience of defining a YANG data
     model for facilitating the operation of SmartPDUs.  The following are
     some exemplary use cases which can be benefited of the availability
     of an SmartPDU YANG model:

     *  Data centers with a focus on green computing and energy
        efficiency.  Modern data centers aim to minimize power consumption
        and carbon footprint.  A standardized SmartPDU YANG model enables
        consistent configuration and telemetry interfaces for energy-aware
        infrastructure components, supporting sustainable operations and
        regulatory compliance.

     *  Real-time monitoring of energy consumption (EC) across different
        network equipment.  Operators require fine-grained and real-time
        visibility into the energy consumption of servers, switches,
        routers, and other devices.  A common YANG model allows uniform
        data collection and reporting of EC metrics across heterogeneous
        PDUs, facilitating proactive energy management and fault
        detection.

     *  Ability to control and remotely shut down certain PDU ports, even
        across devices from different vendors.  In multi-vendor
        environments, proprietary interfaces hinder remote control and
        automation.  A standardized YANG model provides vendor-independent
        mechanisms to enable, disable, or schedule PDU outlets, improving
        operational efficiency and safety during maintenance or energy-
        saving actions.








  Abboud, et al.            Expires 23 April 2026                 [Page 3]


  Internet-Draft                SmartPDU YANG                 October 2025


     *  Automatic load balancing or power capping to optimize energy use.
        Dynamic power distribution requires coordination between PDUs and
        higher-level orchestration systems.  A SmartPDU YANG model offers
        standardized configuration and telemetry hooks to support
        automated load balancing, power capping, and policy-based
        optimization.

     *  Integration with higher-level management systems for reporting and
        analytics.  Energy data from PDUs is increasingly valuable for
        analytics and sustainability dashboards.  A consistent YANG
        interface simplifies integration with network management,
        telemetry collectors, and AI-driven analytics platforms, reducing
        integration costs and promoting interoperability.

     *  Tighter integration with software power management techniques.  As
        servers and network elements implement software-based power
        management (e.g., CPU frequency scaling, sleep states),
        coordination with physical power infrastructure becomes critical.
        A SmartPDU YANG model bridges this gap, enabling end-to-end power
        control workflows through standardized APIs.

  3.  Functional Components and YANG module positioning

     The proposed YANG data model assumes the existence of adaptors to
     vendor-specific APIs, according to the following scheme.

      +-----------------------------------------------------------+
      |  DCIM / NMS / Orchestrator (RESTCONF Client)              |
      |  - Queries /energy-monitoring via RESTCONF                |
      |  - Aggregates multi-device data                                                   |
      |  - Unified API, device reg, automation, etc...            |                        |
      +---------------------A-------------------------------------+
                            |
                       RESTCONF/YANG <-- proposed SmartPDU YANG module
                            |
      +---------------------V-------------------------------------+
      |  Common RESTCONF Wrapper                                  |
      |  - Exposes standardized YANG model                        |
      |  - Adapts vendor API                                      |
      |  - Vendor Adapter Plugins: Vendor A , Vendor B, etc...    |
      +---------------------A-------------------------------------+
                            |
                      Vendor-native API
                            |
      +---------------------V-------------------------------------+
      |  Smart PDU Hardware (Vendor-specific implementation)      |
      +-----------------------------------------------------------+




  Abboud, et al.            Expires 23 April 2026                 [Page 4]


  Internet-Draft                SmartPDU YANG                 October 2025


     It is assumed these functional components being part of the framework
     defined in [I-D.belmq-green-framework].

  4.  Design Principles

     The definition of the SmartPDU YANG data model follows a set of key
     principles intended to ensure interoperability, extensibility, and
     operational efficiency across heterogeneous environments.  These
     principles guide the model structure, data organization, and
     management interfaces to support a unified approach to energy
     monitoring and control.

     *  Unified and Vendor-Neutral Access Layer.  The model defines a
        unified management layer that enables querying and control of any
        SmartPDU device, regardless of vendor implementation.  This
        abstraction allows consistent access to monitoring and
        configuration data through standardized YANG-based interfaces.

     *  Capability Discovery.  The model provides mechanisms to discover
        device capabilities related to power management and energy-saving
        functions.  This includes identifying supported control features,
        outlet-level granularity, available telemetry, and automation
        support.

     *  Real-Time Energy Consumption Monitoring.  Support is included for
        retrieving real-time energy consumption (EC) data both at the
        device level and for individual outlets.  Such information enables
        operators to perform detailed energy analysis, trend tracking, and
        optimization of power usage.

     *  Outlet-Level Control.  The model supports remote control of
        individual outlets, including the ability to trigger operations
        such as shutdown, power-cycle, or state toggling where supported
        by the underlying device.

     *  RESTCONF-Based Access and Extensibility.  The model is designed to
        operate over RESTCONF, providing a standardized management
        interface.  To accommodate heterogeneous environments, vendor-
        specific extensions can be integrated through adapter plugins,
        enabling multi-vendor interoperability while preserving
        standardized core functions.

     *  Fine-Grained Energy Management.  Through outlet-level telemetry
        and control, the model facilitates fine-grained management of
        energy resources.  This capability supports precise monitoring,
        fault isolation, and localized optimization actions.





  Abboud, et al.            Expires 23 April 2026                 [Page 5]


  Internet-Draft                SmartPDU YANG                 October 2025


     *  Cross-Vendor Interoperability.  Interoperability across PDUs from
        different vendors is a core objective.  The model defines common
        data structures and operational semantics to ensure consistent
        control and reporting, enabling unified management of mixed-device
        deployments.

     *  Support for Automated Energy Policies.  The model enables
        automation frameworks to implement energy-saving policies such as
        power capping, load balancing, and scheduled shutdowns.

     *  Event Notifications and Alarms.  To support real-time operational
        awareness, the model defines mechanisms for notifications and
        alarms.  These events can be used to signal threshold violations,
        power faults, or changes in device state, facilitating responsive
        and automated management.

  5.  YANG data model for SmartPDUs

     The follwoing model is defined for the operation on SmartPDUs.

   module: pdu-common
     +--rw pdu-system
     |  +--rw manufacturer?       string
     |  +--rw model?              string
     |  +--rw serial-number?      string
     |  +--rw firmware-version?   string
     |  +--rw ip-address?         inet:ip-address
     |  +--rw uptime?             yang:counter64
     |  +--rw temperature?        decimal64
     |  +--rw humidity?           decimal64
     |
     +--rw network
     |  +--rw ip-address?          inet:ip-address
     |  +--rw subnet-mask?         inet:ip-address
     |  +--rw gateway?             inet:ip-address
     |  +--rw snmp-enabled?        boolean
     |  +--rw restconf-enabled?    boolean
     |  +--rw netconf-enabled?     boolean
     |
     +--rw input-lines
     |  +--rw line* [id]
     |     +--rw id            string
     |     +--rw voltage?      decimal64
     |     +--rw current?      decimal64
     |     +--rw frequency?    decimal64
     |     +--rw power?        decimal64
     |     +--rw energy?       decimal64
     |     +--rw status?       enumeration { ok, warning, fault }



  Abboud, et al.            Expires 23 April 2026                 [Page 6]


  Internet-Draft                SmartPDU YANG                 October 2025


     |
     +--rw outlets
     |  +--rw outlet* [id]
     |     +--rw id?             string
     |     +--rw label?          string
     |     +--rw voltage?        decimal64
     |     +--rw current?        decimal64
     |     +--rw power?          decimal64
     |     +--rw energy?         decimal64
     |     +--rw power-factor?   decimal64
     |     +--rw status?         enumeration { on, off, error, unknown }
     |     +--rw admin-state?    enumeration { on, off, reboot }
     |     +--rw last-change?    yang:date-and-time
     |     +--rw lock-state?     boolean
     |
     +--rw sensors
     |  +--rw sensor* [id]
     |     +--rw id?        string
     |     +--rw type?      enumeration { temperature, humidity, airflow }
     |     +--rw value?     decimal64
     |     +--rw unit?      string
     |     +--rw status?    enumeration { ok, warning, fault }
     |
     +--rw thresholds
        +--rw threshold* [label]
           +--rw label?        string
           +--rw parameter?    string
           +--rw low-limit?    decimal64
           +--rw high-limit?   decimal64
           +--rw action?       enumeration { alert, shutdown, ignore }

  6.  Security and operational considerations

     To be provided.

  7.  Informative References

     [I-D.belmq-green-framework]
                Claise, B., Contreras, L. M., Lindblad, J., Palmero, M.,
                Stephan, E., and Q. Wu, "Framework for Energy Efficiency
                Management", Work in Progress, Internet-Draft, draft-
                belmq-green-framework-06, 20 October 2025,
                <https://datatracker.ietf.org/doc/html/draft-belmq-green-
                framework-06>.







  Abboud, et al.            Expires 23 April 2026                 [Page 7]


  Internet-Draft                SmartPDU YANG                 October 2025


  Appendix A.  Implementation status

     An initial version of the proposed YANG data model has been developed
     during the GREEN Framework and Use Cases project at the Hackathon
     performed during IETF 123 (July 2025).

  Acknowledgements

     This work has been partially funded by the Smart Networks and
     Services Joint Undertaking (SNS JU) under the European Union's
     Horizon Europe research and innovation project Exigence (Grant
     Agreement no. 101139120).

  Authors' Addresses

     Osama Abboud
     Huawei Technologies
     Germany
     Email: osama.abboud@huawei.com


     Artur Hecker
     Huawei Technologies
     Germany
     Email: artur.hecker@huawei.com


     Luis M. Contreras
     Telefonica
     Ronda de la Comunicacion, s/n
     28050 Madrid
     Spain
     Email: luismiguel.contrerasmurillo@telefonica.com
     URI:   http://lmcontreras.com

















  Abboud, et al.            Expires 23 April 2026                 [Page 8]


name: draft-li-cdn-node-selection-enhancement
rev: 00
title: CDN Node Selection Enhancement using Anycast and QUIC
time: 2025-11-07T01:19:45Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-11T01:19:45Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Autonomous netops"]
tags: []
fetched_at: 2026-03-03T15:50:12.944707+00:00
abstract:
  Content Delivery Networks (CDNs) are critical infrastructure for
     improving user experience by serving content from geographically
     proximate servers.  Traditional CDN node selection mechanisms, such
     as DNS-based redirection and BGP-based anycast, primarily rely on
     network proximity and often lack awareness of server load or specific
     application requirements.  This can lead to suboptimal performance
     and inefficient resource utilization.

     This document proposes an enhanced mechanism for dynamic CDN node
     selection that leverages IPv4/v6 anycast, BGP, and the QUIC transport
     protocol.  The proposed solution enables CDN nodes to advertise or
     withdraw their anycast routes based on real-time load and link
     quality.  Furthermore, it defines a mechanism for clients to signal
     their service requirements (e.g., high-compute, low-latency, or high-
     bandwidth) and for servers to redirect clients to more optimal nodes
     using QUIC's connection migration capabilities.  This allows for a
     more intelligent, load-aware, and application-aware CDN node
     selection process.

full_text:
  QUIC Working Group                                                 Z. Li
  Internet-Draft                                                     Z. Du
  Intended status: Standards Track                            China Mobile
  Expires: 10 May 2026                                            W. Cheng
                                                                   J. Wang
                                                                    Centec
                                                           6 November 2025


           CDN Node Selection Enhancement using Anycast and QUIC
                 draft-li-cdn-node-selection-enhancement-00

  Abstract

     Content Delivery Networks (CDNs) are critical infrastructure for
     improving user experience by serving content from geographically
     proximate servers.  Traditional CDN node selection mechanisms, such
     as DNS-based redirection and BGP-based anycast, primarily rely on
     network proximity and often lack awareness of server load or specific
     application requirements.  This can lead to suboptimal performance
     and inefficient resource utilization.

     This document proposes an enhanced mechanism for dynamic CDN node
     selection that leverages IPv4/v6 anycast, BGP, and the QUIC transport
     protocol.  The proposed solution enables CDN nodes to advertise or
     withdraw their anycast routes based on real-time load and link
     quality.  Furthermore, it defines a mechanism for clients to signal
     their service requirements (e.g., high-compute, low-latency, or high-
     bandwidth) and for servers to redirect clients to more optimal nodes
     using QUIC's connection migration capabilities.  This allows for a
     more intelligent, load-aware, and application-aware CDN node
     selection process.

  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
     document are to be interpreted as described in .

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.



  Li, et al.                 Expires 10 May 2026                  [Page 1]


  Internet-Draft        CDN Node Selection with QUIC         November 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 10 May 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Solution  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  Best Effort (BE) Mode . . . . . . . . . . . . . . . . . . . .   4
     5.  Traffic Engineering (TE) Mode . . . . . . . . . . . . . . . .   5
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     With the proliferation of latency-sensitive and resource-intensive
     applications, the performance of application servers has become a
     decisive factor in user engagement and loyalty.  CDNs enhance user
     experience by caching content closer to end-users, thereby reducing
     latency.  The efficiency of a CDN system heavily relies on its
     ability to select an optimal server node for each client request.

     Current prevalent node selection mechanisms include:

     1.  DNS-based redirection: Resolves a hostname to the IP address of a
         topologically "close" server, typically based on the client's DNS
         resolver location.





  Li, et al.                 Expires 10 May 2026                  [Page 2]


  Internet-Draft        CDN Node Selection with QUIC         November 2025


     2.  Anycast routing: A single IP address is assigned to multiple
         servers.  Network routing protocols direct the client's packets
         to the server that is "closest" in terms of network topology.

     These methods, while effective at reducing network latency, generally
     fail to account for the real-time load on CDN servers or the specific
     needs of different applications (e.g., compute-intensive vs.
     bandwidth-intensive).

     This document specifies a solution that integrates BGP-controlled
     anycast with advanced features of the QUIC protocol.  It enables
     load-aware route advertisement and provides a standardized way for
     clients to be redirected to more suitable CDN nodes without
     terminating their session, leveraging QUIC's connection migration
     feature.

  2.  Problem Statement

     DNS-based and anycast-based CDN selection schemes primarily optimize
     for network distance.

     This document aims to address these issues by creating a more
     dynamic, load-aware, and application-aware selection mechanism that
     minimizes service disruption.

     Existing CDN node selection solutions have the following limitations:

     1.  *DNS-based Redirection and Basic Anycast*:

         *  Select nodes based on network distance (not server load),
            leading to load imbalance;

         *  Cannot differentiate service types (e.g., low-latency vs.
            high-bandwidth), resulting in suboptimal service quality;

         *  Poor real-time performance and scalability;

         *  Route reconfiguration often causes connection interruptions.

     2.  *Service-specific Optimization*:

         *  Typically non-standard (e.g., video-only protocols), leading
            to poor compatibility and universality across different
            services.







  Li, et al.                 Expires 10 May 2026                  [Page 3]


  Internet-Draft        CDN Node Selection with QUIC         November 2025


  3.  Solution

     This document proposes a distributed dynamic CDN node selection
     method based on IPv4/v6 Anycast and QUIC.  The method considers
     server load (CPU utilization, remaining computing power), service
     requirements (high bandwidth, low latency, high computing power), and
     supports seamless scaling.  Key network elements include:

     *  *CDN Client*: Initiates service requests via IPv4/v6 Anycast and
        QUIC, processes responses, and supports QUIC connection migration.

     *  *CDN Server*: Configured with IPv4/v6 Anycast addresses;
        advertises/withdraws Anycast routes via BGP based on load;
        receives and responds to QUIC requests; caches resources from
        origin servers.

     The solution supports two working modes: BE (Best Effort) and TE
     (Traffic Engineering).

  4.  Best Effort (BE) Mode

     In BE mode, the system provides basic load-aware routing and
     resilience.

     1.  Each CDN Node is configured with an IPv4/v6 anycast address.

     2.  The CDN Node dynamically manages the BGP advertisement of its
         anycast address based on its status.  For example:

         *  If the CPU load is below a threshold (e.g., 80%) and the link
            to its gateway router is not congested (e.g., RTT <= 1.5 *
            baseline RTT), the node advertises a route for the anycast
            address via BGP.

         *  If the CPU load exceeds the threshold or the link becomes
            congested, the node withdraws the BGP route.

     3.  A client sends its initial QUIC packets to the anycast address.
         BGP directs these packets to the topologically nearest CDN Node
         that is currently advertising the route.

     4.  If the serving CDN Node becomes unavailable (e.g., because it
         withdraws its BGP route due to overload), the client's subsequent
         packets will be routed to the next-nearest available node.  The
         client detects this path change and uses QUIC's connection
         migration feature RFC9000 to seamlessly continue the session with
         the new node without re-establishing the connection.




  Li, et al.                 Expires 10 May 2026                  [Page 4]


  Internet-Draft        CDN Node Selection with QUIC         November 2025


  5.  Traffic Engineering (TE) Mode

     TE mode extends BE mode by allowing for more granular, application-
     aware node selection.

     In TE mode, CDN Nodes are assumed to have knowledge of their ranking
     relative to other nodes within a specific domain (e.g., all nodes
     serving a particular region).  This ranking is based on three key
     metrics:

     *  Compute Power (Kn): A rank indicating the node's available
        computing capacity (e.g., based on FLOPS).  A lower Kn value might
        indicate higher available compute.

     *  Latency (Dn): A rank based on the baseline network latency from
        the node to its gateway, indicating its proximity to the network
        edge.  A lower Dn value indicates lower latency.

     *  Bandwidth (Bn): A rank representing the node's available network
        bandwidth.  A lower Bn value might indicate higher available
        bandwidth.

     The specific mechanism by which nodes discover each other and
     determine these ranks (e.g., via a centralized controller or a
     distributed discovery protocol) is outside the scope of this
     document.

  6.  Security Considerations

     TBD.

  7.  IANA Considerations

     TBD.

  Authors' Addresses

     Zhiqiang Li
     China Mobile
     Beijing
     100053
     China
     Email: lizhiqiangyjy@chinamobile.com








  Li, et al.                 Expires 10 May 2026                  [Page 5]


  Internet-Draft        CDN Node Selection with QUIC         November 2025


     Zongpeng Du
     China Mobile
     Beijing
     100053
     China
     Email: duzongpeng@chinamobile.com


     Wei Cheng
     Centec
     Suzhou
     215000
     China
     Email: chengw@centec.com


     Junjie Wang
     Centec
     Suzhou
     21500
     China
     Email: wangjj@centec.com





























  Li, et al.                 Expires 10 May 2026                  [Page 6]


name: draft-kartha-internet20-ainative
rev: 00
title: Internet 2.0: An Intent-Aware, AI-Native Extension of the Web
time: 2025-11-20T12:21:32Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-24T12:21:31Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Model serving/inference", "Agent discovery/reg", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:12.944714+00:00
abstract:
  This document proposes Internet 2.0, an AI-native extension of the
     traditional web architecture.  Unlike the current internet—which is
     designed primarily for document retrieval—Internet 2.0 enables
     distributed model discovery, intent-based routing, and protocol-level
     AI interaction.  Core components include HTTP+AI, an AI-aware
     extension to HTTP; the Model Resolution Network (MRN), an AI-native
     analogue to DNS; and the AI-Aware Browser, a new class of client
     optimized for intelligent interaction rather than document traversal.
     This architecture treats AI models as first-class network entities
     and provides a foundation for a decentralized, semantic, and privacy-
     preserving AI layer on the internet.

full_text:
  Network Working Group                                          G. Kartha
  Internet-Draft                                          20 November 2025
  Intended status: Informational                                          
  Expires: 24 May 2026


       Internet 2.0: An Intent-Aware, AI-Native Extension of the Web
                    draft-kartha-internet20-ainative-00

  Abstract

     This document proposes Internet 2.0, an AI-native extension of the
     traditional web architecture.  Unlike the current internet—which is
     designed primarily for document retrieval—Internet 2.0 enables
     distributed model discovery, intent-based routing, and protocol-level
     AI interaction.  Core components include HTTP+AI, an AI-aware
     extension to HTTP; the Model Resolution Network (MRN), an AI-native
     analogue to DNS; and the AI-Aware Browser, a new class of client
     optimized for intelligent interaction rather than document traversal.
     This architecture treats AI models as first-class network entities
     and provides a foundation for a decentralized, semantic, and privacy-
     preserving AI layer on the internet.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 24 May 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.



  Kartha                     Expires 24 May 2026                  [Page 1]


  Internet-Draft          Internet 2.0 Architecture          November 2025


     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     2.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
     3.  Copyright Notice  . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     5.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     6.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   5
     8.  Benefits  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     9.  Architectural Overview  . . . . . . . . . . . . . . . . . . .   5
     10. HTTP+AI Protocol  . . . . . . . . . . . . . . . . . . . . . .   6
       10.1.  AI URI Scheme  . . . . . . . . . . . . . . . . . . . . .   6
       10.2.  New HTTP Header Fields . . . . . . . . . . . . . . . . .   7
         10.2.1.  AI-Intent Header Field (Request) . . . . . . . . . .   7
         10.2.2.  AI-Capability Header Field (Request) . . . . . . . .   7
         10.2.3.  AI-Privacy Header Field (Request)  . . . . . . . . .   7
         10.2.4.  AI-Latency-Target Header Field (Request) . . . . . .   7
         10.2.5.  AI-Model-ID Header Field (Response)  . . . . . . . .   8
         10.2.6.  AI-Confidence Header Field (Response)  . . . . . . .   8
       10.3.  Request Semantics  . . . . . . . . . . . . . . . . . . .   8
       10.4.  Response Semantics . . . . . . . . . . . . . . . . . . .   9
       10.5.  Error Codes  . . . . . . . . . . . . . . . . . . . . . .   9
     11. Model Resolution Network (MRN)  . . . . . . . . . . . . . . .   9
       11.1.  MRN Architecture . . . . . . . . . . . . . . . . . . . .  10
       11.2.  Resolution Workflow  . . . . . . . . . . . . . . . . . .  10
       11.3.  Vector-Based Routing . . . . . . . . . . . . . . . . . .  10
     12. AI-Aware Browser  . . . . . . . . . . . . . . . . . . . . . .  10
       12.1.  Core Capabilities  . . . . . . . . . . . . . . . . . . .  10
     13. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  11
       13.1.  Software Development . . . . . . . . . . . . . . . . . .  11
       13.2.  Medical Symptom Analysis . . . . . . . . . . . . . . . .  11
     14. Security Considerations . . . . . . . . . . . . . . . . . . .  11
       14.1.  MRec Authentication  . . . . . . . . . . . . . . . . . .  11
       14.2.  Intent Privacy . . . . . . . . . . . . . . . . . . . . .  11
       14.3.  Model Poisoning  . . . . . . . . . . . . . . . . . . . .  11
     15. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  11
     16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
       16.1.  New URI Scheme . . . . . . . . . . . . . . . . . . . . .  12
       16.2.  New HTTP Header Fields . . . . . . . . . . . . . . . . .  12
       16.3.  New Status Codes . . . . . . . . . . . . . . . . . . . .  12
       16.4.  AI-Privacy Constraint Tokens Registry  . . . . . . . . .  12



  Kartha                     Expires 24 May 2026                  [Page 2]


  Internet-Draft          Internet 2.0 Architecture          November 2025


     17. Discussion and Future Work  . . . . . . . . . . . . . . . . .  12
     18. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     19. Appendix A: Model Record (MRec) Specification . . . . . . . .  13
       19.1.  MRec Required Fields . . . . . . . . . . . . . . . . . .  13
     20. Appendix B: Intent-to-Model Workflow Diagram  . . . . . . . .  14
     21. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

  1.  Requirements Language

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Status of This Memo

     This document is not an Internet Standards Track specification; it is
     published for examination, experimental implementation, and
     evaluation.

     This document defines an Experimental Protocol for the Internet
     community.  This is a contribution to the RFC Series, independently
     of any other RFC stream.  The RFC Editor has chosen to publish this
     document at its discretion and makes no statement about its value for
     implementation or deployment.  Documents approved for publication by
     the RFC Editor are not candidates for any level of Internet Standard;
     see Section 2 of RFC 7841.

     Information about the current status of this document, any errata,
     and how to provide feedback on it may be obtained at https://www.rfc-
     editor.org/info/rfcXXXX.

  3.  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.







  Kartha                     Expires 24 May 2026                  [Page 3]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  4.  Introduction

     The web evolved from static hypertext into dynamic, socially
     interactive platforms, yet its foundations continue to center around
     documents, URLs, and link traversal.  Modern AI usage has shifted
     user expectations away from link retrieval toward synthesized answers
     and goal-oriented assistance.  However, AI systems remain isolated
     behind proprietary APIs without integration into the underlying
     architecture of the internet.

     Internet 2.0 proposes a protocol-level expansion where AI models are
     discoverable, routable, and composable across the network.  This
     document defines three components supporting this architecture: (1)
     HTTP+AI as an AI-aware request protocol; (2) the Model Resolution
     Network as a semantic analog to DNS; and (3) the AI-Aware Browser as
     the primary user interface.  The objective is not to replace the
     existing internet, but to extend it with a distributed, intelligent
     mesh capable of resolving intents, negotiating capabilities, and
     enabling privacy-preserving inference.

  5.  Terminology

     Intent: A structured representation of a user’s goal expressed in
     natural language.

     Intent Vector: The numerical embedding derived from natural language
     input.

     Model Resolution Network (MRN): A hierarchical discovery network
     resolving intents to model endpoints.

     Model Record (MRec): A signed metadata object describing model
     identity, capabilities, trust score, and endpoint (formally defined
     in Appendix A).

     HTTP+AI: An extension of HTTP supporting AI-specific negotiation
     fields.

     AI-Aware Browser: A client capable of rendering synthesized answers
     and invoking distributed models.











  Kartha                     Expires 24 May 2026                  [Page 4]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  6.  Background

     The traditional internet was designed for navigating and retrieving
     documents, not for understanding or synthesizing information.  Users
     rely on keyword-based search engines that return lists of URLs,
     requiring manual extraction of relevant knowledge.  This document-
     centric model has become increasingly insufficient as AI systems take
     on roles in programming assistance, legal summarization, medical
     triage, and enterprise knowledge retrieval.  [Internet20-Paper]

     Large language models have shifted user expectations from link
     retrieval to synthesized, goal-oriented answers.  However, these
     models operate behind proprietary APIs, lack standard discovery
     mechanisms, and remain centralized and cloud-bound.  Traditional
     browsers are unaware of model semantics, capabilities, or privacy
     requirements.  These architectural gaps motivate the design of
     Internet 2.0.  [Internet20-Paper]

  7.  Problem Statement

     The traditional internet was not designed for AI-native interaction.
     Limitations include document-centric retrieval, lack of intent-based
     routing, no AI model discovery mechanism, centralized cloud APIs, and
     absence of standard metadata describing model capabilities.  These
     limitations hinder decentralization, privacy, and modular AI
     deployment.

     Internet 2.0 aims to support semantic routing, model negotiation, and
     privacy-aware edge-based inference.

  8.  Benefits

     Internet 2.0 enables multiple benefits across domains, including
     developer tools, enterprise knowledge search, IoT edge inference,
     education and research assistance, and regulated workloads in
     healthcare, law, and compliance.  These capabilities arise from the
     discoverability and composability of models in the MRN, along with
     privacy-aware execution pathways.  [Internet20-Paper]

  9.  Architectural Overview

     Internet 2.0 introduces an AI-native mesh layer composed of HTTP+AI,
     MRN, MRecs, and AI-aware browsers.  The architecture enables a
     workflow where user intent is embedded, resolved through MRN, and
     executed through selected models.

     User -> AI Browser -> MRN -> Model Selection ->
       HTTP+AI -> Model Execution -> Response



  Kartha                     Expires 24 May 2026                  [Page 5]


  Internet-Draft          Internet 2.0 Architecture          November 2025


     The system supports privacy-aware routing, latency constraints,
     capability filtering, caching, and federated model registries.  The
     detailed workflow is illustrated in Appendix B.

  10.  HTTP+AI Protocol

     HTTP+AI is an extension of HTTP enabling semantic intent-based
     communication between clients and AI model endpoints.  This section
     defines the URI scheme, ABNF syntax, header field definitions,
     request/response rules, and error codes.

  10.1.  AI URI Scheme

     The ai URI scheme is used for intent-based requests.  It is
     syntactically compatible with generic URIs but introduces AI-specific
     query parameters.  The scheme is defined using Augmented Backus–Naur
     Form (ABNF) as specified in [RFC5234].

   ai-URI              = "ai:" "//" authority ai-path [ "?" ai-query ]

   authority           = host [ ":" port ]
   ai-path             = path-abempty
   ai-query            = intent-param *( "&" ai-param )

   intent-param        = "intent=" qchar-1plus

   ai-param            = capability-param
                       / privacy-param
                       / latency-param
                       / ai-token-param

   capability-param    = "capability=" qchar-1plus
   privacy-param       = "privacy=" qchar-1plus
   latency-param       = "latency-target=" 1*DIGIT
   ai-token-param      = "token=" qchar-1plus

   qchar-1plus         = 1*qchar
   qchar               = unreserved / pct-encoded / sub-delims / ":" / "@"

     Example:

     ai://models.example.com/query?
       intent=optimize+python+script&
       capability=code-optimization&
       privacy=local-preferred&
       latency-target=100





  Kartha                     Expires 24 May 2026                  [Page 6]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  10.2.  New HTTP Header Fields

     The following header fields are defined for use with HTTP+AI and
     requested for registration in the "Permanent Message Header Field
     Registry" (Section 16.2).

  10.2.1.  AI-Intent Header Field (Request)

     The AI-Intent header conveys the full, un-encoded natural-language
     description of the user's goal.  It SHOULD be used by the MRN for
     generating the precise Intent Vector.

     AI-Intent = "AI-Intent:" OWS quoted-string

     Example:

     AI-Intent: "optimize this python script for speed"

  10.2.2.  AI-Capability Header Field (Request)

     The AI-Capability header indicates required model skills needed for
     routing and negotiation (e.g., code-generation, medical-dermatology).

     AI-Capability = "AI-Capability:" OWS token *( OWS "," OWS token )

     Example:

     AI-Capability: code-optimization, python

  10.2.3.  AI-Privacy Header Field (Request)

     The AI-Privacy header indicates privacy constraints for routing and
     model selection.  The value SHALL be a token registered in the IANA
     "AI-Privacy Constraint Tokens" registry (Section 16.4).

     AI-Privacy = "AI-Privacy:" OWS token

     Example:

     AI-Privacy: regulated

  10.2.4.  AI-Latency-Target Header Field (Request)

     The AI-Latency-Target header conveys the client's latency expectation
     in milliseconds.  The MRN SHOULD use this value to filter MRecs based
     on performance metrics.  The value represents the time in
     milliseconds.




  Kartha                     Expires 24 May 2026                  [Page 7]


  Internet-Draft          Internet 2.0 Architecture          November 2025


     AI-Latency-Target = "AI-Latency-Target:" OWS 1*DIGIT

     Example:

     AI-Latency-Target: 120

  10.2.5.  AI-Model-ID Header Field (Response)

     The AI-Model-ID header is returned in the response and contains the
     `ModelID` of the specific MRec that successfully executed the
     inference.

     AI-Model-ID = "AI-Model-ID:" OWS quoted-string

  10.2.6.  AI-Confidence Header Field (Response)

     The AI-Confidence header is returned in the response and contains a
     float (0.0 to 1.0) indicating the model's self-assessed confidence in
     the generated result.

     AI-Confidence = "AI-Confidence:" OWS 1*DIGIT
                     [ "." 1*DIGIT ]  ; float 0.0–1.0

  10.3.  Request Semantics

     A valid HTTP+AI request MUST contain at least:

     *  The AI-Intent header.

     *  Either an ai URI or an HTTP(s) URI resolved by the MRN.

     *  HTTP method GET or POST.

     Example HTTP+AI request:

     GET ai://query?intent=optimize+python+script HTTP/1.1
     Host: models.example.com
     AI-Intent: "optimize python script"
     AI-Capability: code-optimization, python
     AI-Privacy: local-preferred
     AI-Latency-Target: 100










  Kartha                     Expires 24 May 2026                  [Page 8]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  10.4.  Response Semantics

     The response to an HTTP+AI inference request SHOULD include the AI-
     Model-ID and AI-Confidence headers (defined above) to aid the AI-
     Aware Browser in interpreting the result and verifying provenance.
     The response body SHOULD contain the structured inference output
     (e.g., JSON).

     Example response:

     HTTP/1.1 200 OK
     Content-Type: application/json
     AI-Model-ID: org.example.model.v1
     AI-Confidence: 0.91

     {
       "result": "Here is the optimized Python script...",
       "explanation": "Loop unrolling improves speed.",
       "metrics": { "latency_ms": 85 }
     }

  10.5.  Error Codes

     HTTP+AI defines the following additional status codes for
     registration in the HTTP Status Code registry (Section 16.3):

     *  450 AI-Model-Ambiguous — The MRN resolved the intent to multiple
        models with similar confidence, and the client MUST re-query with
        more specific constraints.

     *  451 AI-Low-Confidence — The selected model executed the inference
        but returned a confidence score below a client threshold.  The
        client SHOULD warn the user.

     *  453 AI-Privacy-Constraint-Failed — The MRN could not locate any
        model matching the required AI-Privacy constraint.

  11.  Model Resolution Network (MRN)

     The Model Resolution Network (MRN) is a hierarchical, federated
     discovery system that resolves semantic intents to appropriate AI
     model endpoints.  It serves as the AI-native counterpart to the
     Domain Name System (DNS).








  Kartha                     Expires 24 May 2026                  [Page 9]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  11.1.  MRN Architecture

     MRN consists of Index Models that perform semantic search over
     registered Model Records (MRecs).  The architecture is federated,
     supporting root-level index models, domain-specific registries, and
     peer-to-peer lookup nodes.

  11.2.  Resolution Workflow

     The MRN resolution process involves:

     1.  User query parsing and intent vector embedding

     2.  Query forwarding to appropriate Index Model

     3.  Semantic search over MRec database using vector similarity

     4.  Ranking results by relevance, trust score, and performance

     5.  Returning one or more matching MRecs (defined in Appendix A) to
         the client

     The Intent Vector SHOULD conform to a consistent, standardized
     encoding format (e.g., Base64-encoded array of floating-point
     numbers) to ensure interoperability between AI-Aware Browsers and MRN
     Index Models.

  11.3.  Vector-Based Routing

     Unlike DNS's exact string matching, MRN uses semantic embedding
     similarity for routing.  Intent vectors are compared against
     capability embeddings in MRecs using cosine similarity or other
     distance metrics.

  12.  AI-Aware Browser

     The AI-Aware Browser is a specialized client interface designed for
     intent-based interaction with the AI-native internet layer.

  12.1.  Core Capabilities

     *  Accepts natural language or goal-oriented prompts

     *  Generates intent vectors from user queries

     *  Queries MRN for model discovery and selection

     *  Executes HTTP+AI requests to distributed models



  Kartha                     Expires 24 May 2026                 [Page 10]


  Internet-Draft          Internet 2.0 Architecture          November 2025


     *  Presents synthesized answers with provenance and confidence

     *  Manages conversational context and follow-up queries

  13.  Use Cases

  13.1.  Software Development

     Query: "Generate a Dockerfile for a Python FastAPI app" Workflow: MRN
     resolves to DevOps model → Returns ready-to-use Dockerfile with
     explanation and confidence score.

  13.2.  Medical Symptom Analysis

     Query: "I have red rashes on my body, possible causes?"  Workflow:
     MRN routes to certified dermatology model → Returns potential
     diagnoses with confidence levels and medical disclaimers.

  14.  Security Considerations

  14.1.  MRec Authentication

     Model Records MUST be cryptographically signed and verified to
     prevent spoofing.  The public key infrastructure for MRec signing
     SHOULD be auditable.

  14.2.  Intent Privacy

     User intents may contain sensitive information; TLS encryption and
     privacy-preserving embedding techniques are RECOMMENDED.

  14.3.  Model Poisoning

     MRN implementations SHOULD implement trust scoring and reputation
     systems to mitigate malicious model registration.  Provenance data in
     the HTTP+AI response SHOULD link the answer to the verified MRec.

  15.  Privacy Considerations

     The architecture supports local-device inference, region-aware
     routing, protection of sensitive intents, and differential privacy
     for shared models.  The AI-Privacy header is the primary mechanism
     for client-mandated privacy control.

  16.  IANA Considerations

     This document requests several registrations with IANA:




  Kartha                     Expires 24 May 2026                 [Page 11]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  16.1.  New URI Scheme

     Registration of the ai URI scheme in the "Uniform Resource Identifier
     (URI) Schemes" registry is requested.

  16.2.  New HTTP Header Fields

     Registration of the following HTTP header fields in the "Permanent
     Message Header Field Registry" is requested:

     *  AI-Intent

     *  AI-Capability

     *  AI-Privacy

     *  AI-Latency-Target

     *  AI-Model-ID

     *  AI-Confidence

  16.3.  New Status Codes

     Registration of status codes 450, 451, and 453 in the "Hypertext
     Transfer Protocol (HTTP) Status Code Registry" is requested.

  16.4.  AI-Privacy Constraint Tokens Registry

     This document requests the creation of a new IANA registry named "AI-
     Privacy Constraint Tokens" to manage the field values for the `AI-
     Privacy` HTTP header.  The initial tokens SHALL be: `local-
     preferred`, `cloud-allowed`, and `regulated`.

  17.  Discussion and Future Work

     Key research challenges include authentication and safety of model
     endpoints, interoperable metadata formats, efficient caching of
     inference results, versioning and provenance tracking, and economic
     models for federated participation.  [Internet20-Paper]

     Future work includes prototyping MRN nodes using vector databases,
     defining HTTP+AI extensions, creating a lightweight AI-aware browser,
     and developing open specifications under an AI-RFC series.
     [Internet20-Paper]






  Kartha                     Expires 24 May 2026                 [Page 12]


  Internet-Draft          Internet 2.0 Architecture          November 2025


  18.  Conclusion

     Internet 2.0 proposes a protocol-level extension to treat AI models
     as first-class, discoverable network entities.  By integrating intent
     resolution, model discovery, and AI-native client interfaces, the
     architecture shifts the web from static document retrieval to
     dynamic, intelligent interaction.  It does not replace the existing
     internet but extends it with modularity, privacy, and semantic
     routing.  [Internet20-Paper]

  19.  Appendix A: Model Record (MRec) Specification

     The Model Record (MRec) is a signed JSON object that defines an AI
     model's capabilities, performance characteristics, and deployment
     information.  It is the core record type for the MRN.

     {
       "ModelID": "org.example.model.v1",
       "Endpoint": "https://models.example.com/infer",
       "Capabilities": ["python", "fastapi", "asyncio"],
       "Version": "1.2.0",
       "Privacy": "edge-local",
       "TrustScore": 0.92,
       "TTL": 3600,
       "LatencyMetrics": { "avg_ms": 85 },
       "Authentication": "<cryptographic-signature>"
     }

  19.1.  MRec Required Fields

     The following fields are REQUIRED in a valid MRec:

     *  ModelID: Globally unique hierarchical identifier (string).

     *  Endpoint: Network address for HTTP+AI inference requests (URI).

     *  Capabilities: Array of domain/task keywords (string array).

     *  Version: Model version string (string).

     *  TTL: Time-to-live in seconds for caching (integer).

     *  Privacy: Token defined in the "AI-Privacy Constraint Tokens" IANA
        registry (string).

     *  TrustScore: Metric (0.0 to 1.0) indicating verified reliability
        (float).




  Kartha                     Expires 24 May 2026                 [Page 13]


  Internet-Draft          Internet 2.0 Architecture          November 2025


     *  Authentication: Cryptographic signature over the MRec object,
        using an IETF-specified algorithm (e.g., ECDSA over JWS).

  20.  Appendix B: Intent-to-Model Workflow Diagram

     The following sequence diagram illustrates the workflow for intent
     resolution within MRN.

     User         AI-Browser        MRN         Model
       |                |            |             |
       |--"intent"---->|            |             |
       |                |--intent_vec-->|             |
       |                |            |--search-->|
       |                |<--MRecs-------|             |
       |                |---HTTP+AI--------------->|
       |                |<--response---------------|
       |<--answer------|            |             |

  21.  References

     [RFC2119]  IETF, "Key words for use in RFCs to Indicate Requirement
                Levels", March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  IETF, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key
                Words", May 2017,
                <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", January 2008,
                <https://www.rfc-editor.org/rfc/rfc5234>.

     [Internet20-Paper]
                Gokul Kartha, "Internet 2.0: An Intent-Aware, AI-Native
                Extension of the Web", 2025,
                <https://engrxiv.org/preprint/view/5800/9663>.

  Author's Address

     Gokul Kartha
     Email: kartha.gokul@gmail.com
     URI:   https://www.techysaint.com/.well-known/ietf-draft









  Kartha                     Expires 24 May 2026                 [Page 14]


name: draft-xsaopig-nsttlp-traffic-labeling
rev: 00
title: Network Service Type-Aware Traffic Labeling Protocol (NST-TLP)
time: 2026-01-29T08:47:41Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-02T08:47:41Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Autonomous netops", "Policy/governance"]
tags: []
fetched_at: 2026-03-03T15:50:12.944758+00:00
abstract:
  This document specifies a protocol mechanism for embedding service
     type identifiers into network packets in order to enable intelligent
     traffic recognition, policy-based forwarding, and resource
     optimization by network devices.  The protocol allows standardized
     service type labels to be carried in IPv4/IPv6 headers, MPLS labels,
     or Ethernet frame headers.  It is applicable to a wide range of
     services, including immersive VR (e.g., 1080p, 4K), scientific
     computing, real-time communications, and Internet of Things (IoT)
     applications.

full_text:
  Internet Engineering Task Force                                   H. Zhu
  Internet-Draft             Huazhong University of Science and Technology
  Intended status: Informational                           29 January 2026
  Expires: 2 August 2026


       Network Service Type-Aware Traffic Labeling Protocol (NST-TLP)
                  draft-xsaopig-nsttlp-traffic-labeling-00

  Abstract

     This document specifies a protocol mechanism for embedding service
     type identifiers into network packets in order to enable intelligent
     traffic recognition, policy-based forwarding, and resource
     optimization by network devices.  The protocol allows standardized
     service type labels to be carried in IPv4/IPv6 headers, MPLS labels,
     or Ethernet frame headers.  It is applicable to a wide range of
     services, including immersive VR (e.g., 1080p, 4K), scientific
     computing, real-time communications, and Internet of Things (IoT)
     applications.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 2 August 2026.

  Copyright Notice

     Copyright (c) 2026 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components



  Zhu                       Expires 2 August 2026                 [Page 1]


  Internet-Draft                   NST-TLP                    January 2026


     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   2
     2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     5.  Terms and Definitions . . . . . . . . . . . . . . . . . . . .   4
     6.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   4
     7.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
       7.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   4
     8.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .   4
       8.1.  Design Principles . . . . . . . . . . . . . . . . . . . .   5
       8.2.  System Components and Workflow  . . . . . . . . . . . . .   5
     9.  Label Format  . . . . . . . . . . . . . . . . . . . . . . . .   7
     10. Label Encoding and Registry . . . . . . . . . . . . . . . . .   8
       10.1.  NST-TLP Service Class Registry . . . . . . . . . . . . .   8
       10.2.  NST-TLP Sub-Class Registries . . . . . . . . . . . . . .   9
       10.3.  Example of a Complete Label Encoding . . . . . . . . . .   9
     11. Label Insertion and Handling  . . . . . . . . . . . . . . . .  10
       11.1.  Labeling Points  . . . . . . . . . . . . . . . . . . . .  10
       11.2.  Label Processing Rules . . . . . . . . . . . . . . . . .  11
     12. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  12
       12.1.  Immersive VR/AR Service Assurance  . . . . . . . . . . .  12
       12.2.  High-Performance and Scientific Computing Networks . . .  12
       12.3.  Critical IoT and Industrial Control  . . . . . . . . . .  13
       12.4.  Real-Time Communication Quality Improvement  . . . . . .  13
       12.5.  Cross-Domain Network Slicing and Service Chaining  . . .  13
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  14
       13.1.  Label Forgery and Spoofing . . . . . . . . . . . . . . .  14
       13.2.  Information Disclosure and Privacy . . . . . . . . . . .  14
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     15. Normative References  . . . . . . . . . . . . . . . . . . . .  14
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF).  They may be
     updated, replaced, or obsoleted by other documents at any time.  It
     is inappropriate to use Internet-Drafts as reference material or to
     cite them other than as "work in progress".




  Zhu                       Expires 2 August 2026                 [Page 2]


  Internet-Draft                   NST-TLP                    January 2026


  2.  Introduction

     With the diversification of network service types, traffic flows
     exhibit significantly different requirements in terms of latency,
     bandwidth, jitter, and packet loss.  Traditional network devices have
     limited visibility into application-layer semantics, resulting in
     coarse-grained and inefficient resource allocation.

     This document proposes a lightweight and extensible traffic labeling
     protocol that enables network devices to apply differentiated
     forwarding and resource management policies based on service type,
     without relying on deep packet inspection (DPI) or maintaining
     complex per-flow state.

  3.  Conventions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] and [RFC8174].

  4.  Scope

     This specification defines a standardized service type labeling
     mechanism to enhance network awareness of application requirements
     and to enable more precise and automated policy enforcement.

     The protocol applies primarily to IP-based networks (IPv4 and IPv6),
     and can be extended to other data plane protocols that support label
     insertion, such as MPLS and selected Ethernet frame formats.

     Labeling points may include end hosts, edge gateways, or SDN
     controllers.  Label-aware nodes include routers, switches, firewalls,
     and virtualized network functions capable of interpreting NST-TLP
     labels and enforcing differentiated forwarding, QoS, traffic
     engineering, or resource scheduling policies.

     The target services are those with significantly differentiated
     network requirements, such as immersive AR/VR, high-performance
     scientific computing, industrial control signaling, high-priority IoT
     telemetry, and interactive real-time communications.

     This document does not fully specify the complete service type
     taxonomy.  Service type registries are maintained through IANA as
     described in Section 8.  Deployment of NST-TLP is incremental and
     does not require universal support within a network domain.





  Zhu                       Expires 2 August 2026                 [Page 3]


  Internet-Draft                   NST-TLP                    January 2026


  5.  Terms and Definitions

     Service Type: A standardized code identifying an application traffic
     category (e.g., "VR-1080p", "Scientific-Computing").

     Traffic Label: A field embedded in a packet header that carries the
     service type identifier.

     Labeling Point: A network entity responsible for inserting labels
     into packets.

     Label-Aware Node: A network device capable of recognizing labels and
     applying policies accordingly.

  6.  Abbreviations

     QoS: Quality of Service

  7.  Protocol Overview

     NST-TLP provides a standardized mechanism to translate application
     semantics into compact, machine-readable labels that are carried in-
     band within packet headers.  This enables network devices to perform
     service-aware forwarding without requiring DPI or complex flow
     classification.

  7.1.  Design Principles

     In-band Signaling: Labels are carried within packets to ensure
     synchronization between traffic and policy.

     Incremental Deployment: Networks may contain a mix of label-aware and
     unaware nodes.  Unaware nodes forward packets according to existing
     protocol rules.

     Separation of Semantics and Policy: Labels convey service semantics
     only.  Forwarding actions are determined by local or controller-based
     policy tables.

  8.  Protocol Overview

     The Network Service Type-Aware Traffic Labeling Protocol (NST-TLP) is
     a lightweight and extensible mechanism that provides standardized
     service type identification for network packets.  Its fundamental
     objective is to translate application- or service-level semantics
     (e.g., service category and quality requirements) into a compact,
     machine-readable label carried in-band within packet headers.




  Zhu                       Expires 2 August 2026                 [Page 4]


  Internet-Draft                   NST-TLP                    January 2026


     By embedding service type information directly into packet headers,
     network devices along the forwarding path can recognize the service
     attributes of traffic flows and apply appropriate forwarding,
     scheduling, or resource management policies without relying on deep
     packet inspection (DPI) or maintaining complex per-flow state.

  8.1.  Design Principles

     The design of NST-TLP follows these principles:

     In-band Signaling: The service type label is carried as part of the
     packet itself, ensuring strict synchronization between traffic and
     policy enforcement.  This avoids the latency and consistency issues
     associated with out-of-band signaling mechanisms.

     Incremental Deployment: NST-TLP is designed to support coexistence of
     label-aware and label-unaware nodes within the same network.  Nodes
     that do not support NST-TLP MUST ignore the label and forward packets
     according to the standard processing rules of the underlying protocol
     (e.g., IPv4 options or IPv6 extension header handling).

     Separation of Semantics and Policy: The NST-TLP label conveys only
     standardized service type semantics and does not prescribe specific
     forwarding actions.  Concrete actions (e.g., queue selection, path
     computation, or rate limiting) are determined by local policy or by
     controller-provided policy mapping tables.  This separation provides
     operational flexibility for network administrators.

  8.2.  System Components and Workflow

     A typical NST-TLP system involves the following logical components
     and their interactions:



















  Zhu                       Expires 2 August 2026                 [Page 5]


  Internet-Draft                   NST-TLP                    January 2026


     +------------------+      +-----------------------+
     |  Application /   |      |   Policy Controller   |
     |  Service         |      | (Service-to-Policy    |
     | (Service Type    |      |   Mapping, Optional)  |
     +--------+---------+      +-----------+-----------+
             |                            |
             | Service Type Indication    | Policy Distribution
             v                            v
     +--------+---------+      +-----------+-----------+
     |  Labeling Point  |      |  Label-Aware Node     |
     | (Insert NST-TLP  +------> (Parse Label, Enforce |
     |   Label)         | Data  |   Policy)            |
     | (Host / Gateway) | Flow  | (Router / Switch)    |
     +------------------+      +-----------------------+
                                         |
                                         v
                             +-----------+-----------+
                             | Label Removal / Sink  |
                             | (Optional, e.g., at   |
                             |  domain boundaries)   |
                             +-----------------------+

                                    Figure 1

     Service Type Identification and Label Generation: Service type
     information MAY be determined by the traffic source (e.g., an
     application or virtual machine network interface) or by an
     intelligent network ingress device (e.g., an SDN edge switch or
     service gateway) using traffic classification or control-plane
     instructions.  Once identified, an NST-TLP label is generated
     according to the encoding rules defined in this specification.

     Label Encapsulation: The labeling point inserts the generated NST-TLP
     label into outgoing packets.  The specific encapsulation method
     depends on the underlying network layer protocol (e.g., IPv4, IPv6,
     MPLS, or Ethernet extensions).

     Label-Based Forwarding and Policy Enforcement: NST-TLP label-aware
     nodes along the forwarding path parse the label carried in packets.
     These nodes maintain, or retrieve from a controller, a service-type-
     to-action mapping table.  Based on the Service Class, Sub-Class, and
     Priority fields, the node applies corresponding actions, such as:
     assigning packets to specific priority queues, selecting low-latency
     or high-bandwidth paths, performing traffic metering or shaping, or
     triggering monitoring and logging events.






  Zhu                       Expires 2 August 2026                 [Page 6]


  Internet-Draft                   NST-TLP                    January 2026


     Label Lifetime: The lifetime of a label is typically bound to the
     lifetime of the associated traffic flow.  A label MAY be removed at
     administrative domain boundaries (e.g., for security or policy
     reasons) or rewritten when service type mapping is required across
     domains.  At the final destination, the label is normally ignored or
     stripped by the protocol stack.

  9.  Label Format

     The NST-TLP label is encoded as a fixed-length or variable-length
     field carried within packet headers.  A recommended basic format is
     shown below.

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Version | Service Class | Sub-Class | Priority | Flow Hint  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                    Optional Metadata                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                    Figure 2

     The fields are defined as follows:

     Version (4 bits): Indicates the version of the NST-TLP format.  This
     document defines version value 1.

     Service Class (8 bits): Identifies the major service category, such
     as VR/AR, scientific computing, IoT, or real-time communication.
     Values are assigned from the IANA NST-TLP Service Class registry.

     Sub-Class (8 bits): Identifies a sub-category within a given Service
     Class, such as 1080p, 4K, or 8K for VR video services.  The
     interpretation of this field is specific to the associated Service
     Class and is defined in the corresponding sub-registry.

     Priority (4 bits): Indicates the relative priority of the traffic
     within the same Service Class or Sub-Class.  This field is intended
     to support QoS scheduling and differentiated forwarding behavior.

     Flow Hint (8 bits): A sender-assigned hint value that assists network
     devices in flow identification or load balancing.  For example, this
     field MAY be used to distinguish multiple parallel flows generated by
     the same application instance or to carry a simplified hash value for
     Equal-Cost Multi-Path (ECMP) forwarding.  The processing of this
     field is local to a network domain and its semantics are not
     guaranteed to be consistent across domains.



  Zhu                       Expires 2 August 2026                 [Page 7]


  Internet-Draft                   NST-TLP                    January 2026


     Optional Metadata (variable length): Carries additional information
     related to the service type.  The structure and semantics of this
     field are defined by the specification of the corresponding Service
     Class.  For example, for scientific computing services, the metadata
     MAY include a compact Job Identifier or communication pattern
     indicator, while for financial trading services it MAY include a
     microsecond-level timestamp.

  10.  Label Encoding and Registry

     To ensure global consistency and interoperability of NST-TLP labels,
     a public and authoritative encoding registry is required.  This
     document specifies that IANA maintains the registries for NST-TLP
     Service Classes and Sub-Classes.

     Once a value is assigned and published, its semantic meaning MUST
     remain stable across future versions of the protocol and MUST NOT be
     redefined.  All assignments MUST be supported by stable and publicly
     available technical documentation describing the characteristics of
     the service type, its typical network requirements, and the format of
     optional metadata (if applicable).

  10.1.  NST-TLP Service Class Registry

     The NST-TLP Service Class registry consists of 6-bit values (0-63).
     Each registry entry defines a major service category.

     Each registry entry includes the following fields:

     Value: A 6-bit numeric value (0-63).

     Name: An English abbreviation and full name of the service category
     (e.g., "VRAR – Virtual Reality/Augmented Reality").

     Description: A brief description of the service category and its
     typical characteristics.

     Sub-Class Specification: A reference to the RFC or stable document
     that defines the Sub-Class values for this Service Class.

     Contact: The responsible IETF working group or designated expert.

     Initial registry contents are as follows:

     *  0: RESERVED

     *  1: VRAR – Virtual Reality / Augmented Reality




  Zhu                       Expires 2 August 2026                 [Page 8]


  Internet-Draft                   NST-TLP                    January 2026


     *  2: SCICOMP – Scientific Computing

     *  3: IOTCRIT – Critical IoT Control

     *  4: RTC – Real-Time Communication (e.g., VoIP, Video Conferencing)

     *  5-31: Unassigned (reserved for future IETF allocation)

     *  32-63: Experimental/Private Use (not guaranteed to be globally
        interoperable)

  10.2.  NST-TLP Sub-Class Registries

     For each Service Class that requires detailed sub-category
     definitions, IANA SHALL maintain an associated Sub-Class registry or
     a normative appendix referenced from the main registry entry.

     For example, for Service Class 1 (VRAR), a "VRAR Sub-Class" registry
     is defined using 8-bit values.

     Example entries for the VRAR Sub-Class registry include:

     *  0: RESERVED

     *  1: VIDEO_2K (1080p)

     *  2: VIDEO_4K

     *  3: VIDEO_8K

     *  4: POSE_HIGH (high-rate pose and control signaling)

     *  5: AUDIO_3D (spatial audio)

  10.3.  Example of a Complete Label Encoding

     This section provides an illustrative example of constructing a
     complete NST-TLP label.

     Consider a 4K VR video flow that is marked as high priority and uses
     the basic label format.  The Flow Hint field is set to 0xAB.

     Service Class (VRAR): IANA-assigned value 1 (binary 00000001).

     Sub-Class (VIDEO_4K): Sub-registry value 2 (binary 00000010).

     Priority: High priority = 0001.




  Zhu                       Expires 2 August 2026                 [Page 9]


  Internet-Draft                   NST-TLP                    January 2026


     Version: Basic format = 0001.

     Flow Hint: 0xAB (binary 10101011).

     The resulting 32-bit label is:

     0001 00000001 00000010 0001 10101011

     Which corresponds to the hexadecimal value 0x10121AB.

     This 4-octet label can be inserted into an IPv6 Hop-by-Hop Options
     header or a dedicated extension header, enabling intermediate network
     devices to recognize the flow as a high-priority 4K VR service and
     apply appropriate low-latency and high-bandwidth forwarding policies.

  11.  Label Insertion and Handling

  11.1.  Labeling Points

     NST-TLP labels MAY be inserted at different points in the network,
     depending on the network architecture, policy management model, and
     device capabilities.

     End systems (e.g., hosts, servers, and user devices) are the
     preferred labeling points because they can provide the most accurate
     service type information.  Applications that support the NST-TLP API
     MAY specify the service type when creating sockets or sending data,
     and the operating system network stack is responsible for generating
     and encapsulating the corresponding label.  The operating system MAY
     also infer service type automatically based on packet characteristics
     such as destination port, transport protocol, or process context.  In
     virtualized environments, virtual network interface drivers or
     hypervisors MAY label traffic based on the service type of the
     associated virtual machine or container.

     When end systems do not support label insertion, network edge devices
     MAY perform this function.  As the first hop in the network, an edge
     device MAY insert labels based on deep packet inspection (DPI), flow
     feature analysis, or policy instructions received from a control
     plane (e.g., an SDN controller).  In mobile networks, a base station
     MAY map bearer-level QoS identifiers (e.g., QCI in LTE or 5QI in 5G)
     to NST-TLP labels.  Security gateways MAY also insert service type
     labels based on application identification results while enforcing
     security policies.

     In software-defined networking (SDN) and network function
     virtualization (NFV) environments, label insertion is more flexible.
     Using southbound interfaces (e.g., OpenFlow), controllers MAY



  Zhu                       Expires 2 August 2026                [Page 10]


  Internet-Draft                   NST-TLP                    January 2026


     instruct switches to insert labels for specific flows.  At the
     ingress of an NFV service chain, labels MAY be assigned according to
     service chain policies.

  11.2.  Label Processing Rules

     NST-TLP label-aware nodes SHOULD process labels in a consistent
     manner to ensure predictable network behavior.  A node MUST identify
     the label encapsulation location according to the packet type (e.g.,
     IPv4, IPv6, or Ethernet) and validate the label format, including the
     Version field and length.  The node MUST verify whether the Service
     Class and Sub-Class values are known.  For unknown values, the node
     SHOULD apply a default policy.

     A node MUST apply forwarding and resource management actions based on
     the label contents.  For queue scheduling, packets SHOULD be assigned
     to appropriate priority queues according to the Service Class, Sub-
     Class, and Priority fields.  For example, VR 4K traffic MAY be placed
     in a strict priority queue, while background data transfers MAY be
     assigned to a best-effort queue.  For path selection, forwarding
     decisions MAY consider the service type, such as selecting high-
     bandwidth paths for scientific computing traffic and low-latency
     paths for interactive VR traffic.  Nodes MAY reserve bandwidth or
     compute resources for specific service types.

     By default, a node SHOULD preserve the NST-TLP label and forward it
     with the packet.  In certain cases, a node MAY update the label, for
     example, by updating the Flow Hint field to reflect path changes,
     adjusting the Priority field based on congestion conditions, or
     performing service type mapping at administrative domain boundaries.

     A node SHOULD consider removing the label under the following
     conditions: when traffic leaves an NST-TLP-capable domain; when
     required by security policy; or when the packet reaches its final
     destination.

     If a label does not conform to the specified format, a node MAY
     discard the packet (in security-sensitive environments), remove the
     label and forward the packet according to default policy (in best-
     effort environments), and/or generate an error log or an ICMP error
     message (subject to local configuration).

     If no explicit policy is configured for a given Service Class or Sub-
     Class, the node SHOULD apply the default policy associated with that
     Service Class.  If no such default policy exists, the node SHOULD
     apply the lowest-priority best-effort policy.





  Zhu                       Expires 2 August 2026                [Page 11]


  Internet-Draft                   NST-TLP                    January 2026


  12.  Use Cases

     By providing standardized service type identification, NST-TLP
     enables intelligent traffic management and resource scheduling in a
     wide range of network scenarios.  This section describes
     representative use cases.

  12.1.  Immersive VR/AR Service Assurance

     VR/AR traffic is highly sensitive to latency (e.g., less than 20 ms)
     and jitter, and different sub-flows within the same session (such as
     4K video, pose tracking signaling, and haptic feedback) have
     heterogeneous bandwidth and reliability requirements.  Compared with
     using only DSCP, NST-TLP allows the network to distinguish different
     sub-flows of the same VR session and provide more fine-grained
     resource guarantees.

     A VR application or operating system marks video streams as Service
     Class: VRAR and Sub-Class: VIDEO_4K, and marks critical pose control
     signaling as Sub-Class: POSE_HIGH with Priority set to a high value.
     Access switches and core routers recognize these labels and apply
     strict priority forwarding and low-latency path selection to
     POSE_HIGH traffic, while ensuring high bandwidth and enhanced
     reliability (e.g., by using forward error correction) for VIDEO_4K
     traffic.

  12.2.  High-Performance and Scientific Computing Networks

     High-performance computing (HPC) jobs (e.g., MPI communication) often
     generate bursty elephant flows and require high throughput and low
     job completion time, while management and control traffic is latency
     sensitive.  NST-TLP improves overall cluster utilization by enabling
     the network to become computation-aware rather than a transparent
     pipe.

     A job scheduler or compute node marks MPI bulk traffic as Service
     Class: SCICOMP and Sub-Class: MPI_BULK, and MAY include a compact Job
     Identifier hash in the optional metadata.  Data center switches build
     job-aware scheduling policies, isolating SCICOMP traffic from web or
     background traffic.  For collective operations (e.g., MPI_BARRIER),
     higher-priority sub-classes MAY be used to ensure fast
     synchronization.









  Zhu                       Expires 2 August 2026                [Page 12]


  Internet-Draft                   NST-TLP                    January 2026


  12.3.  Critical IoT and Industrial Control

     Industrial IoT control signaling requires deterministic latency and
     high reliability, whereas sensor telemetry may tolerate higher delay
     and jitter.  NST-TLP enables critical control traffic to receive
     deterministic service on a shared physical network, reducing
     deployment and maintenance costs.

     Programmable logic controllers (PLCs) or gateways mark motion control
     commands as Service Class: IOTCRIT and Sub-Class: MOTION_CTRL, while
     periodic sensor data is marked as Sub-Class: TELEMETRY.  Time-
     Sensitive Networking (TSN) switches or 5G user plane functions (UPFs)
     map IOTCRIT traffic to scheduled transmission gates or guaranteed
     bit-rate bearers to ensure latency and reliability requirements.

  12.4.  Real-Time Communication Quality Improvement

     Real-time applications such as video conferencing and cloud gaming
     contain multiple traffic components, including audio, video,
     signaling, and file sharing, which require differentiated treatment.
     NST-TLP allows the network to prioritize core interactive media even
     under congestion, thereby improving user experience.

     A real-time communication client marks audio streams as Service
     Class: RTC and Sub-Class: AUDIO_INTERACTIVE, video streams as
     VIDEO_CONF, and file transfers as DATA_FILE.  Enterprise WAN
     optimization devices or provider edge routers use these labels to
     assign highest priority to audio traffic, guarantee bandwidth for
     video traffic, and rate-limit file transfers.

  12.5.  Cross-Domain Network Slicing and Service Chaining

     In network slicing and service function chaining provided by
     operators and cloud providers, a generic flow-level identifier is
     required to steer traffic through specific virtual networks or
     function chains.  NST-TLP provides a lighter-weight alternative to
     deep packet inspection and a more flexible mechanism than
     destination-based classification.

     When user traffic enters the network, ingress devices or controllers
     mark packets with slice-related NST-TLP labels, such as Service Class
     values representing eMBB or URLLC.  Sub-Class or optional metadata
     MAY indicate the required service function chain (e.g., firewall,
     intrusion detection, and video optimization).  Network nodes forward
     traffic to the corresponding virtual network functions based on these
     labels.





  Zhu                       Expires 2 August 2026                [Page 13]


  Internet-Draft                   NST-TLP                    January 2026


  13.  Security Considerations

  13.1.  Label Forgery and Spoofing

     Malicious endpoints or on-path attackers may forge or modify NST-TLP
     labels, for example, by marking bulk download traffic as high-
     priority VR traffic in order to obtain preferential treatment.  This
     results in a form of QoS theft and may degrade the service quality of
     legitimate flows.

     Mitigation strategies include rewriting or validating labels at trust
     domain boundaries (e.g., user-network interfaces), such that labels
     provided by untrusted user devices are not directly honored.  In
     high-security environments, optional metadata MAY carry a lightweight
     message authentication code (MAC) generated and verified by trusted
     anchors or controllers using shared keys.  This approach introduces
     processing overhead and MUST be carefully evaluated.

  13.2.  Information Disclosure and Privacy

     NST-TLP labels may expose sensitive information about user behavior,
     application usage, or operational status.  For example, frequent
     occurrence of SCICOMP labels may indicate that a user is performing
     scientific computing tasks.

     To mitigate privacy risks, gateways MAY map fine-grained Sub-Class
     values to coarser Service Class values when traffic traverses public
     or untrusted networks.  Labels MAY also be removed at administrative
     boundaries according to policy.  Encryption mechanisms such as IPsec
     or TLS MAY be used to protect packets carrying labels against
     eavesdropping, noting that this may limit intermediate nodes' ability
     to process the labels.

  14.  IANA Considerations

     This document requests IANA to create and maintain registries for
     NST-TLP Service Classes and Sub-Classes as described in Section 8.

  15.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", RFC 2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", RFC 8174, May 2017,
                <https://www.rfc-editor.org/info/rfc8174>.




  Zhu                       Expires 2 August 2026                [Page 14]


  Internet-Draft                   NST-TLP                    January 2026


  Authors' Addresses

     Huanxing Zhu, Huazhong University of Science and Technology, Wuhan,
     China, Email: huanxingzhu@hust.edu.cn

  Author's Address

     Huanxing Zhu
     Huazhong University of Science and Technology
     Wuhan
     China
     Email: huanxingzhu@hust.edu.cn







































  Zhu                       Expires 2 August 2026                [Page 15]


name: draft-vaughan-aipref-vocab
rev: 00
title: Vocabulary for Expressing Content Preferences for AI Training
time: 2025-07-24T07:09:02Z
group_uri: /api/v1/group/group/2440/
expires: 2025-07-24T12:37:34Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: ["Policy/governance", "Data formats/interop", "AI safety/alignment"]
tags: []
fetched_at: 2026-03-03T15:50:13.454042+00:00
abstract:
  This document proposes a vocabulary for expressing content
     preferences for rightsholders who wish to manage the use of their
     content in AI training.  This vocabulary allows publishers to express
     preferences through metadata or content-delivery protocols.  The
     vocabulary can be applied at different levels of granularity and
     incorporates preferences for permissions, usage scope, and data
     retention, providing a foundation for interoperability across various
     Internet protocols.

full_text:
  AI Preferences                                                T. Vaughan
  Internet-Draft                                   Common Crawl Foundation
  Intended status: Informational                           20 January 2025
  Expires: 24 July 2025


       Vocabulary for Expressing Content Preferences for AI Training
                       draft-vaughan-aipref-vocab-00

  Abstract

     This document proposes a vocabulary for expressing content
     preferences for rightsholders who wish to manage the use of their
     content in AI training.  This vocabulary allows publishers to express
     preferences through metadata or content-delivery protocols.  The
     vocabulary can be applied at different levels of granularity and
     incorporates preferences for permissions, usage scope, and data
     retention, providing a foundation for interoperability across various
     Internet protocols.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://thunderpoot.github.io/draft-vaughan-aipref-vocab/draft-
     vaughan-aipref-vocab.html.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-vaughan-aipref-
     vocab/.

     Discussion of this document takes place on the AI Preferences mailing
     list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/thunderpoot/draft-vaughan-aipref-vocab.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.




  Vaughan                   Expires 24 July 2025                  [Page 1]


  Internet-Draft                AIPREF Vocab                  January 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 24 July 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Vocabulary Elements / Preference Signals  . . . . . . . . . .   3
       4.1.  Permission  . . . . . . . . . . . . . . . . . . . . . . .   3
       4.2.  Purpose . . . . . . . . . . . . . . . . . . . . . . . . .   4
       4.3.  Temporal Restrictions . . . . . . . . . . . . . . . . . .   4
       4.4.  Content-Specific Granularity  . . . . . . . . . . . . . .   4
       4.5.  Content Type  . . . . . . . . . . . . . . . . . . . . . .   4
       4.6.  Derivative Content  . . . . . . . . . . . . . . . . . . .   4
       4.7.  Data Retention  . . . . . . . . . . . . . . . . . . . . .   5
       4.8.  Preference Persistence  . . . . . . . . . . . . . . . . .   5
       4.9.  Precedence  . . . . . . . . . . . . . . . . . . . . . . .   5
       4.10. Geographic Restrictions . . . . . . . . . . . . . . . . .   5
     5.  Implementation Considerations . . . . . . . . . . . . . . . .   5
       5.1.  HTTP Headers  . . . . . . . . . . . . . . . . . . . . . .   6
       5.2.  Robots Exclusion Protocol (REP) . . . . . . . . . . . . .   6
       5.3.  <meta> Tags for Sub-Document Level Control  . . . . . . .   6
       5.4.  “Well-Known” Locations  . . . . . . . . . . . . . . . . .   7
       5.5.  Embedded Metadata . . . . . . . . . . . . . . . . . . . .   9
       5.6.  Content Credentials (ISO 22144) . . . . . . . . . . . . .  10
       5.7.  ISCC (ISO 24138)  . . . . . . . . . . . . . . . . . . . .  10
     6.  Example Usage Scenarios . . . . . . . . . . . . . . . . . . .  10
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10



  Vaughan                   Expires 24 July 2025                  [Page 2]


  Internet-Draft                AIPREF Vocab                  January 2025


     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
     Appendix A.  Table of Preference Signals  . . . . . . . . . . . .  11
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     As AI models become more reliant on large-scale data (driven by
     scaling laws that link model performance to dataset size), content
     publishers seek ways to control how their content is used in training
     these models.  This draft provides a vocabulary that enables
     publishers to signal preferences for AI training concerning their
     content.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Scope

     The AI-PREF vocabulary is limited to expressing content preferences
     for AI training and does not include enforcement mechanisms or client
     authentication.  Default opt-in or opt-out statuses are beyond the
     scope of this proposal, as it focuses solely on establishing a
     standard for signalling explicit preferences.  In cases where no
     preferences are signalled, the decision on whether this constitutes
     an opt-in or opt-out should be determined at the policy level
     downstream.

     It is important to note that preference signals are advisory.

  4.  Vocabulary Elements / Preference Signals

  4.1.  Permission

     Basic indicators of whether content can be used for AI training.

     *  *allow_training*: Boolean

     *  *restricted_training:* public, non-commercial, internal, licensed





  Vaughan                   Expires 24 July 2025                  [Page 3]


  Internet-Draft                AIPREF Vocab                  January 2025


  4.2.  Purpose

     Defines acceptable uses in training.

     *  *purpose*: String:

        -  *generation*: Creating models that are capable of generating
           content

        -  *embedding*: Converting content to vector representations

           o  *classification*: Categorising or labelling content

           o  *summary*: Creating condensed versions of content

           o  *paraphrase*: Creating derivative versions of content

           o  *quotation*: Repetition of a passage or fragment of original
              content

           o  *translation*: Converting content between languages

  4.3.  Temporal Restrictions

     Specifies the date range for training use.

     *  *effective_date*: ISO 8601 Date string

     *  *expiration_date*: ISO 8601 Date string

  4.4.  Content-Specific Granularity

     Defines the scope of applicability.  Refers to the level at which
     preferences apply within the content.

     *  *scope*: global, content-specific, conditional

  4.5.  Content Type

     Specifies content types the preference applies to.

     *  *mime_type*: text, image, video, audio, application, [RFC2046].

  4.6.  Derivative Content

     Allows or restricts derivatives like summaries.

     *  *allow_derivatives*: Boolean



  Vaughan                   Expires 24 July 2025                  [Page 4]


  Internet-Draft                AIPREF Vocab                  January 2025


     *  *derivative_type*: summary, paraphrase, translation

  4.7.  Data Retention

     Defines content retention period post-training.

     *  *retention_period*: ISO 8601 Duration string (e.g.,
        P3Y6M4DT12H30M5S)

  4.8.  Preference Persistence

     Indicates if preferences should persist in derived datasets, or be
     optional.  A derived dataset is the result of processing,
     transforming, or extracting information from the original source,
     such as aggregated statistics and summaries, or subsets of data.

     *  *metadata_persistence*: Boolean

  4.9.  Precedence

     Conflicts should be resolved by assigning precedence values (e.g.,
     high, medium, low) to rules, with a defined hierarchy that allows
     content producers to override publishers, domain operators, and
     others as necessary.

     *  *precedence:* Sets priority when preferences conflict with other
        layered preferences.

  4.10.  Geographic Restrictions

     Specifies regions where preferences apply, ISO 3166-1.

     *  *geo_limitations:* Specifies geographic regions where training
        permissions apply.

  5.  Implementation Considerations

     Implementing the AI-PREF vocabulary effectively can be accomplished
     using various mechanisms, depending on the needs and existing
     infrastructure of content publishers.  Approaches include, but are
     not limited to, using HTTP headers, possible extensions to [RFC9309]
     ([PURPOSE]), and (for example) <meta> tags and other embedded data
     (such as EXIF) for sub-document-level control.








  Vaughan                   Expires 24 July 2025                  [Page 5]


  Internet-Draft                AIPREF Vocab                  January 2025


  5.1.  HTTP Headers

     Publishers can use HTTP headers to communicate AI-PREF preferences
     directly in response to client requests.  This approach allows fine-
     grained control and easy integration into existing server
     configurations.

     *Example header:*

     AI-PREF: allow_training=true; purpose=generation,classification; retention_period=P3Y6M4DT12H30M5S

     This header specifies that the content can be used for text
     generation and classification, with a retention period of 3 years, 6
     months, 4 days, 12 hours, 30 minutes, and 5 seconds.  The syntax and
     options should be carefully chosen to ensure compatibility with
     common web servers and clients.

  5.2.  Robots Exclusion Protocol (REP)

     For publishers who already use REP (as defined in RFC9309
     (https://datatracker.ietf.org/doc/rfc9309/)), extending REP rules to
     include AI-PREF preferences could be beneficial.

     Example rule:

     User-agent: *
     Allow-Training: non-commercial
     Purpose: embedding, summarisation

     This REP rule specifies that all user agents are allowed to use the
     content for non-commercial AI training, limited to embedding and
     summarisation purposes.  Further extensions to REP could specify
     additional constraints, such as geographic limitations or temporal
     restrictions.

  5.3.  <meta> Tags for Sub-Document Level Control

     To specify AI-PREF preferences at the level of individual HTML
     documents or specific parts of a document, <meta> tags and HTML
     attributes can be used.

     Example <meta> tag:

     <meta name="AI-PREF" content="allow_training=false; retention_period=0">

     Example HTML attribute:

     <div data-aipref="allow_training=false; retention_period=0">



  Vaughan                   Expires 24 July 2025                  [Page 6]


  Internet-Draft                AIPREF Vocab                  January 2025


     The methods above specify that AI training is not allowed for the
     content of this document, with no retention period permitted. <meta>
     tags can be used to provide specific content preferences for a
     specific piece of content, and thus provide a flexible way to manage
     AI training signals at a more granular level.

  5.4.  “Well-Known” Locations

     According to [RFC8615], “well-known” locations can serve metadata or
     configuration information that is easily discoverable by automated
     clients.  AI-PREF preferences can be published at a “well-known” URL.
     There is already the Text and Data Mining Reservation Protocol
     (TDMRep (https://www.w3.org/community/reports/tdmrep/CG-FINAL-tdmrep-
     20240510/)) which has the same or overlapping intent.

     Example:

     https://example.com/.well-known/aipref

     At this URL, a JSON or other structured format can specify AI-PREF
     preferences for the entire domain or specific content types.

     Example JSON 1:

     {
       "allow_training": false,
       "purpose": ["generation"],
       "retention_period": "0"
     }

     Example JSON 2:




















  Vaughan                   Expires 24 July 2025                  [Page 7]


  Internet-Draft                AIPREF Vocab                  January 2025


     {
       "version": "1.0",
       "resources": [
         {
           "path": "/videos/tutorial.mp4",
           "type": "video/mp4",
           "components": [
             {
               "name": "Introduction",
               "time-range": "00:00:00-00:01:00",
               "preferences": {
                 "classification": "allowed",
                 "embedding": "allowed"
               }
             },
             {
               "name": "Main Content",
               "time-range": "00:01:01-00:05:00",
               "preferences": {
                 "generation": "prohibited",
                 "summarization": "allowed"
               }
             }
           ]
         }
       ]
     }

     This approach simplifies discovery for automated clients and provides
     a centralised way to communicate content preferences across a domain.

     TDMRep Example:

     A rightsholder could expose a “well-known” TDMRep file at:

     https://example.com/.well-known/tdmrep

     Example TDMRep JSON Content:













  Vaughan                   Expires 24 July 2025                  [Page 8]


  Internet-Draft                AIPREF Vocab                  January 2025


     {
       "version": "1.0",
       "license": "https://example.com/license",
       "contact": {
         "email": "tdm-support@example.com",
         "url": "https://example.com/contact"
       },
       "resources": [
         {
           "path": "/articles/",
           "type": "text/html",
           "restriction": "no-crawling"
         },
         {
           "path": "/api/data/",
           "type": "application/json",
           "restriction": "license-required"
         }
       ]
     }

  5.5.  Embedded Metadata

     Preferences for multimodal data can be embedded directly into file
     metadata (such as EXIF or XMP) as self-contained control signals.
     Compatibility and tamper resistance (e.g. signing) should be
     considered.

     Example EXIF:

     AI-Pref-Allow-Training: false
     AI-Pref-Purpose: embedding
     AI-Pref-Retention-Period: 0

     Example PDF Metadata Using XMP:

     <x:xmpmeta xmlns:x="adobe:ns:meta/">
        <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
           <rdf:Description rdf:about=""
              xmlns:dc="http://purl.org/dc/elements/1.1/">
              <dc:Rights>Text mining allowed; Data sharing restricted</dc:Rights>
           </rdf:Description>
        </rdf:RDF>
     </x:xmpmeta>

     Preferences can be applied at the file level, or even to specific
     components (e.g., chapters in a PDF or frames in a video).




  Vaughan                   Expires 24 July 2025                  [Page 9]


  Internet-Draft                AIPREF Vocab                  January 2025


     Example WEBVTT:

  WEBVTT

  00:00:00.000 --> 00:01:00.000
  Usage Preferences: allow_training=true; purpose=generation,classification

  00:01:01.000 --> 00:05:00.000
  Usage Preferences: allow_training=false;

  5.6.  Content Credentials (ISO 22144)

     TBD

  5.7.  ISCC (ISO 24138)

     TBD

  6.  Example Usage Scenarios

     TODO examples

  7.  Security Considerations

     This document does not affect the security of the Internet.  AI-PREF
     preferences do not include enforcement mechanisms, which should be
     addressed by AI model developers.  Publishers should be aware that
     preferences may not prevent unauthorised use and may rely on mutual
     agreements or legal protections.

  8.  IANA Considerations

     This document does not require any immediate IANA actions but may
     suggest future registry entries for the vocabulary terms to support
     interoperability.

  9.  References

  9.1.  Normative References

     [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
                Extensions (MIME) Part Two: Media Types", RFC 2046,
                DOI 10.17487/RFC2046, November 1996,
                <https://www.rfc-editor.org/rfc/rfc2046>.







  Vaughan                   Expires 24 July 2025                 [Page 10]


  Internet-Draft                AIPREF Vocab                  January 2025


     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
                (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
                <https://www.rfc-editor.org/rfc/rfc8615>.

     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

  9.2.  Informative References

     [PURPOSE]  Illyes, G., "Robots Exclusion Protocol User Agent Purpose
                Extension", Work in Progress, Internet-Draft, draft-
                illyes-rep-purpose-00, 18 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-illyes-rep-
                purpose-00>.

  Appendix A.  Table of Preference Signals

     This table defines terms and values that specify metadata preferences
     for the use of content in AI training.  Each term includes a
     description of its purpose and example values:

     +======================+===============+=================+==========================+
     |Term                  |Values         |Description      |Example                   |
     +======================+===============+=================+==========================+
     |allow_training        |Boolean        |Basic indicator  |allow_training: false     |
     |                      |               |of whether       |                          |
     |                      |               |content can be   |                          |
     |                      |               |used for AI      |                          |
     |                      |               |training         |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |purpose               |String:        |Defines          |purpose: classification,  |
     |                      |generation,    |acceptable       |summarisation             |
     |                      |classification,|applications for |                          |
     |                      |summarisation, |training e.g.    |                          |
     |                      |embedding, etc |fine-tuning,     |                          |
     |                      |               |classification,  |                          |
     |                      |               |summarisation,   |                          |



  Vaughan                   Expires 24 July 2025                 [Page 11]


  Internet-Draft                AIPREF Vocab                  January 2025


     |                      |               |etc              |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |effective_date        |Date string,   |Start date of    |effective_date:           |
     |                      |*ISO 8601*     |when permissions |2024-10-30T15:52:55.440238|
     |                      |               |take effect      |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |expiration_date       |Date string,   |Date after which |expiration_date:          |
     |                      |*ISO 8601*     |permissions no   |2024-10-30T15:52:55.440238|
     |                      |               |longer apply     |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |scope                 |String: global,|Defines whether  |scope: content-specific   |
     |                      |content-       |the preferences  |                          |
     |                      |specific,      |apply            |                          |
     |                      |conditional    |universally, to  |                          |
     |                      |               |specific content,|                          |
     |                      |               |or under certain |                          |
     |                      |               |conditions       |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |mime_type             |text, image,   |Specifies the    |mime_type: text, image    |
     |                      |video, audio   |type(s) of       |                          |
     |                      |               |content the      |                          |
     |                      |               |preference       |                          |
     |                      |               |applies to       |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |allow_derivatives     |Boolean        |Indicates whether|allow_derivatives: true   |
     |                      |               |derivative works |                          |
     |                      |               |(summaries,      |                          |
     |                      |               |paraphrasing) are|                          |
     |                      |               |allowed based on |                          |
     |                      |               |content          |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |derivative_type       |String:        |Lists permissible|derivative_type: summary, |
     |                      |summary,       |types is         |paraphrase                |
     |                      |paraphrase,    |allow_derivatives|                          |
     |                      |translation    |is true          |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |retention_period      |Duration       |Specifies how    |P3Y6M4DT12H30M5S          |
     |                      |string, *ISO   |long content may |representing three years, |
     |                      |8601*          |be retained after|six months, four days,    |
     |                      |               |use (e.g. after  |twelve hours, thirty      |
     |                      |               |training).       |minutes, and five seconds.|
     +----------------------+---------------+-----------------+--------------------------+
     |preference_persistence|Boolean        |Whether          |preference_persistence:   |
     |                      |               |preferences must |true                      |
     |                      |               |persist with     |                          |
     |                      |               |derived data,    |                          |
     |                      |               |boolean for      |                          |
     |                      |               |either required  |                          |



  Vaughan                   Expires 24 July 2025                 [Page 12]


  Internet-Draft                AIPREF Vocab                  January 2025


     |                      |               |or optional      |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |precedence            |String:high,   |Sets priority    |precedence: high          |
     |                      |medium, low    |when preferences |                          |
     |                      |               |conflict with    |                          |
     |                      |               |other layered    |                          |
     |                      |               |preferences      |                          |
     +----------------------+---------------+-----------------+--------------------------+
     |geo_limitations       |Location codes,|Specifies        |geo_limitations: EU, US   |
     |                      |*ISO 3166*     |geographic       |                          |
     |                      |               |regions where    |                          |
     |                      |               |training         |                          |
     |                      |               |permissions apply|                          |
     +----------------------+---------------+-----------------+--------------------------+

                                    Table 1

  Acknowledgments

     *  Greg Lindahl

     *  Sebastian Nagel

     *  Gary Illyes

     *  Mark Nottingham

     *  Suresh Krishnan

     *  Martin Thomson

     *  Paul Keller

     *  Leonard Rosenthol

     *  Special thanks to the program committee and contributing members
        of the IAB AI-CONTROL Workshop, and aipref Working Group.

  Author's Address

     Thom Vaughan
     Common Crawl Foundation
     Email: thom@commoncrawl.org








  Vaughan                   Expires 24 July 2025                 [Page 13]


name: draft-romm-aipref-contentsignals
rev: 00
title: Vocabulary For Expressing Content Signals
time: 2025-10-01T08:54:26Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-04T08:54:26Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:13.454059+00:00
abstract:
  This Internet Draft proposes three categories that would enable
     parties to express preferences regarding how digital assets are used
     by automated processing systems.  The proposal is for these
     categories to nest within the larger category of Automated
     Processing, currently envisaged in the [AIPREF-VOCAB].

full_text:
  AI Preferences                                               M. Tremante
  Internet-Draft                                                   L. Romm
  Intended status: Standards Track                              Cloudflare
  Expires: 4 April 2026                                     1 October 2025


                 Vocabulary For Expressing Content Signals
                    draft-romm-aipref-contentsignals-00

  Abstract

     This Internet Draft proposes three categories that would enable
     parties to express preferences regarding how digital assets are used
     by automated processing systems.  The proposal is for these
     categories to nest within the larger category of Automated
     Processing, currently envisaged in the [AIPREF-VOCAB].

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://l-
     romm.github.io/draft-romm-aipref-vocab-contentsignals/draft-romm-
     aipref-contentsignals.html.  Status information for this document may
     be found at https://datatracker.ietf.org/doc/draft-romm-aipref-
     contentsignals/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/l-romm/draft-romm-aipref-vocab-contentsignals.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.







  Tremante & Romm           Expires 4 April 2026                  [Page 1]


  Internet-Draft           AIPREF Content Signals             October 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 4 April 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Vocabulary Definition . . . . . . . . . . . . . . . . . . . .   3
       3.1.  Search  . . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.2.  AI Input  . . . . . . . . . . . . . . . . . . . . . . . .   3
       3.3.  AI Training . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Usage Category Labels . . . . . . . . . . . . . . . . . . . .   3
     5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
     6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
     7.  Addendum  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .   5
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

  1.  Introduction

     This proposal introduces and aims to define a specific set of
     preferences to address the need for expressing how digital assets can
     be used by automated systems, particularly in the context of training
     artificial intelligence (AI) models and generating search results.
     These preference categories enable clear and explicit communication
     of preferences regarding the use of digital assets for search
     indexing and AI training.



  Tremante & Romm           Expires 4 April 2026                  [Page 2]


  Internet-Draft           AIPREF Content Signals             October 2025


  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     For the purposes of this document, in addition to the definitions in
     Section 4 of [AIPREF-VOCAB], the following terms are used:

     *  *Search Results:* hyperlinks and short excerpts returned from
        contents of the retrieved asset(s)

     *  *Retrieval-Augmented Generation (RAG):* A technique where external
        content is retrieved at query time and supplied to a model to
        condition the generated output (B.  Silver)

  3.  Vocabulary Definition

  3.1.  Search

     The act of using one or more assets to build a search index and
     provide Search Results.  Search does not include providing AI-
     generated search summaries.  The use of assets for Search is a proper
     subset of Automated Processing usage.

  3.2.  AI Input

     The act of inputting an asset or assets into one or more AI models
     for purposes of retrieval-augmented generation, grounding, or other
     real-time taking of content for generative AI search answers.  The
     use of assets for AI Input is a proper subset of Automated Processing
     usage.

  3.3.  AI Training

     The act of training or fine-tuning AI models.  The use of assets for
     AI Training is a proper subset of Automated Processing usage.

  4.  Usage Category Labels

     Each usage category in Section 3 is mapped to a short textual label.
     Table 1 specifies this mapping.







  Tremante & Romm           Expires 4 April 2026                  [Page 3]


  Internet-Draft           AIPREF Content Signals             October 2025


                   +=============+==========+=============+
                   | Category    | Label    | Reference   |
                   +=============+==========+=============+
                   | Search      | search   | Section 3.1 |
                   +-------------+----------+-------------+
                   | AI Input    | ai-input | Section 3.2 |
                   +-------------+----------+-------------+
                   | AI Training | ai-train | Section 3.3 |
                   +-------------+----------+-------------+

                        Table 1: Usage category labels

  5.  Security Considerations

     TODO Security

  6.  IANA Considerations

     This document has no IANA actions.

  7.  Addendum

     The definition definition for Search (3.1) provided in this document
     may be replaced with the Search Category definition proposed in
     [AIPREF-VOCAB] and copied below:

     Using one or more assets in a search application that directs users
     to the location from which the assets were retrieved.  Search
     applications can be complex and may serve multiple purposes.  Only
     those parts of applications that direct users to the location of an
     asset are included in this category of use.  This includes the use of
     titles or excerpts from assets that are used to help users select
     between multiple candidate options.

     Preferences for the Search category apply to those parts of
     applications that provide search capabilities, regardless of what
     other preferences are stated.

     Parts of applications that do not direct users to the location of
     assets, such as summaries, are not covered by this category of use.

     The use of assets for Search is a proper subset of Automated
     Processing usage.

  8.  References

  8.1.  Normative References




  Tremante & Romm           Expires 4 April 2026                  [Page 4]


  Internet-Draft           AIPREF Content Signals             October 2025


     [ASCII]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [FIELDS]   Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  8.2.  Informative References

     [AIPREF-VOCAB]
                Keller, P. and M. Thomson, Ed., "A Vocabulary For
                Expressing AI Usage Preferences", Work in Progress,
                Internet-Draft, draft-ietf-aipref-vocab, October 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-aipref-
                vocab>.

     [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
                2003, <https://www.rfc-editor.org/rfc/rfc3629>.

  Appendix A.  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Michael Tremante
     Cloudflare
     Email: mst@cloudflare.com


     Leah Romm
     Cloudflare
     Email: lromm@cloudflare.com






  Tremante & Romm           Expires 4 April 2026                  [Page 5]


name: draft-keller-aipref-vocab
rev: 01
title: Proposal for an Opt-Out Vocabulary
time: 2025-04-10T14:46:31Z
group_uri: /api/v1/group/group/2440/
expires: 2025-10-01T09:12:25Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: ["Policy/governance", "Data formats/interop", "AI safety/alignment"]
tags: []
fetched_at: 2026-03-03T15:50:13.454064+00:00
abstract:
  This document proposes a standardized vocabulary of use cases that
     can be targeted when expressing machine-readable opt-outs related to
     Text and Data Mining (TDM) and AI training.  The vocabulary is
     agnostic to specific opt-out mechanisms and enables declaring parties
     to communicate restrictions or permissions regarding the use of their
     digital assets in a structured and interoperable manner.  It defines
     three key use cases—TDM, AI Training, and Generative AI
     Training—which can be referenced by opt-out systems to ensure
     consistent interpretation across different implementations.

full_text:
  AI Preferences                                                 P. Keller
  Internet-Draft                                               Open Future
  Intended status: Informational                             28 March 2025
  Expires: 29 September 2025


                     Proposal for an Opt-Out Vocabulary
                        draft-keller-aipref-vocab-01

  Abstract

     This document proposes a standardized vocabulary of use cases that
     can be targeted when expressing machine-readable opt-outs related to
     Text and Data Mining (TDM) and AI training.  The vocabulary is
     agnostic to specific opt-out mechanisms and enables declaring parties
     to communicate restrictions or permissions regarding the use of their
     digital assets in a structured and interoperable manner.  It defines
     three key use cases—TDM, AI Training, and Generative AI
     Training—which can be referenced by opt-out systems to ensure
     consistent interpretation across different implementations.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://paul2keller.github.io/opt-out-vocab-id/draft-keller-aipref-
     vocab.html.  Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-keller-aipref-vocab/.

     Discussion of this document takes place on the WG Working Group
     mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/paul2keller/opt-out-vocab-id.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.




  Keller                  Expires 29 September 2025               [Page 1]


  Internet-Draft                Opt-Out Vocab                   March 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 29 September 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   3
     4.  Vocabulary Structure  . . . . . . . . . . . . . . . . . . . .   3
     5.  Proposed Vocabulary . . . . . . . . . . . . . . . . . . . . .   4
       5.1.  Relationship with more specific instructions  . . . . . .   4
       5.2.  Relationship between categories . . . . . . . . . . . . .   4
     6.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
       9.2.  Informative References  . . . . . . . . . . . . . . . . .   6
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     The purpose of this document is to provide a common vocabulary that
     can be used for machine-readable opt-outs by parties who wish to
     restrict the use of their assets for the purpose of AI training and
     other forms of Text and Data Mining (TDM).






  Keller                  Expires 29 September 2025               [Page 2]


  Internet-Draft                Opt-Out Vocab                   March 2025


     The elements of the vocabulary can be used to describe, in a
     standardized way, the types of uses that a declaring party may wish
     to restrict (or allow), thereby ensuring that opt-outs can be
     communicated, processed and stored in a consistent and interoperable
     manner.

     The vocabulary is agnostic to the technical implementations of opt-
     out systems and is designed to ensure that opt-out information can be
     effectively exchanged between different systems.  The vocabulary is
     intended to govern the use of works in the context of training AI
     models and other forms of TDM but does not concern itself with the
     collection of training data (crawling).  In particular the vocabulary
     is not intended for expressing instructions or restrictions related
     to crawling for the purpose of building a search index, as there are
     already more specific standards and protocols for this purpose
     including but not limited to [RFC9309].

     The vocabulary is intended to both work in contexts where such opt-
     outs expressed to the declaring party give rise to legal obligation
     (such as rights reservation made by rightholders) and in contexts
     where this is not the case.  It is without prejudice to applicable
     laws and the applicability of exceptions and limitations.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  3.  Definitions

     *  *Asset:* A digital file or stream of data, usually with associated
        metadata.

     *  *Declaring party:* The entity that expresses an opt-out with
        regards to an Asset.

  4.  Vocabulary Structure

     The vocabulary consists of the overarching TDM (Text and Data Mining)
     category and a number of specific use cases that can be addressed
     independently.  The overarching category TDM is based on the
     definition of Text and Data Mining in Article 2(2) of [EUCD2019].






  Keller                  Expires 29 September 2025               [Page 3]


  Internet-Draft                Opt-Out Vocab                   March 2025


  5.  Proposed Vocabulary

     The following categories are defined for use in the opt-out
     vocabulary:

     *  *TDM* : Text and Data Mining.  The act of using one or more assets
        in the context of any automated analytical technique aimed at
        analyzing text and data in digital form in order to generate
        information which includes but is not limited to patterns, trends
        and correlations.

     *  *AI Training* : The act of training AI models

     *  *Generative AI Training* : The act of training General Purpose AI
        models that have the capacity to generate text, images or other
        forms of synthetic content, or the act of training other types of
        AI models that have the purpose of generating text, images or
        other forms of synthetic content.

     This list of specific use cases may be expanded in the future, should
     a consensus emerge between stakeholders, to include categories that
     address additional use cases as they emerge.  In addition to these
     categories defined in the vocabulary, it is also expected that some
     systems implementing this vocabulary may extend this list with
     additional categories for their particular needs.

  5.1.  Relationship with more specific instructions

     The vocabulary does not preclude the use of other specific
     categories.  Any opt-outs based on this vocabulary shall not be
     interpreted as restricting the use of the work(s) strictly for the
     purpose of search and discovery as long as no restriction is declared
     through search-specific means such as [RFC9309].

     When using this vocabulary more specific instructions — either based
     on the vocabulary or derived from other protocols — should be given
     preference over less specific ones.

  5.2.  Relationship between categories

     The TDM category is the overarching category that includes the AI
     training category.  Generative AI training is a subset of the AI
     training category.  Both AI training and generative AI training are
     considered to be forms of TDM.  As such, when a Declaring Party opts
     out of TDM, they also opt out of these categories.  AI model
     developers processing opt-outs must therefore interpret an opt-out
     from TDM to also mean an opt-out from Generative AI Training and AI
     Training.



  Keller                  Expires 29 September 2025               [Page 4]


  Internet-Draft                Opt-Out Vocab                   March 2025


     The figure below shows the relationship between the currently defined
     categories:

  +--------------------------------------------------------------------------+
  |                                                                          |
  |                          Text and Data Mining (TDM)                      |
  |                                                                          |
  | +--------------------------------------------+  +- - - - - - - - - - -+  |
  | |  +--------------------------+              |  |                     |  |
  | |  |                          |              |                           |
  | |  |                          |              |  |    [possibly]:      |  |
  | |  | Generative AI Training   |  AI Training |                           |
  | |  |                          |              |  |  Other use cases    |  |
  | |  |                          |              |                           |
  | |  +--------------------------+              |  |                     |  |
  | +--------------------------------------------+  +- - - - - - - - - - -+  |
  |                                                                          |
  +--------------------------------------------------------------------------+

                Figure 1: Overview of proposed vocabulary

     Systems referencing the vocabulary must not introduce additional
     categories that include existing categories defined in the vocabulary
     or otherwise include additional hierarchical relationships.

  6.  Usage

     The vocabulary may be used by declaring that an opt-out system or
     entity expressing or processing opt-outs uses the terms defined in
     the "Proposed Vocabulary" section above, directly or via mappings, in
     accordance with how they are defined in this document.

  7.  Security Considerations

     TODO Security

  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

  9.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.



  Keller                  Expires 29 September 2025               [Page 5]


  Internet-Draft                Opt-Out Vocab                   March 2025


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

  9.2.  Informative References

     [EUCD2019] European Union, "Directive (EU) 2019/790 of the European
                Parliament and of the Council of 17 April 2019 on
                copyright and related rights in the Digital Single
                Market", 17 May 2019,
                <https://eur-lex.europa.eu/eli/dir/2019/790/oj>.

  Acknowledgments

     The following individuals have been involved in the drafting of the
     proposal:

     *  Cullen Miller, Spawing.ai

     *  Sebastian Posth, Liccium

     *  Leonard Rosenthol, Adobe

     *  Laurent Le Meur, EDRLab

  Author's Address

     Paul Keller
     Open Future
     Email: paul@openfuture.eu
















  Keller                  Expires 29 September 2025               [Page 6]


name: draft-liao-aipref-autoctl-ext
rev: 01
title: Protocol Extension for Automation Control
time: 2025-11-03T07:09:20Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-24T05:25:29Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Policy/governance", "A2A protocols"]
tags: []
fetched_at: 2026-03-03T15:50:13.454067+00:00
abstract:
  This document specifies extensions to [CORE-SPEC], providing a wider
     range of controls for server-side automation permissions.  It
     supports rate limiting, automation technology restrictions, API
     permissions, session requirements, and HTML asset annotations.  These
     extensions enable service owners to exercise more granular control
     over automated interactions.

full_text:
  AI Preferences                                                L. Peiyuan
  Internet-Draft                                                Condé Nast
  Intended status: Experimental                              20 April 2025
  Expires: 22 October 2025


                 Protocol Extension for Automation Control
                      draft-liao-aipref-autoctl-ext-01

  Abstract

     This document specifies extensions to [CORE-SPEC], providing a wider
     range of controls for server-side automation permissions.  It
     supports rate limiting, automation technology restrictions, API
     permissions, session requirements, and HTML asset annotations.  These
     extensions enable service owners to exercise more granular control
     over automated interactions.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://datatracker.ietf.org/doc/draft-liao-aipref-autoctl-ext/.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-liao-aipref-autoctl-ext/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 22 October 2025.



  Peiyuan                  Expires 22 October 2025                [Page 1]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Relationship to Core Specification  . . . . . . . . . . .   3
     2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
     3.  Extended Protocol Specification . . . . . . . . . . . . . . .   4
       3.1.  Rate Limiting . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Automation Technology Restrictions  . . . . . . . . . . .   4
         3.2.1.  Protocol Tokens . . . . . . . . . . . . . . . . . . .   5
         3.2.2.  Runtime Tokens  . . . . . . . . . . . . . . . . . . .   6
       3.3.  API and XHR Permissions . . . . . . . . . . . . . . . . .   6
       3.4.  Session Requirements  . . . . . . . . . . . . . . . . . .   7
       3.5.  HTML Asset Annotation . . . . . . . . . . . . . . . . . .   8
     4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   9
     5.  Backward Compatibility  . . . . . . . . . . . . . . . . . . .  11
     6.  Implementation and Enforcement  . . . . . . . . . . . . . . .  12
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
     Sample Extended automation-preferences.txt File . . . . . . . . .  14
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

  1.  Introduction

     Often, the behaviors of automated systems may exhibit a certain
     pattern that is hard to characterize with only the HTTP method and
     user-agent used by [CORE-SPEC].  This document introduces a set of
     extensions for service owners to specify more complex and granular
     automation policies involving rate limiting, particularly prevalent
     automation technologies, API permissions, session requirements, and
     annotations on HTML assets.




  Peiyuan                  Expires 22 October 2025                [Page 2]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  1.1.  Relationship to Core Specification

     All directives and mechanisms defined in the core specification
     remain valid and are not redefined here.  This document assumes
     familiarity with [CORE-SPEC] and uses its terminology and concepts
     throughout.

     The extensions defined in this document are OPTIONAL for both servers
     and clients.  Implementations that support only the core
     specification are considered compliant with the automation-
     preferences.txt protocol, though they will not benefit from the
     granular controls defined here.

     When both core and extended directives are present in an automation-
     preferences.txt file, parsers that do not support the extensions
     defined in this document MUST ignore the unrecognized directives, as
     specified in the core specification's extension-mechanism.

  2.  Conventions and Terminology

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     This document uses the terminology defined in [CORE-SPEC].  The
     following additional terms are introduced:

     *  Rate limiting: Constraints on the frequency or concurrency of
        automated requests.

     *  Automation technology: Specific tools or frameworks used for
        automation, such as headless browsers or browser automation
        protocols.

     *  XHR/Fetch: XMLHttpRequest or Fetch API calls performed
        programmatically.

     *  Session validation: Mechanisms to verify that automated requests
        are part of a legitimate user session.

     *  Asset annotation: Metadata embedded within HTML documents to
        specify automation policies for individual content elements.







  Peiyuan                  Expires 22 October 2025                [Page 3]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  3.  Extended Protocol Specification

     This section defines additional directives that extend the
     automation-preferences.txt protocol.  These directives may be used
     alongside the core directives in any group within the automation-
     preferences.txt file.

     Unless stated otherwise, the empty form of any comma-separated list
     means "explicitly none", distinct from omitting the directive.

  3.1.  Rate Limiting

     The following directives are defined:

     *  request-limit: Specifies the maximum number of requests allowed
        within a time period, expressed as a count followed by a time unit
        (e.g., "60/minute").  Supported time units are "second", "minute",
        "hour", and "day".

     *  concurrent-limit: Specifies the maximum number of concurrent
        connections allowed from a single client.

     Example:

     request-limit: 60/minute
     concurrent-limit: 5

                                    Figure 1

     Rate limiting directives apply to all requests within the scope of
     the group, regardless of HTTP method.  If no rate limiting directives
     are specified, clients SHOULD NOT assume any specific rate limits.

  3.2.  Automation Technology Restrictions

     Automation technology directives specify whether particular
     automation capabilities are permitted.  Automation mechanisms fall
     into two orthogonal layers: _protocol_ (the wire format exchanged
     with the browser) and _runtime_ (whether the browser runs headless or
     headed).  Tokens defined in Section 3.2.1 and Section 3.2.2 MAY be
     mixed in any order.

     The following directive is defined:








  Peiyuan                  Expires 22 October 2025                [Page 4]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     *  allowed-automations: A comma-separated list of tokens representing
        permitted automation mechanisms.  If this directive is present but
        empty, it implies that no standard tokens are explicitly
        permitted.  If the directive is absent, clients SHOULD NOT assume
        any mechanism is allowed.

     Default behavior: when the allowed-automations directive is:

     present and empty  no standard tokens are permitted;

     absent  the server makes no statement, and clients SHOULD assume the
        most restrictive stance (i.e., that no automation mechanism is
        authorised).

     This aligns the silent default with that of api-automation, allow-
     xhr, and disallow-fetch-from, ensuring a single, predictable "fail-
     closed" rule across all extension directives.

     A list-valued directive that appears as name: followed only by
     whitespace or a comment MUST be parsed as an empty list, not a syntax
     error.  This applies to allowed-automations and all other comma-
     separated lists in the core or extension specs.

     Example (allowing WebDriver traffic in headless mode):

     allowed-automations: webdriver, headless

                                    Figure 2

     If a token is not listed in a present allowed-automations directive,
     clients SHOULD assume that the use of that mechanism is not permitted
     within the specified scope.  Implementations SHOULD respect these
     directives when applicable, even though detection techniques may
     differ.

     The directive accepts any string token, but the following identifiers
     are suggested for interoperability.

     This list is not exhaustive.  Future specifications MAY define
     additional standard tokens.

  3.2.1.  Protocol Tokens

     *  webdriver: Automation using the W3C WebDriver wire protocol
        [WEBDRIVER].

     *  cdp: Automation using the Chrome DevTools Protocol [CDP].




  Peiyuan                  Expires 22 October 2025                [Page 5]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     *  webkit-remote: Automation using the WebKit Remote Debugging
        Protocol [WKREMOTE].

     *  firefox-remote: Automation using the Firefox Remote Debug Protocol
        via GeckoDriver [FFREMOTE].

  3.2.2.  Runtime Tokens

     *  headless: Browser runs with no visible UI [HEADLESS].

     *  headed: Browser UI is presented to the user.

  3.3.  API and XHR Permissions

     API and XHR permission directives specify rules for API usage and
     automated use of XMLHttpRequest, Fetch, or AJAX.  The following
     directives are defined:

     *  api-automation: Indicates how API endpoints may be accessed by
        automated clients.  Valid values are:

        -  _none_: No API automation is permitted.

        -  _with-key-only_: API automation is permitted only with proper
           authentication.

        -  _open_: API automation is generally permitted.

     *  allow-xhr: Indicates how XMLHttpRequest or Fetch API may be used
        by automated clients.  Valid values are:

        -  _none_: No XHR/Fetch automation is permitted.

        -  _read-only_: Only GET requests are permitted via XHR/Fetch.

        -  _open_: XHR/Fetch automation is generally permitted.

     *  disallow-fetch-from: Comma-separated list of URL patterns from
        which automated XHR/Fetch requests are prohibited.  Wildcards MAY
        be used.

     Example:

     api-automation: with-key-only
     allow-xhr: read-only
     disallow-fetch-from: /account/*, /checkout/*, /admin/*

                                    Figure 3



  Peiyuan                  Expires 22 October 2025                [Page 6]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     If API and XHR permission directives are not specified, clients
     SHOULD assume the most restrictive value (i.e., "none" for api-
     automation and allow-xhr).

  3.4.  Session Requirements

     Session requirement directives specify whether automated requests
     must be part of a legitimate user session.  The following directives
     are defined:

     *  require-human-initiated-session: Boolean value indicating whether
        automated requests must be part of a session that was initiated by
        a human user.

     *  session-validation: Specifies the method used to validate
        sessions.  Valid values are:

        -  _cookie-based_: Sessions are validated using HTTP cookies.

        -  _token-based_: Sessions are validated using authentication
           tokens.

        -  _oauth_: Sessions are validated using OAuth.

        -  _none_: No session validation is required.

     *  session-ttl: Specifies the maximum time-to-live for a session,
        expressed as a duration (e.g., "30m", "2h", "1d").

        A duration literal consists of a sequence of decimal digits
        immediately followed by a single unit character.  Units are mapped
        as follows:

        -  s - seconds (1 <= value <= 86400)

        -  m - minutes (1 <= value <= 1440)

        -  h - hours (1 <= value <= 168)

        -  d - days (1 <= value <= 365)

        Implementations MUST reject values outside these ranges with a
        client or server error appropriate to their role.

     Example:






  Peiyuan                  Expires 22 October 2025                [Page 7]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     require-human-initiated-session: true
     session-validation: cookie-based
     session-ttl: 1h

                                    Figure 4

     If session requirement directives are not specified, clients SHOULD
     NOT assume any specific session requirements, but SHOULD include a
     valid User-Agent header in all requests.

  3.5.  HTML Asset Annotation

     Automation preferences MAY be embedded directly within HTML documents
     to annotate individual assets.  Authors SHOULD use structured data
     markup using JSON-LD [JSON-LD11] embedded in a <script> element.  The
     JSON object SHOULD use a defined type and include relevant fields
     that mirror those used in automation-preferences.txt.

     Note that unlike site-wide directives, asset-level annotations SHOULD
     NOT include HTTP method restrictions, request limits, or concurrency
     limits, as these concepts apply to endpoints and services rather than
     to individual content assets.

     Example:

     <script type="application/ld+json">
     {
       "@context": "https://schema.org",
       "@type": "AutomationPolicyAnnotation",
       "allowedAutomations": [],
       "allowedPurposes": [],
     }
     </script>

                                    Figure 5

     When both an automation-preferences.txt file and HTML asset
     annotations are present, the more specific rule (typically the HTML
     annotation) SHALL be applied to the corresponding content asset.
     Clients supporting HTML asset annotations SHOULD parse and respect
     these annotations when present.

     The annotation schema MAY include any directives defined in the core
     or extension specifications.  Fields in the annotation SHOULD use
     camelCase naming to align with JSON-LD conventions (e.g.,
     allowedAutomations for allowed-automations, requestLimit for request-
     limit), while maintaining semantic equivalence to the corresponding
     directives in the automation-preferences.txt file.



  Peiyuan                  Expires 22 October 2025                [Page 8]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  4.  Formal Syntax

     Below is an Augmented Backus-Naur Form (ABNF) description,
     incorporating the extensions defined in this document.  It extends
     the grammar defined in the core specification Part formal-syntax of
     [CORE-SPEC].

     Rules inherited or unmodified from the core specification are
     included for completeness.  Rules added or modified by this extension
     are indicated with comments (`; Extension directive` or `; Extended
     rule`).

     automation-preferences = *( group )

     group            = 1*scope-directive           ; at least one <scope>
                        *( directive / emptyline )
                        1*emptyline                 ; blank line terminates group

     directive        = scope-directive / host-directive /
                        user-agent-directive /
                        method-directive / purpose-directive /
                        ; Extended rule: Added extension directives
                        request-limit-directive / concurrent-limit-directive /
                        allowed-automations-directive / api-automation-directive /
                        allow-xhr-directive / disallow-fetch-from-directive /
                        require-human-session-directive / session-validation-directive /
                        session-ttl-directive

     ; --- Core directives (from CORE-SPEC) ---------------------

     scope-directive   = *WS "scope"            *WS ":" *WS url-pattern    EOL
     host-directive    = *WS "host"             *WS ":" *WS host-pattern   EOL
     method-directive  = *WS "allowed-methods"  *WS ":" *WS method-list    EOL
     purpose-directive = *WS "allowed-purposes" *WS ":" *WS purpose-list   EOL
     user-agent-directive  = *WS "user-agent" *WS ":" *WS product-token
                             *( *WS "," *WS product-token ) EOL

     ; --- Extension directives ---------------------------------

     request-limit-directive = *WS "request-limit"  *WS ":" *WS rate-spec EOL
     concurrent-limit-directive = *WS "concurrent-limit" *WS ":" *WS count EOL
     allowed-automations-directive = *WS "allowed-automations" *WS ":" *WS automation-list EOL
     api-automation-directive = *WS "api-automation" *WS ":" *WS api-automation-value EOL
     allow-xhr-directive = *WS "allow-xhr" *WS ":" *WS allow-xhr-value EOL
     disallow-fetch-from-directive = *WS "disallow-fetch-from" *WS ":" *WS url-pattern-list EOL
     require-human-session-directive = *WS "require-human-initiated-session" *WS ":" *WS boolean EOL
     session-validation-directive = *WS "session-validation" *WS ":" *WS session-validation-value EOL
     session-ttl-directive = *WS "session-ttl" *WS ":" *WS duration EOL



  Peiyuan                  Expires 22 October 2025                [Page 9]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     ; --- Directive value syntax (Core) ------------------------

     url-pattern     = 1*( VCHAR / UTF8-char-noctl )
     host-pattern    = 1*( ALPHA / DIGIT / "-" / "." / UTF8-char-noctl )
     method-list     = method *( *WS "," *WS method )
     method          = "GET" / "HEAD" / "POST" / "PUT" /
                       "DELETE" / "PATCH" / "OPTIONS" /
                       "TRACE" / "CONNECT"
     purpose-list    = purpose-token *( *WS "," *WS purpose-token )
     purpose-token   = 1*VCHAR   ; placeholder for future vocabulary
     product-token   = identifier / "*"
     identifier      = 1*( %x2D / %x41-5A / %x5F / %x61-7A )

     ; --- Directive value syntax (Extension) -------------------

     rate-spec       = count "/" time-unit
     count           = 1*DIGIT
     time-unit       = "second" / "minute" / "hour" / "day"

     automation-list = *( automation-token *( *WS "," *WS automation-token ) )
     automation-token= 1*VCHAR ; e.g., "cdp", "headless", "selenium"

     api-automation-value = "none" / "with-key-only" / "open"

     allow-xhr-value = "none" / "read-only" / "open"

     url-pattern-list= url-pattern *( *WS "," *WS url-pattern )

     boolean         = "true" / "false"

     session-validation-value = "cookie-based" / "token-based" / "oauth" / "none"

     duration        = 1*DIGIT time-unit-char
     time-unit-char  = "s" / "m" / "h" / "d"  ; s=second, m=minute,
                                              ; h=hour, d=day

     ; --- Lexical primitives (from CORE-SPEC) ------------------

     comment         = "#" *( UTF8-char-noctl / WS / "#" )

     emptyline       = *WS [comment] EOL
     EOL             = *WS [comment] NL
     NL              = CRLF / LF / CR
     CRLF            = CR LF
     CR              = %x0D
     LF              = %x0A
     WS              = SP / HTAB
     SP              = %x20



  Peiyuan                  Expires 22 October 2025               [Page 10]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     HTAB            = %x09

     ; --- Core ABNF terminals (RFC 5234) -----------------------

     ALPHA           = %x41-5A / %x61-7A
     DIGIT           = %x30-39
     VCHAR           = %x21-7E

     ; --- UTF-8 (derived from RFC 3629) ------------------------

     UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
     UTF8-1-noctl    = %x21 / %x22 / %x24-7F
     UTF8-2          = %xC2-DF UTF8-tail
     UTF8-3          = %xE0 %xA0-BF UTF8-tail
                     / %xE1-EC UTF8-tail-2
                     / %xED %x80-9F UTF8-tail
                     / %xEE-EF UTF8-tail-2
     UTF8-4          = %xF0 %x90-BF UTF8-tail-2
                     / %xF1-F3 UTF8-tail-3
                     / %xF4 %x80-8F UTF8-tail-2
     UTF8-tail       = %x80-BF
     UTF8-tail-2     = UTF8-tail UTF8-tail
     UTF8-tail-3     = UTF8-tail UTF8-tail UTF8-tail

  5.  Backward Compatibility

     All directives defined in this document are OPTIONAL.
     Implementations that support only the core specification can safely
     ignore these directives.

     Implementations supporting these extensions SHOULD degrade gracefully
     when interacting with servers or clients that support only the core
     specification.

     *  Servers supporting extensions SHOULD still process all core
        directives correctly, even if extended directives are also
        present.

     *  Clients supporting extensions SHOULD still honor all core
        directives, even if they do not recognize extended directives in a
        file.

     *  When HTML asset annotations are not supported by a client, the
        client SHOULD fall back to the site-level automation-
        preferences.txt file for guidance.






  Peiyuan                  Expires 22 October 2025               [Page 11]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  6.  Implementation and Enforcement

     Servers implementing the extensions defined in this document SHOULD:

     *  Employ detection mechanisms (e.g., CDP fingerprinting, headless
        browser detection) to identify automated clients using specific
        technologies.

     *  Implement rate limiting according to the specified directives.

     *  Validate sessions as required by the session requirement
        directives.

     *  Process HTML asset annotations when interpreting automation
        policies for specific content.

     *  Respond with appropriate HTTP status codes [RFC9110] for non-
        compliant requests, such as:

        -  429 Too Many Requests for rate limit violations.

        -  403 Forbidden for unauthorized automation technology use.

        -  401 Unauthorized for missing or invalid authentication.

     Clients supporting these extensions SHOULD:

     *  Honor rate limiting directives by self-throttling requests.

     *  Respect automation technology restrictions by only using tools
        listed in the allowed-automations directive, if present.

     *  Adhere to API and XHR permissions as specified (api-automation,
        allow-xhr, disallow-fetch-from).

     *  Establish and maintain valid sessions when required (require-
        human-initiated-session, session-validation, session-ttl).

     *  Parse and respect HTML asset annotations when present.

     Both servers and clients MAY implement additional detection and
     enforcement mechanisms beyond those explicitly described in this
     document, as long as they maintain compatibility with the specified
     directives.







  Peiyuan                  Expires 22 October 2025               [Page 12]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  7.  Security Considerations

     In addition to the security considerations mentioned in [CORE-SPEC],
     the extensions defined in this document introduce the following
     considerations:

     *  Rate Limiting: Implementations of rate limiting SHOULD use secure
        methods to track request counts and prevent circumvention through
        IP spoofing or other means.

     *  Technology Detection: Methods used to detect specific automation
        technologies can be circumvented by sophisticated clients.
        Servers SHOULD employ multiple detection approaches and adapt to
        evolving evasion techniques.

     *  Session Validation: Session validation mechanisms SHOULD be
        resistant to replay attacks and session hijacking attempts.

     *  HTML Asset Annotations: Parsing of JSON-LD annotations MUST be
        performed securely to prevent injection attacks or denial-of-
        service through malformed input.

  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

  9.1.  Normative References

     [CORE-SPEC]
                Liao, P., "Protocol for Automation Control", Work in
                Progress, Internet-Draft, draft-liao-aipref-autoctl-core-
                01, April 2025, <https://datatracker.ietf.org/doc/html/
                draft-liao-aipref-autoctl-core-01>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  9.2.  Informative References





  Peiyuan                  Expires 22 October 2025               [Page 13]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     [CDP]      Google, "Chrome DevTools Protocol", 2025,
                <https://chromedevtools.github.io/devtools-protocol/>.

     [FFREMOTE] Mozilla, "GeckoDriver Remote Protocol", 2025,
                <https://firefox-source-
                docs.mozilla.org/testing/geckodriver/index.html>.

     [HEADLESS] Google, "Chrome Headless Mode", 2024,
                <https://developer.chrome.com/docs/chromium/headless>.

     [JSON-LD11]
                Kellogg, G., Champin, P.-A., and D. Longley, "JSON-LD
                1.1", W3C Recommendation REC-json-ld11-20200716, 16 July
                2020, <https://www.w3.org/TR/json-ld11/>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/info/rfc9110>.

     [WEBDRIVER]
                W3C, "WebDriver", 2018,
                <https://www.w3.org/TR/webdriver/>.

     [WKREMOTE] WebKit Project, "WebKit Remote Debugging Protocol", 2015,
                <https://webkit.org/debugging-webkit/>.

  Sample Extended automation-preferences.txt File

     The following is an example of an automation-preferences.txt file
     that includes both core and extended directives:




















  Peiyuan                  Expires 22 October 2025               [Page 14]


  Internet-Draft             aipref-autoctl-ext                 April 2025


  <!-- Automation preferences for example.com -->
  <!-- Version: 2.0 (incorporating extensions) -->
  <!-- Last updated: 2025-04-20 -->

  <!-- Group 1: Applies to the entire site for all user agents -->
  user-agent: *
  host: example.com
  scope: /
  allowed-methods: GET, HEAD
  allowed-purposes: PLACEHOLDER_PURPOSE1, PLACEHOLDER_PURPOSE2

  <!-- Extended directives for Group 1 -->
  request-limit: 60/minute
  concurrent-limit: 5
  <!-- Empty - forbids all automation technologies -->
  allowed-automations:
  api-automation: with-key-only
  require-human-initiated-session: true
  session-validation: cookie-based
  session-ttl: 1h


  <!-- Group 2: Specific preferences for the /admin/ path for ExampleBot -->
  user-agent: ExampleBot
  host: example.com
  scope: /admin/
  allowed-methods: GET
  allowed-purposes: PLACEHOLDER_PURPOSE1

  <!-- Extended directives for admin path (Group 2) -->
  request-limit: 10/minute
  concurrent-limit: 2
  require-human-initiated-session: true
  session-validation: token-based
  session-ttl: 30m


  <!-- Group 3: Default for /admin/ for other user agents (less specific than Group 2) -->
  user-agent: *
  host: example.com
  scope: /admin/
  allowed-methods: GET

                                 Figure 6

  Author's Address





  Peiyuan                  Expires 22 October 2025               [Page 15]


  Internet-Draft             aipref-autoctl-ext                 April 2025


     Liao Peiyuan
     Condé Nast
     United States of America
     Email: peiyuan_liao@condenast.com















































  Peiyuan                  Expires 22 October 2025               [Page 16]


name: draft-liao-aipref-autoctl-core
rev: 01
title: Protocol for Automation Control
time: 2025-11-03T07:09:20Z
group_uri: /api/v1/group/group/1027/
expires: 2025-10-23T07:36:36Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "ML traffic mgmt", "Policy/governance"]
tags: []
fetched_at: 2026-03-03T15:50:13.454070+00:00
abstract:
  This document specifies a machine-readable protocol for server-side
     automation permissions in the light of recent advances in AI-driven
     web automation.  Building upon RFC9309, this protocol addresses a
     broader range of state-changing activities that service owners may
     wish to control.  It defines the file format, HTTP method
     restrictions, and purpose requirements.

full_text:
  AI Preferences                                                L. Peiyuan
  Internet-Draft                                                Condé Nast
  Intended status: Experimental                              20 April 2025
  Expires: 22 October 2025


                      Protocol for Automation Control
                     draft-liao-aipref-autoctl-core-01

  Abstract

     This document specifies a machine-readable protocol for server-side
     automation permissions in the light of recent advances in AI-driven
     web automation.  Building upon RFC9309, this protocol addresses a
     broader range of state-changing activities that service owners may
     wish to control.  It defines the file format, HTTP method
     restrictions, and purpose requirements.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://datatracker.ietf.org/doc/draft-liao-aipref-autoctl-core/.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-liao-aipref-autoctl-core/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 22 October 2025.



  Peiyuan                  Expires 22 October 2025                [Page 1]


  Internet-Draft               aipref-autoctl                   April 2025


  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Relationship to Extension Specification . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   4
       3.1.  File Location and Format  . . . . . . . . . . . . . . . .   4
       3.2.  HTTP Method Restrictions  . . . . . . . . . . . . . . . .   4
       3.3.  Purpose Declaration . . . . . . . . . . . . . . . . . . .   4
       3.4.  Scope and Applicability . . . . . . . . . . . . . . . . .   5
     4.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Extension Mechanism . . . . . . . . . . . . . . . . . . . . .   8
     6.  Implementation and Enforcement  . . . . . . . . . . . . . . .   8
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Sample automation-preferences.txt File  . . . . . . . . . . . . .  10
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

  1.  Introduction

     The evolution of web automation has outpaced the capabilities of
     existing standards that only provide for read-only crawler
     permissions.  Sophisticated, AI-driven bots are now able to interact
     with web servers in a complex, human-like manner, allowing them to
     deeply acquire and modify content.  This document introduces a
     protocol that enables service owners to declare policies governing
     such interactions, notably state-changing HTTP methods.






  Peiyuan                  Expires 22 October 2025                [Page 2]


  Internet-Draft               aipref-autoctl                   April 2025


  1.1.  Applicability

     The automation-preferences.txt _file_ applies to automated systems
     interacting with web servers, especially those driven by AI models.
     Content owners may use this file to specify acceptable automation
     behaviors, and developers of automated systems may use these
     directives to ensure compliance.

  1.2.  Relationship to Extension Specification

     A separate document, "Protocol Extension for Automation Control,"
     extends this document with additional directives and capabilities,
     focusing on a wider range of state-changing web requests.

     Implementations conforming to only this specification are considered
     compliant with the protocol.

     This protocol _augments_, and does not relax, the directives of
     [RFC9309].  If a path is disallowed in robots.txt, an automation-
     preferences.txt directive MUST NOT be interpreted to expand access.
     Conversely, when robots.txt explicitly allows any HTTP method on a
     path, an automation-preferences.txt directive that disallows state-
     changing requests to that same path SHALL take precedence; the more
     restrictive rule MUST be enforced.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     The following terms are used in this document:

     *  Automation: Programmatic interactions with a web server.

     *  State-changing requests: HTTP methods that alter server state
        (e.g., POST, PUT, DELETE, PATCH).

     *  Automation purpose: The declared intent or use case for which
        automation is being performed.

     All terminology defined in this core specification applies to the
     extension specification without redefinition.  The extension
     specification may introduce additional terms for concepts not covered
     in this document.




  Peiyuan                  Expires 22 October 2025                [Page 3]


  Internet-Draft               aipref-autoctl                   April 2025


  3.  Protocol Specification

  3.1.  File Location and Format

     The automation-preferences.txt file MUST be hosted at the root of the
     domain, in the same manner as [RFC9309].  The file is structured as a
     series of key-value pairs that specify automation permissions.

     The file MUST be served with the media type text/plain; charset=utf-
     8.  Lines beginning with the hash symbol (#) are considered comments
     and MUST be ignored by parsers.  Each directive consists of a field
     name, followed by a colon, followed by a value.  Multiple values MAY
     be separated by commas.  Parsers MUST silently ignore any directives
     they do not recognize.

     Implementations SHOULD reject files that contain raw control bytes
     (code points < U+0020) other than the permitted CR (U+000D) and LF
     (U+000A) line breaks.

  3.2.  HTTP Method Restrictions

     The protocol MUST explicitly list allowed HTTP methods using the
     allowed-methods directive.  Typically, GET and HEAD are permitted
     while methods such as POST, PUT, DELETE, and PATCH are disallowed for
     automated processing.  Methods that are not listed are assumed to be
     disallowed.

     Example:

     allowed-methods: GET, HEAD
     <!-- Note: This example shows basic method allowance -->

                                    Figure 1

     If a group omits the allowed-methods directive, _all_ HTTP methods
     are considered disallowed for automated processing within that scope.

  3.3.  Purpose Declaration

     The protocol allows server owners to accept or reject user agents
     with specific purposes with the allowed-purposes directive, which
     accepts a comma-separated list of permitted purposes using
     standardized vocabulary terms.

     The specific vocabulary terms for automation purposes are not defined
     in this document.  Instead, this protocol provides a mechanism for
     expressing allowed and disallowed purposes, which can be compatible
     with an accepted vocabulary standard in the future.



  Peiyuan                  Expires 22 October 2025                [Page 4]


  Internet-Draft               aipref-autoctl                   April 2025


     Example:

     allowed-purposes: PLACEHOLDER_PURPOSE1, PLACEHOLDER_PURPOSE2
     <!-- Note: Placeholder purposes are used here -->

                                    Figure 2

  3.4.  Scope and Applicability

     The automation-preferences.txt file is divided into groups, each of
     which applies to a specific subset of content.  Each group begins
     with one or more scope directives that define the target of the
     preferences.  The following directives MAY be used within a group:

     *  scope: Specifies the URL pattern (e.g., /admin/) to which the
        group applies.  Wildcards MAY be used to indicate variable
        components of the URL.

     *  host: Specifies a subdomain or host.  If present, the group
        applies only to the indicated subdomain; if omitted, the group is
        assumed to apply to the entire host.

     *  user-agent: Specifies one or more automation user-agent tokens to
        which the group applies.  If omitted, the group applies to all
        user agents.

     Groups are processed in order of specificity.  Specificity is
     determined by (1) an _exact host match_ over a wildcard or absent
     host; (2) the _longest matching scope directive_; (3) the _most
     specific user-agent token_ (an exact token outranks the wildcard *);
     then (4) appearance order, where the group appearing later in the
     file SHALL take precedence when all preceding criteria are equal.

     A group MUST contain at least one scope directive and MAY omit all
     other directives.

     Example:














  Peiyuan                  Expires 22 October 2025                [Page 5]


  Internet-Draft               aipref-autoctl                   April 2025


     <!-- Group 1: Applies to the entire site -->
     user-agent: *
     host: example.com
     scope: /
     allowed-methods: GET, HEAD

     <!-- Group 2: Specific preferences for the /admin/ path -->
     user-agent: *
     host: example.com
     scope: /admin/
     allowed-methods: GET

                                    Figure 3

  4.  Formal Syntax

     Below is an Augmented Backus-Naur Form (ABNF) description, as defined
     in [RFC5234], with references to [RFC3629], [RFC3986], and [RFC9309].

     automation-preferences = *( group )

     group            = 1*scope-directive           ; at least one <scope>
                        *( directive / emptyline )
                        1*emptyline                 ; blank line terminates group

     directive        = scope-directive / host-directive /
                        user-agent-directive /
                        method-directive / purpose-directive

     ; --- individual directives ----------------------------------

     scope-directive   = *WS "scope"            *WS ":" *WS url-pattern    EOL
     host-directive    = *WS "host"             *WS ":" *WS host-pattern   EOL
     method-directive  = *WS "allowed-methods"  *WS ":" *WS method-list    EOL
     purpose-directive = *WS "allowed-purposes" *WS ":" *WS purpose-list   EOL
     user-agent-directive  = *WS "user-agent" *WS ":" *WS product-token
                             *( *WS "," *WS product-token ) EOL

     ; --- directive value syntax ---------------------------------

     ; url-pattern: visible ASCII or UTF-8, implementers SHOULD interpret it
     ;              as an RFC 3986 path/authority matcher with wildcards
     url-pattern     = 1*( VCHAR / UTF8-char-noctl )

     ; host-pattern: UTF-8 hostname or wildcard; servers SHOULD match IDNA U-labels
     host-pattern    = 1*( ALPHA / DIGIT / "-" / "." / UTF8-char-noctl )

     method-list     = method *( *WS "," *WS method )



  Peiyuan                  Expires 22 October 2025                [Page 6]


  Internet-Draft               aipref-autoctl                   April 2025


     method          = "GET" / "HEAD" / "POST" / "PUT" /
                       "DELETE" / "PATCH" / "OPTIONS" /
                       "TRACE" / "CONNECT"

     purpose-list    = purpose-token *( *WS "," *WS purpose-token )
     purpose-token   = 1*VCHAR   ; placeholder for future vocabulary

     ; product-token: derived from RFC 9309
     product-token         = identifier / "*"
     identifier            = 1*( %x2D / %x41-5A / %x5F / %x61-7A )

     ; --- lexical primitives -------------------------------------

     comment         = "#" *( UTF8-char-noctl / WS / "#" )

     emptyline       = *WS [comment] EOL
     EOL             = *WS [comment] NL
     NL              = CRLF / LF / CR
     CRLF            = CR LF
     CR              = %x0D
     LF              = %x0A
     WS              = SP / HTAB
     SP              = %x20
     HTAB            = %x09

     ; --- core ABNF terminals (RFC 5234) --------------------------

     ALPHA           = %x41-5A / %x61-7A
     DIGIT           = %x30-39
     VCHAR           = %x21-7E

     ; --- UTF-8 (derived from RFC 3629) ---------------------------

     UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
     UTF8-1-noctl    = %x21 / %x22 / %x24-7F
     UTF8-2          = %xC2-DF UTF8-tail
     UTF8-3          = %xE0 %xA0-BF UTF8-tail
                     / %xE1-EC UTF8-tail-2
                     / %xED %x80-9F UTF8-tail
                     / %xEE-EF UTF8-tail-2
     UTF8-4          = %xF0 %x90-BF UTF8-tail-2
                     / %xF1-F3 UTF8-tail-3
                     / %xF4 %x80-8F UTF8-tail-2
     UTF8-tail       = %x80-BF
     UTF8-tail-2     = UTF8-tail UTF8-tail
     UTF8-tail-3     = UTF8-tail UTF8-tail UTF8-tail





  Peiyuan                  Expires 22 October 2025                [Page 7]


  Internet-Draft               aipref-autoctl                   April 2025


  5.  Extension Mechanism

     The automation-preferences.txt file defines a forward-compatible
     approach where implementations:

     *  MUST process all recognized directives according to this
        specification

     *  MUST silently ignore any unrecognized directives

     *  MUST NOT fail or produce errors when encountering extended
        directives

     This enables future extensions to add new capabilities, which may
     include:

     *  Rate limiting controls

     *  Automation technology restrictions

     *  API and XHR permissions

     *  Session requirements

     *  Asset-level annotation methods

  6.  Implementation and Enforcement

     Servers implementing this protocol SHOULD:

     *  Verify incoming requests against automation-preferences.txt.

     *  Respond with appropriate HTTP status codes (e.g., 403 Forbidden)
        [RFC9110] for non-compliant requests.

     Clients consuming this protocol SHOULD:

     *  Fetch and parse automation-preferences.txt before performing
        automated operations.

     *  Honor the HTTP method restrictions specified.

     *  Declare their automation purpose.

     *  Respect the scope directives when performing operations on
        different paths.





  Peiyuan                  Expires 22 October 2025                [Page 8]


  Internet-Draft               aipref-autoctl                   April 2025


     Implementations MAY cache automation-preferences.txt in accordance
     with [RFC9111]; all freshness calculations are governed solely by
     standard HTTP cache-control semantics.

  7.  Security Considerations

     The use of automation-preferences.txt introduces security
     considerations that SHOULD be assessed by implementors:

     *  Parsing of automation-preferences.txt MUST be performed securely
        to prevent vulnerabilities such as buffer overruns and denial-of-
        service attacks.

     *  Care SHOULD be taken to avoid exposing sensitive scope details
        that could be exploited by adversaries.

     *  The protocol does not provide authentication or cryptographic
        verification mechanisms for the file content.  Servers SHOULD
        ensure the file is served via secure connections to prevent
        tampering.

     *  The protocol does not enforce client compliance; it relies on
        good-faith adherence by automation providers.  Servers SHOULD
        implement additional detection and enforcement mechanisms when
        needed.

  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

  9.1.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
                2003, <https://www.rfc-editor.org/info/rfc3629>.

     [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/info/rfc3986>.




  Peiyuan                  Expires 22 October 2025                [Page 9]


  Internet-Draft               aipref-autoctl                   April 2025


     [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
                Specifications: ABNF", STD 68, RFC 5234,
                DOI 10.17487/RFC5234, January 2008,
                <https://www.rfc-editor.org/info/rfc5234>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/info/rfc9110>.

     [RFC9111]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Caching", STD 98, RFC 9111,
                DOI 10.17487/RFC9111, June 2022,
                <https://www.rfc-editor.org/info/rfc9111>.

     [RFC9309]  Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/info/rfc9309>.

  9.2.  Informative References

  Sample automation-preferences.txt File

     The following is an example of an automation-preferences.txt file
     that adheres to this specification:

     <!-- Automation preferences for example.com -->
     <!-- Version: 1.0 -->
     <!-- Last updated: 2025-04-20 -->

     <!-- Group 1: Applies to the entire site -->
     scope: /
     user-agent: *
     host: example.com
     allowed-methods: GET, HEAD
     allowed-purposes: PLACEHOLDER_PURPOSE1, PLACEHOLDER_PURPOSE2

     <!-- Group 2: Specific preferences for the /admin/ path -->
     scope: /admin/
     user-agent: ExampleBot
     host: example.com
     allowed-methods: GET
     allowed-purposes: PLACEHOLDER_PURPOSE1



  Peiyuan                  Expires 22 October 2025               [Page 10]


  Internet-Draft               aipref-autoctl                   April 2025


                                    Figure 4

  Author's Address

     Liao Peiyuan
     Condé Nast
     United States of America
     Email: peiyuan_liao@condenast.com











































  Peiyuan                  Expires 22 October 2025               [Page 11]


name: draft-it-aipref-attachment
rev: 00
title: Indicating Preferences Regarding Content Usage
time: 2025-05-28T02:45:54Z
group_uri: /api/v1/group/group/2440/
expires: 2025-11-29T01:55:19Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/", "/api/v1/doc/state/35/"]
categories: ["Policy/governance", "Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-03T15:50:13.454072+00:00
abstract:
  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.

full_text:
  AI Preferences                                                 G. Illyes
  Internet-Draft                                                    Google
  Updates: 9309 (if approved)                                   M. Thomson
  Intended status: Standards Track                                 Mozilla
  Expires: 29 November 2025                                    28 May 2025


               Indicating Preferences Regarding Content Usage
                       draft-it-aipref-attachment-00

  Abstract

     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.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://unicorn-
     wg.github.io/aipref-attachment/draft-it-aipref-attachment.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-it-aipref-attachment/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/unicorn-wg/aipref-attachment.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.





  Illyes & Thomson        Expires 29 November 2025                [Page 1]


  Internet-Draft          Content Usage Preferences               May 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 29 November 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Preference Expressions  . . . . . . . . . . . . . . . . .   3
       1.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Embedded Preferences  . . . . . . . . . . . . . . . . . .   4
       1.4.  Conventions and Definitions . . . . . . . . . . . . . . .   4
     2.  HTTP Content-Usage Header Field . . . . . . . . . . . . . . .   4
     3.  Robots Exclusion Protocol Content-Usage Directive . . . . . .   5
       3.1.  Processing Multiple Groups  . . . . . . . . . . . . . . .   5
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     The automated consumption of content by crawlers and other machines
     has increased significantly in recent years.  This is partly due to
     the training of machine-learning models.

     Content creators and other stakeholders, such as distributors, might
     wish to express a preference regarding the types of usage they
     consider acceptable.  Entities that might use that content need those
     preferences to be expressed in a way that is easily consumed by an
     automated system.



  Illyes & Thomson        Expires 29 November 2025                [Page 2]


  Internet-Draft          Content Usage Preferences               May 2025


     This document describes two mechanisms for associating preferences
     with content:

     *  A Content-Usage header field for HTTP [HTTP]; see Section 2.

     *  A Content-Usage directive for the Robots Exclusion Protocol
        (colloquially known as "robots.txt") [ROBOTS]; see Section 3.

     For automated systems that use HTTP to gather content, these allow
     for the automated gathering of preferences in the same way that
     content is obtained.

  1.1.  Preference Expressions

     The format of preference expressions is defined in the preference
     vocabulary [VOCAB].  The preference vocabulary defines:

     *  what preferences can be expressed,

     *  how multiple expressions of preference are combined, and

     *  how those preferences are turned into strings or byte sequences
        for use in a protocol.

     This document only defines how the strings or byte sequences are
     conveyed so that the preferences can be associated with content.

  1.2.  Examples

     A server that provides content using HTTP could signal preferences
     about how that content is used with the Content-Usage header field as
     follows:

     200 OK
     Date: Wed, 23 Apr 2025 04:48:02 GMT
     Content-Type: text/plain
     Content-Usage: ai=n

     This is some content.

     Alternatively, or additionally, a server might include the same
     directive in its "robots.txt" file:

     User-Agent: *
     Content-Usage: ai=n
     Allow: /





  Illyes & Thomson        Expires 29 November 2025                [Page 3]


  Internet-Draft          Content Usage Preferences               May 2025


  1.3.  Embedded Preferences

     This document does not define a means of embedding preferences in
     content.  Embedding preferences is expected to be an effective means
     of associating preferences with content, because it ensures that
     metadata is always associated with content.

     The main challenge with embedding is that a different method is
     needed for each content type.  That is, a different means of
     conveying preferences needs to be defined for each audio, documents,
     images, video, or other content format.  Furthermore, some content
     types, such as plain text (text/plain), offer no universal means of
     carrying metadata.  Though preferences might still be embedded in
     content with these formats, those preferences would not be reliably
     accessible to an automated system.

     The mechanisms in this document are therefore universal, in the sense
     that they apply to any content type.  They are not universal in that
     they rely on the content being obtained using HTTP (and maybe FTP).

     Future work might define how preferences might be indicated for
     alternative content distribution or acquisition methods, such as
     email.

  1.4.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  HTTP Content-Usage Header Field

     The Content-Usage field is a structured field dictionary, as defined
     in Section 3.2 of [FIELDS].  This field follows the vocabulary and
     processing rules in [VOCAB].

     This field indicates usage preferences regarding the content of the
     HTTP message.  That is, the representation data, as defined in
     Section 8.1 of [HTTP], not the resource.

     Servers MUST retain any preferences associated with a request if the
     content of that request is used to answer later requests.  For
     example, the content of a PUT request that is used to answer
     subsequent GET requests.  Note that servers that have not been
     updated to understand this field will not comply with this
     requirement.



  Illyes & Thomson        Expires 29 November 2025                [Page 4]


  Internet-Draft          Content Usage Preferences               May 2025


     The Content-Usage field does not have any special effect on caching.

  3.  Robots Exclusion Protocol Content-Usage Directive

     A Content-Usage directive is added to the Group definition in the
     Robots Exclusion Protocol format [ROBOTS].

     That is, the ABNF is extended as follows:

     group = startgroupline *(startgroupline / emptyline)
             [content-usage] ; <-- NEW
             *(rule / emptyline)

     content-usage = *WS "content-usage" *WS ":" *WS usage-pref
     usage-pref    = <usage preference vocabulary; see [VOCAB]>

     This directive updates the definition of a group to be more
     expansive.  Where a group was previously a set of user-agents (either
     "*" or a set of one or more identifiers), a Group is updated to
     include zero or one Content-Usage preferences.

  3.1.  Processing Multiple Groups

     The effect of this change is that a crawler might need to consider
     multiple groups.  A crawler needs to consider this both to decide
     whether content can be requested and to determine what preferences
     apply to content.

     Rather than looking for a group based on a specific User-Agent
     identifier, such as "ExampleBot", then falling back to the wildcard
     group ("*"), a crawler might have multiple groups, each with a
     different set of preferences.

     Where there are multiple groups, a crawler first looks for groups
     with a matching User-Agent identifer.  If any groups match the
     crawler identity (as defined in Section 2.2.1 of [ROBOTS]), all
     matching groups are considered.  If there are no matching groups, all
     groups that include a User-Agent of "*" are considered.

     In determining which group applies for a given resource, the crawler
     evaluates each group in turn.  Any group for which the resource is
     disallowed (as defined in Section 2.2.2 of [ROBOTS]) is excluded.  If
     all groups are excluded in this way, the resource is not crawled.

     If any group allows the crawling of the resource, content can be
     retrieved.  If multiple groups allow crawling, the usage preference
     from the group with the longest Allow rule match applies to that
     content.



  Illyes & Thomson        Expires 29 November 2025                [Page 5]


  Internet-Draft          Content Usage Preferences               May 2025


     For example, given the following "robots.txt" document:

     User-Agent: *
     Content-Usage: ai=n
     Allow: /
     Disallow: /never/

     User-Agent: *
     Content-Usage: ai=y
     Allow: /ai-ok/
     Disallow: /

     User-Agent: ExampleBot
     Content-Usage: ai=y
     Allow: /

     A crawler that identifies as "ExampleBot" would be able to obtain all
     content and apply preferences of "ai=y" (processed as defined in
     [VOCAB]).

     All other crawlers would use the same two groups.  The first group
     allows the retrieval of most resources, excluding resources starting
     with "/never/", and applies a usage preference of "ai=n" across those
     resources.  The second group creates a specific rule for resources
     under "/ai-ok", where the usage preference is "ai=y".  This might
     result in the following outcome after crawling:

                 +=============+=========+==================+
                 | Path        | Allowed | Saved Preference |
                 +=============+=========+==================+
                 | /test       |   yes   | ai=n             |
                 +-------------+---------+------------------+
                 | /never/test |    no   | n/a              |
                 +-------------+---------+------------------+
                 | /ai-ok/test |   yes   | ai=y             |
                 +-------------+---------+------------------+

                                   Table 1

  4.  Security Considerations

     TODO Security

  5.  IANA Considerations

     TODO request registration of field

  6.  Normative References



  Illyes & Thomson        Expires 29 November 2025                [Page 6]


  Internet-Draft          Content Usage Preferences               May 2025


     [FIELDS]   Nottingham, M. and P. Kamp, "Structured Field Values for
                HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
                <https://www.rfc-editor.org/rfc/rfc9651>.

     [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [ROBOTS]   Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

     [VOCAB]    Keller, P. and M. Thomson, "Proposal for an Opt-Out
                Vocabulary", Work in Progress, Internet-Draft, draft-ietf-
                aipref-vocab-00, 30 April 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-aipref-
                vocab-00>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Gary Illyes
     Google
     Email: garyillyes@google.com


     Martin Thomson
     Mozilla
     Email: mt@lowentropy.net








  Illyes & Thomson        Expires 29 November 2025                [Page 7]


name: draft-illyes-aipref-cbcp
rev: 02
title: Crawler best practices
time: 2025-10-07T10:43:05Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-10T10:43:05Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["ML traffic mgmt", "Policy/governance"]
tags: []
fetched_at: 2026-03-03T15:50:13.454075+00:00
abstract:
  This document describes best pratices for web crawlers.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/garyillyes/cbcp.

full_text:
  Network Working Group                                          G. Illyes
  Internet-Draft                                               Independent
  Intended status: Informational                             M. Kuehlewind
  Expires: 10 April 2026                                          Ericsson
                                                                   A. Kohn
                                                       Blind Five Year Old
                                                            7 October 2025


                           Crawler best practices
                        draft-illyes-aipref-cbcp-02

  Abstract

     This document describes best pratices for web crawlers.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Source for this draft and an issue tracker can be found at
     https://github.com/garyillyes/cbcp.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 10 April 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.







  Illyes, et al.            Expires 10 April 2026                 [Page 1]


  Internet-Draft                    cbcp                      October 2025


     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Recommended Best Practices  . . . . . . . . . . . . . . . . .   3
       2.1.  Crawlers must respect the Robots Exclusion Protocol . . .   3
       2.2.  Crawlers must be easily identifiable through their user
             agent string  . . . . . . . . . . . . . . . . . . . . . .   3
       2.3.  Crawlers must not interfere with the normal operation of a
             site  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.4.  Crawlers must support caching directives  . . . . . . . .   4
       2.5.  Crawlers must expose the IP ranges they use for
             crawling  . . . . . . . . . . . . . . . . . . . . . . . .   4
       2.6.  Crawlers must explain how the crawled data is used and how
             the crawler can be blocked  . . . . . . . . . . . . . . .   5
     3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
     6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

  1.  Introduction

     Automatic clients, such as crawlers and bots, are used to access web
     resources, including indexing for search engines or, more recently,
     training data for new artifical intelligence (AI) applications.  As
     crawling activity increases, automatic clients must behave
     appropriately and respect the constraints of the resources they
     access.  This includes clearly documenting how they can be identified
     and how their behavior can be influenced.  Therefore, crawler
     operators are asked to follow the best practices for crawling
     outlined in this document.

     To further assist website owners, it should also be considered to
     create a central registry where website owners can look up well-
     behaved crawlers.  Note that while self-declared research crawlers,
     including privacy and malware discovery crawlers, and contractual
     crawlers are welcome to adopt these practices, due to the nature of
     their relationsh with sites, they may exempt themselves from any of
     the Crawler Best Practices with a rationale.





  Illyes, et al.            Expires 10 April 2026                 [Page 2]


  Internet-Draft                    cbcp                      October 2025


  2.  Recommended Best Practices

     The following best practices should be followed and are already
     applied by a vast majority of large-scale crawlers on the Internet:

     1.  Crawlers must support and respect the Robots Exclusion Protocol.

     2.  Crawlers must be easily identifiable through their user agent
         string.

     3.  Crawlers must not interfere with the regular operation of a site.

     4.  Crawlers must support caching directives.

     5.  Crawlers must expose the ranges they are crawling from in a
         standardized format.

     6.  Crawlers must expose a page that explains how the crawling can be
         blocked, whether the page is rendered, amd how the crawled data
         is used.

  2.1.  Crawlers must respect the Robots Exclusion Protocol

     All well behaved-crawlers must support the REP as defined in
     Section 2.2.1 of [REP] to allow site owners to opt out from crawling.

     Especially if the website chooses not to use a robots.txt file as
     defined by the REP, crawlers further need to respect the X-robots-tag
     in the HTTP header.

  2.2.  Crawlers must be easily identifiable through their user agent
        string

     As outlined in Section 2.2.1 of [REP] (Robots Exclusion Protocol;
     REP), the HTTP request header 'User-Agent' should clearly identify
     the crawler, usually by including a URL that hosts the crawler's
     descrtion.  For example:

     User-Agent: Mozilla/5.0 (compatible; ExampleBot/0.1;
     +https://www.example.com/bot.html).

     This is already a widely accepted practice among crawler operators.
     To remain compliant, crawler operators must include unique
     identifiers for their crawlers in the case-insensitive User-Agent,
     such as "contains 'googlebot' and 'https://url/...'".  Additionally,
     the name should clearly identify both the crawler owner and its
     purpose as much as reasonably possible.




  Illyes, et al.            Expires 10 April 2026                 [Page 3]


  Internet-Draft                    cbcp                      October 2025


  2.3.  Crawlers must not interfere with the normal operation of a site

     Depending on a site's setup (computing resources and software
     efficiency) and its size, crawling may slow down the site or even
     take it offline altogether.  Crawler operators must ensure that their
     crawlers are equped with back-out logic that relies on at least the
     standard signals defined by Section 15.6 of [HTTP-SEMANTICS],
     preferably also additional heuristics such as a change in the
     relative response time of the server.

     Therefore, crawlers should log already visited URLs, the number of
     requests sent to each resource, and the respective HTTP status codes
     in the responses, especially if errors occur, to prevent repeatedly
     crawling the same sourceerrors occur, to prevent repeatedly crawling
     the same source.  Using the same data, crawlers should, on a best
     effort basis, crawl the site at times of the day when the site is
     estimated to have fewer human visitors.

     Generally, crawlers should avoid sending multle requests to the same
     resources at the same time and should limit the crawling speed to
     prevent server overload, if possible, following the limits outlined
     in the REP protocol.  Additionally, resources should not be re-
     crawled too often.  Ideally, crawlers should restrict the depth of
     crawling and the number of requests per resource to prevent loops.

     Crawlers should not attempt to bypass authentication or other access
     restrictions, such as when login is required, CAPTCHAs are in use, or
     content is behind a paywall, unless explicitly agreed upon with the
     website owner.

     Crawlers should primarily access resources using HTTP GET requests,
     resorting to other methods (e.g., POST, PUT) only if there is a prior
     agreement with the publisher or if the publisher's content management
     system automatically makes those calls when JavaScrt runs.
     Generally, the load caused by executing JavaScrt should be carefully
     considered or even avoided whenever possible.

  2.4.  Crawlers must support caching directives

     [HTTP-CACHING] HTTP caching removes the need of repeated access from
     crawlers to the same URL.

  2.5.  Crawlers must expose the IP ranges they use for crawling

     To complement the REP, crawler operators should publish the IP ranges
     they have allocated for crawling in [JAFAR] format, and keep this
     information reasonably up-to-date, according to the specification.




  Illyes, et al.            Expires 10 April 2026                 [Page 4]


  Internet-Draft                    cbcp                      October 2025


     The object containing the IP addresses must be linked from the page
     describing the crawler, and it must also be referenced in the page's
     metadata for machine readability.  For example:

     &lt;link rel="help" href="https://example.com/crawlerips.json"&gt;

  2.6.  Crawlers must explain how the crawled data is used and how the
        crawler can be blocked

     Crawlers must be easily identifiable through their user-agent string,
     and they should explain how the data they collect will be used.  In
     practice, this is usually done via the documentation page linked in
     the crawler's user agent.  Additionally, the documentation page
     should include a contact address for the crawler owner.

     The webpage should also provide an example REP file to block the
     crawler and a method for verifying REP files.

     If the crawler has exempted itself of these best practices, the
     documentation page should describe the reason for that.

  3.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  4.  Security Considerations

     TODO Security

  5.  IANA Considerations

     This document has no IANA actions.

  6.  Normative References

     [HTTP-CACHING]
                Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Caching", STD 98, RFC 9111,
                DOI 10.17487/RFC9111, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9111>.







  Illyes, et al.            Expires 10 April 2026                 [Page 5]


  Internet-Draft                    cbcp                      October 2025


     [HTTP-SEMANTICS]
                Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [JAFAR]    Illyes, G., "A JSON-Based Format for Publishing IP Ranges
                of Automated HTTP Clients", Work in Progress, Internet-
                Draft, draft-illyes-aipref-jafar-00, 30 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-illyes-
                aipref-jafar-00>.

     [REP]      Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Gary Illyes
     Independent
     Email: synack@garyillyes.com


     Mirja Kühlewind
     Ericsson
     Email: mirja.kuehlewind@ericsson.com


     AJ Kohn
     Blind Five Year Old
     Email: aj@blindfiveyearold.com






  Illyes, et al.            Expires 10 April 2026                 [Page 6]


name: draft-thomson-aipref-sup
rev: 00
title: Short Usage Preference Strings for Automated Processing
time: 2025-08-20T07:09:01Z
group_uri: /api/v1/group/group/2440/
expires: 2025-08-21T04:48:33Z
states: ["/api/v1/doc/state/2/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: ["Data formats/interop", "Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-03T15:50:13.454077+00:00
abstract:
  Content creators and other stakeholders might wish to signal their
     preferences about how their content might be consumed by automated
     systems.  This document defines a very simple format for expressions.

     This document updates RFC 9309 to define one means of conveyance.  An
     HTTP header field is also defined.

full_text:
  AI Preferences                                                M. Thomson
  Internet-Draft                                                   Mozilla
  Updates: 9309 (if approved)                             17 February 2025
  Intended status: Standards Track                                        
  Expires: 21 August 2025


          Short Usage Preference Strings for Automated Processing
                        draft-thomson-aipref-sup-00

  Abstract

     Content creators and other stakeholders might wish to signal their
     preferences about how their content might be consumed by automated
     systems.  This document defines a very simple format for expressions.

     This document updates RFC 9309 to define one means of conveyance.  An
     HTTP header field is also defined.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at
     https://martinthomson.github.io/sup-ai/draft-thomson-aipref-sup.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-thomson-aipref-sup/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/martinthomson/sup-ai.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.






  Thomson                  Expires 21 August 2025                 [Page 1]


  Internet-Draft         Short Usage Strings for AI          February 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 21 August 2025.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Applicability . . . . . . . . . . . . . . . . . . . . . .   3
       1.2.  Conventions and Definitions . . . . . . . . . . . . . . .   4
     2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.  Preference Expression Strings . . . . . . . . . . . . . . . .   5
       3.1.  Preference  . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Labels  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.3.  Values  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       3.4.  Duplicated Labels . . . . . . . . . . . . . . . . . . . .   5
       3.5.  Specificity . . . . . . . . . . . . . . . . . . . . . . .   6
     4.  Usage Labels  . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Defining New Labels . . . . . . . . . . . . . . . . . . .   7
       4.2.  Label Characters  . . . . . . . . . . . . . . . . . . . .   8
     5.  Processing Preference Expression Strings  . . . . . . . . . .   8
       5.1.  Parsing . . . . . . . . . . . . . . . . . . . . . . . . .   9
       5.2.  Determination . . . . . . . . . . . . . . . . . . . . . .  10
       5.3.  Optimization and Length Limits  . . . . . . . . . . . . .  10
       5.4.  Multiple Preference Expressions . . . . . . . . . . . . .  11
       5.5.  Multiple Usages . . . . . . . . . . . . . . . . . . . . .  11
     6.  Carrying Preference Expressions . . . . . . . . . . . . . . .  11
       6.1.  The "robots.txt" Format . . . . . . . . . . . . . . . . .  11
       6.2.  HTTP Header Field . . . . . . . . . . . . . . . . . . . .  12
       6.3.  Content Metadata  . . . . . . . . . . . . . . . . . . . .  13
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13



  Thomson                  Expires 21 August 2025                 [Page 2]


  Internet-Draft         Short Usage Strings for AI          February 2025


       8.1.  Preference Label Registry . . . . . . . . . . . . . . . .  14
         8.1.1.  Registration Guidance . . . . . . . . . . . . . . . .  14
         8.1.2.  Initial Registry Contents . . . . . . . . . . . . . .  15
       8.2.  HTTP Content-Usage Field Registration . . . . . . . . . .  15
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  16
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  17

  1.  Introduction

     The automated consumption of content by crawlers and other machines
     has increased significantly in recent years.  This is partly due to
     the training of machine-learning models.

     Content creators and other stakeholders, such as distributors, might
     wish to have a say in what types of usage by automatons is
     acceptable.  At the same time, the operator of an automated system
     might be happy to follow any guidance given.

     In the absence of a clear means of indicating preferences, there is
     no way for preferences to conveyed.  This document seeks to address
     this shortcoming.

     The format of preferences is a simple string that looks something
     like this:

     ai=n,search=y

     This format seeks to be:

     *  Simple to understand and create

     *  Straightforward to consume

     *  Easily conveyed in multiple ways

     The document defines extensions to "robots.txt" [ROBOTS] and HTTP
     [HTTP] for making preferences available to automated processing
     systems.

  1.1.  Applicability

     These expressions do not consider the process of acquiring content.
     They only express preferences regarding how the content is ultimately
     used.  In particular, this includes both the training of machine
     learning models and the use of those models.



  Thomson                  Expires 21 August 2025                 [Page 3]


  Internet-Draft         Short Usage Strings for AI          February 2025


     This is not intended to replace copyright licensing or other means of
     conveying similar information.  Rather, it is intended to provide
     clear information that can be used by automatons to quickly identify
     whether content is available or not for processing.

     Preference expressions do not apply where usage is explicitly allowed
     or disallowed in law or when licensing has been pre-arranged.

     This document assumes that automatons have a default policy that
     applies when no preferences have been expressed.  How those defaults
     are determined is not specified.

  1.2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  Examples

     The following string opts out of all forms of automated processing
     for the associated content:

     tdm=n

     On its own, this string does not define which content is affected.

     The following shows how a preference to allow general text and data
     mining, except for artificial intelligence applications, is applied
     to content that is delivered in an HTTP response; see Section 6.2.

     404 Not Found
     Date: Mon, 17 Feb 2025 03:32:05 GMT
     Usage-Pref: tdm=y,ai=n
     Content-Type: text/html

     <HTML page contents omitted from this example>

     Similarly, a website might use "robots.txt" (see Section 6.1) to
     indicate that search indexing is the only acceptable form of data use
     for all resources with a path that starts with "/article/":

     User-Agent: *
     Usage-Pref: tdm=n,search=y
     Allow: /article/




  Thomson                  Expires 21 August 2025                 [Page 4]


  Internet-Draft         Short Usage Strings for AI          February 2025


  3.  Preference Expression Strings

     A preference expression string is a Unicode string.

     A preference expression string comprises zero or more directives,
     where each directive is separated by a COMMA ("," or U+2C).

  3.1.  Preference

     Each preference consists of a label, an EQUALS character ("=" or
     U+3D), and value of either "y" (U+79) or "n" (U+6E).

     Preferences that do not conform to this syntax are ignored and have
     no effect.

     Some whitespace -- specifically spaces (U+20) and horizontal tabs
     (U+9) -- are ignored to make authoring easier.  Whitespace is ignored
     before and after both labels and values.

  3.2.  Labels

     Each label describes how an automaton might use content.  A set of
     core labels is defined in this document; see Section 4.

     A label that is not understood by an automaton are ignored.
     Similarly, labels that do not apply to a usage are ignored.

  3.3.  Values

     Each preference includes one of two values: "y" or "n".

     A value of "y" indicates a preference to allow the associated usage,
     unless there is a label for a more specific usage that has a value of
     "n".

     A value of "n" indicates a preference to deny the associated usage,
     unless there is a label for a more specific usage that has a value of
     "y".

     Any other value causes a preference to be ignored.

  3.4.  Duplicated Labels

     Preferences with duplicated labels are permitted.  This can happen
     when multiple preference expressions are combined; see Section 5.4.






  Thomson                  Expires 21 August 2025                 [Page 5]


  Internet-Draft         Short Usage Strings for AI          February 2025


     If multiple preferences include the same label, any preference with a
     value of "n" applies.  Failing that, any preference with a value of
     "y" is used.  Preferences that cannot be parsed successfully as
     either "y" or "n" are ignored.

     For example, the following indicates a preference to deny artificial
     intelligence uses.

     ai=y,ai=n,ai=y,unknown=y

     The order of duplicate labels has no effect on the outcome, until the
     preference expression string exceeds the length permitted by the
     automaton processing it.

  3.5.  Specificity

     A label might be defined to be more specific than another label.

     The value for the most specific applicable label applies, even if the
     more general label has a contradictory value.

     For example, the following indicates a preference to allow a use in
     generative AI applications, but not for other AI applications:

     garbage!!!,genai=y,ai=n

     The order of preferences and the presence of invalid values has no
     effect on the outcome.

  4.  Usage Labels

     This section defines a limited taxonomy of usages, with just the
     following broad usage labels:

     tdm:
        The "tdm" label relates to all forms of automated processing of
        content.  The acronym TDM stands for "text and data mining".  This
        is a broad category that refers to the practice of the automated
        extraction of any sort of information from content.

     ai:
        The "ai" label describes usage for all forms of artificial
        intelligence or machine learning.  This includes both the training
        of models using the content and the use of a model that has been
        trained using the content.  The "ai" label is more specific than
        "tdm".

     genai:



  Thomson                  Expires 21 August 2025                 [Page 6]


  Internet-Draft         Short Usage Strings for AI          February 2025


        The "genai" label describes usage for artificial intelligence or
        machine learning models that are able to produce content.  That
        content does not need to be similar in form to the content that a
        preference expression is applied.  This includes both the training
        of models using the content and the use of a model that has been
        trained using the content.  The "genai" label is more specific
        than "ai".

     search:
        The "search" label describes a use of content for developing a
        search index and the use of those indexes to find content.  The
        "search" label is more specific than "tdm".

        |  Note that although search applications often use machine
        |  learning, "search" is not more specific than the "ai" label.

  4.1.  Defining New Labels

     The set of labels can be expanded, but the core set is intended to be
     small.  The most important goal is to ensure that each label is
     clearly understood and widely recognized.  A proliferation of choices
     makes it harder to choose the right label to use and increases the
     chances that a label is not recognized by an automaton.

     An entity processing a preference expression only uses preferences
     that are known to it.  Preferences that contain labels unknown are
     ignored.  This potentially allows for the inclusion of preferences
     for new usages.

     Because new labels might not be recognized, it might be necessary for
     preference expressions to include values for more general labels in
     addition to the new and more specific label.

     For example, if a new "example" usage is defined to more specific
     than the existing "tdm" label, there are four potential expressions.
     Depending on whether an automaton is updated to support the new
     label, the outcome differs, as shown in Table 1.














  Thomson                  Expires 21 August 2025                 [Page 7]


  Internet-Draft         Short Usage Strings for AI          February 2025


                     +=========+=====+=========+=========+
                     | example | tdm | updated | old     |
                     +=========+=====+=========+=========+
                     |    n    |  n  | DENIED  | DENIED  |
                     +---------+-----+---------+---------+
                     |    n    |  y  | DENIED  | ALLOWED |
                     +---------+-----+---------+---------+
                     |    y    |  n  | ALLOWED | DENIED  |
                     +---------+-----+---------+---------+
                     |    y    |  y  | ALLOWED | ALLOWED |
                     +---------+-----+---------+---------+

                        Table 1: Backward Compatibility
                                 for New Labels

     If automatons that might use content in the new way can also be
     expected to understand the new label, then the new label can be
     safely used.  Otherwise, there is a risk that automatons infer
     permission based on more general preferences.

     Section 8 describes a process for registering new labels.

  4.2.  Label Characters

     A preference expression cannot include certain characters when
     carried in specific protocols (see Section 6):

     *  A "#" (U+23) character is interpreted as a line ending in the
        "robots.txt" format Section 6.1.

     *  The structured field dictionaries used for the auto-usage field in
        HTTP Section 6.2 limit character repertoire to lowercase
        alphabetic characters ("a" through "z"), digits ("0" through "9"),
        "_", "-", ".", and "*".

     *  Line ending characters (U+10 and U+13) and control characters
        (U+00 through U+31) are not special in this format.  However, some
        systems could be incapable of authoring, conveying, or rendering
        them without alteration.

     The format does not prohibit the use of these characters.  However,
     any new labels intended for wide compatibility SHOULD use only
     lowercase alphabetical characters.

  5.  Processing Preference Expression Strings

     This section details an example algorithm for processing of
     preference expressions.



  Thomson                  Expires 21 August 2025                 [Page 8]


  Internet-Draft         Short Usage Strings for AI          February 2025


     An automaton that receives a preference expression uses the following
     algorithm, or any process with an equivalent outcome, to determine
     whether a particular usage is ALLOWED or DENIED according to that
     expression.

     1.  The automaton parses the preference expression and produces a
         record of values for each label known to it following the process
         in Section 5.1.

     2.  The automaton selects the labels that apply to its current usage,
         including labels at all levels of generality.  These are passed
         to the determination process in Section 5.2 to determine whether
         the usage is ALLOWED or DENIED.

  5.1.  Parsing

     The process of parsing a preference expression and updating the
     record of values, is as follows:

     1.  The automaton initializes a record one variable for each of the
         labels that is known to it with a value of UNKNOWN.  Include
         labels in this record that are more general, even if the specific
         usage is properly described by that subset (for example, include
         "tdm" in addition to "search" for a simple search indexing
         function).

     2.  The expression is split into a sequence of preferences by
         splitting the string at each COMMA (",", U+2C).

     3.  Each preference is then processed in turn:

         a.  The preference is split into a label and a value at the first
         EQUALS ("=", U+3D).  Preferences that do not contain an EQUALS
         ("=", U+3D) are skipped and processing continues with the next
         preference.

         b.  Spaces (U+20) and tabs (U+9) are trimmed from the start and
         end of each label and value.  (ISSUE: move this up a step for SF
         compatibility and easier parsing?)

         c.  If the label is not understood by the automaton or the label
         does not apply to the current usage, it is ignored and the
         processing continues with the next preference.

         d.  If the value is the string "n" (a single U+6E), the record
         for that the corresponding label is set to NO.





  Thomson                  Expires 21 August 2025                 [Page 9]


  Internet-Draft         Short Usage Strings for AI          February 2025


         e.  If the value is the string "y" (a single U+79), and the
         current record for the corresponding label is not set, that
         record is set to YES.

  5.2.  Determination

     When values have been recorded for known labels, the automaton
     selects the labels that applies to a specific usage.

     This includes more general labels.  For example, a "genai"
     application would include both "ai" and "tdm" labels.

     The following process can be followed to determine whether that usage
     is ALLOWED or DENIED according to a preference expression.

     1.  Starting with the most general labels, iterate over the recorded
         value for each label.

         a.  For each of the labels that are more specific than this
         label, replace any value of UNKNOWN for that more specific label
         with the value from this (more general) label.

         b.  If all aspect of the usage is covered by more specific labels
         discard the more general label from the record.

     2.  If the value for any of the remaining labels is UNKNOWN, the
         automaton substitutes a YES or NO value based on its configured
         policy for missing preferences for the corresponding label.

     3.  If the value for any of the remaining labels is NO, resolve that
         the indicated preference regarding the usage is DENIED.

     4.  Otherwise, resolve that the indicated preference regarding the
         usage is ALLOWED.

     In addition to understanding which labels apply to a given usage,
     automatons need to have a default policy for each of those labels.

  5.3.  Optimization and Length Limits

     The parsing of preference expressions can be implemented in a
     streaming fashion, requiring minimal state beyond that needed to
     track the value of applicable labels.

     A preference expression of arbitrary length can be processed
     efficiently.  However, implementations MAY choose to stop processing
     expressions at any point once at least 1000 characters have been
     processed.



  Thomson                  Expires 21 August 2025                [Page 10]


  Internet-Draft         Short Usage Strings for AI          February 2025


  5.4.  Multiple Preference Expressions

     An automaton that is consuming content might encounter multiple
     preference expressions that relate to the same piece of content.  For
     example, preference expressions might be carried by both "robots.txt"
     (Section 6.1) and content metadata (Section 6.3).

     Multiple preference expressions can be combined by simple
     concatenation in any order.  A single comma (",") is inserted between
     each expression.

     For an identical outcome, the parsing process (Section 5.1) can be
     run separately for each expression, updating the same record of
     values rather than starting anew for each.

  5.5.  Multiple Usages

     An automaton that might use content for multiple purposes can parse
     preference expressions once.

     The parsing process (Section 5.1) can be run, recording the value of
     all labels that apply to any of the potential usages.

     The state that is produced from parsing can be retained and applied
     (Section 5.2) to each different usage.

  6.  Carrying Preference Expressions

     A preference expression might be propagated by multiple different
     mechanisms.  This provides content creators and distributors choice
     in how they manage the signaling of their preferences.

  6.1.  The "robots.txt" Format

     Use of "robots.txt" , or the Robots Exclusion Protocol [ROBOTS],
     provides automated crawlers with information about what resources can
     be gathered.

     This is a file that is served in a well-known location by HTTP
     servers.

     An extension is defined for this format to allow for carrying simple
     usage preference strings.  A rule name of "usage" is added to each
     group, appearing between the startgroupline and rule lines as
     follows:






  Thomson                  Expires 21 August 2025                [Page 11]


  Internet-Draft         Short Usage Strings for AI          February 2025


     group = startgroupline
             *(startgroupline / emptyline)
             *(usage / emptyline)
             *(rule / emptyline)
     usage = *WS "usage" *WS ":" usage-pref-exp EOL
     usage-pref-exp = *UTF8-char-noctl

     Notes:

     *  The label "usage" is case insentive, but the preference expression
        is case sensitive.

     *  Preference expressions will be truncated at the first "#"
        character (U+23); see Section 4.2.  Labels that include this
        character can be omitted.

  6.2.  HTTP Header Field

     An HTTP Response Header field called Content-Usage is defined.

     This field is defined as a structured field dictionary, as defined in
     Section 3.2 of [RFC9651].

     Dictionary members MUST all include a single token value
     (Section 3.3.4 of [RFC9651]) that is either "y" or "n".

     The Content-Usage field applies to the content of a request or
     response, not the resource or representation.

     The Content-Usage field can be used in requests to have the
     preference apply to the content of the request.  Servers could retain
     a copy of preferences if the content of a request is used to answer
     later requests.  For example, the content of a PUT request that is
     used to answer subsequent GET requests.  Servers SHOULD reject
     requests that include Content-Usage unless the same or compatible
     preferences can be provided to entities that might obtain the
     included content.  Obviously, servers that have not been updated to
     this specification will not.

     Content-Usage does not have any special effect on caching.

     The value of this field MAY be first parsed using a structured field
     parser.  This implies the following restrictions:

     *  Structured field parsers do not permit whitespace between
        dictionary key, the "=" separator, and value.  Therefore, this
        additional space MUST be removed before creating the field.




  Thomson                  Expires 21 August 2025                [Page 12]


  Internet-Draft         Short Usage Strings for AI          February 2025


     *  Dictionary members are tokens, not Booleans (Section 3.3.6 of
        [RFC9651]).  Boolean members MUST be ignored.

     *  Dictionary members with parameters MUST be ignored.

  6.3.  Content Metadata

     Specific formats can define how preference expressions are carried in
     content metadata.

     This document does not define any such format.

        |  Question: Should we define how to use HTML meta, or rely on
        |  http-equiv?

  7.  Security Considerations

     This document defines a preference mechanism, not a security feature.

     The primary consideration for security is the correct and efficient
     implementation of parsing.  Errors in parsers have been known to be
     exploited by actors that produce malicious input to effect one of two
     common types of problem:

     *  buffer overruns, where malicious input is formed to enable remote
        code execution

     *  denial of service, where malicious input is constructed to be
        difficult to process in order to exhaust resources

     The algorithms in Section 5 are not immune to these issues if
     incautiously implemented by an automaton.  They are exemplary only
     and are biased toward being comprehensible rather than being secure.

     Preference strings could include characters that can create confusing
     or misleading renderings.  For instance, invisible characters or U+8
     (backspace) could be used to create a misleading representation.
     These characters can be avoided when authoring preference expressions
     and replaced when displaying them (using U+FFFD for example).

  8.  IANA Considerations

     This document defines a new registry for labels (Section 8.1) and an
     HTTP header field (Section 8.2).







  Thomson                  Expires 21 August 2025                [Page 13]


  Internet-Draft         Short Usage Strings for AI          February 2025


  8.1.  Preference Label Registry

     This document establishes a registry that lists Labels for Preference
     Expressions for Automated Use of Content with IANA.  The policy for
     new registrations is Specification Required [RFC8126].

     Each entry has the following fields:

     Label:
        a Unicode string (see Section 4.1 for advice on selecting values)
     Definition:
        a short description of the automated usage that the label applies
        to
     Narrows:
        a list of other labels that this label is more specific than
     Specification:
        a link to a publicly accessible specification that contains a more
        complete definition
     Status:
        either is "provisional" or "permanent" (see below)
     Date:
        the date of the last update to the registration
     Change Controller:
        the entity responsible for the specification
     Contact:
        contact details for the registrant

  8.1.1.  Registration Guidance

     An ideal label for a new registration is short, descriptive, and
     memorable.  Lowercase characters (U+61 through U+7A) are most
     compatible; see Section 4.2.

     Provisional registrations can be used by entities other than a change
     controller to register labels in order to avoid registration
     collisions.  Provisional registrations can omit fields.  However,
     provisional labels can be removed if details are not provided within
     12 months.  Removals are subject to approval by the IESG.

     Designated experts are advised to discourage new permanent
     registrations in favor of provisional registrations.  Once utility
     and -- critically -- understanding of labels has been demonstrated,
     provisional registrations can be upgraded to permanent status.

     Designated experts are expected to help ensure that registrations
     correctly identify which labels are more general.  This could include
     updates to existing labels, to reference a new registration as being
     more general.



  Thomson                  Expires 21 August 2025                [Page 14]


  Internet-Draft         Short Usage Strings for AI          February 2025


     Designated experts are expected to deny registration requests for
     large numbers of labels, labels that are unclear in purpose, labels
     that are too similar to existing labels, labels that are long, and
     labels that promote proprietary products or unproven concepts.

     Expert decisions can be appealed to the IESG.

  8.1.2.  Initial Registry Contents

     Table 2 tabulates the other fields for registrations of labels from
     Section 3.2.

          +========+=====================================+=========+
          | Label  | Definition                          | Narrows |
          +========+=====================================+=========+
          | tdm    | Any automated process that extracts |         |
          |        | information from content            |         |
          +--------+-------------------------------------+---------+
          | ai     | Training or use of any machine      | tdm     |
          |        | learning system (or AI)             |         |
          +--------+-------------------------------------+---------+
          | genai  | Training or use of machine learning | ai      |
          |        | (or AI) that can generate content   |         |
          +--------+-------------------------------------+---------+
          | search | Generation of search index or use   | tdm     |
          |        | for search applications             |         |
          +--------+-------------------------------------+---------+

                     Table 2: Initial Label Registrations

     Initial registrations in this registry also include the following
     values:

     Specification:  this document
     Status:  permanent
     Date:  the date of publication of this document
     Change Controller:  IETF
     Contact:  IETF AI-PREF WG (ai-control@ietf.org)

  8.2.  HTTP Content-Usage Field Registration

     An HTTP field named Content-Usage is registered in the Hypertext
     Transfer Protocol (HTTP) Field Name Registry, following the
     procedures in Section 18.4 of [HTTP].  The following values are
     registered:

     Field Name:  Content-Usage
     Status:  permanent



  Thomson                  Expires 21 August 2025                [Page 15]


  Internet-Draft         Short Usage Strings for AI          February 2025


     Reference:  this document
     Comments:  (none)

  9.  References

  9.1.  Normative References

     [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
                Writing an IANA Considerations Section in RFCs", BCP 26,
                RFC 8126, DOI 10.17487/RFC8126, June 2017,
                <https://www.rfc-editor.org/rfc/rfc8126>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [RFC9651]  Nottingham, M. and P. Kamp, "Structured Field Values for
                HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
                <https://www.rfc-editor.org/rfc/rfc9651>.

     [ROBOTS]   Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.

  9.2.  Informative References

     [REP-PURPOSE]
                Illyes, G., "Robots Exclusion Protocol User Agent Purpose
                Extension", Work in Progress, Internet-Draft, draft-
                illyes-rep-purpose-00, 18 October 2024,
                <https://datatracker.ietf.org/doc/html/draft-illyes-rep-
                purpose-00>.








  Thomson                  Expires 21 August 2025                [Page 16]


  Internet-Draft         Short Usage Strings for AI          February 2025


     [VOCAB]    Vaughan, T., "Vocabulary for Expressing Content
                Preferences for AI Training", Work in Progress, Internet-
                Draft, draft-vaughan-aipref-vocab-00, 20 January 2025,
                <https://datatracker.ietf.org/doc/html/draft-vaughan-
                aipref-vocab-00>.

  Acknowledgments

     This document is informed by discussions at the AI-CONTROL workshop.

     Drafts from Gary Ilyes ([REP-PURPOSE] and Thom Vaughan [VOCAB] helped
     inform some of the choices.  This document aims to be more complete
     than the former and simpler than the latter.

  Author's Address

     Martin Thomson
     Mozilla
     Email: mt@lowentropy.net
































  Thomson                  Expires 21 August 2025                [Page 17]


name: draft-ietf-aipref-vocab
rev: 05
title: A Vocabulary For Expressing AI Usage Preferences
time: 2025-12-01T08:30:50Z
group_uri: /api/v1/group/group/2440/
expires: 2026-06-04T08:30:50Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Policy/governance", "Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-03T15:50:13.454080+00:00
abstract:
  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.

full_text:
  AI Preferences                                                 P. Keller
  Internet-Draft                                               Open Future
  Intended status: Standards Track                         M. Thomson, Ed.
  Expires: 4 June 2026                                             Mozilla
                                                           1 December 2025


              A Vocabulary For Expressing AI Usage Preferences
                         draft-ietf-aipref-vocab-05

  Abstract

     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.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://ietf-wg-
     aipref.github.io/drafts/draft-ietf-aipref-vocab.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-aipref-vocab/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-wg-aipref/drafts.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."



  Keller & Thomson           Expires 4 June 2026                  [Page 1]


  Internet-Draft          AI Preference Vocabulary           December 2025


     This Internet-Draft will expire on 4 June 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Statements of Preference  . . . . . . . . . . . . . . . . . .   4
       3.1.  Conformance . . . . . . . . . . . . . . . . . . . . . . .   5
       3.2.  Applicability and Effect  . . . . . . . . . . . . . . . .   5
     4.  Vocabulary Definition . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Foundation Model Production Category  . . . . . . . . . .   6
       4.2.  Search  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.3.  Vocabulary Extensions . . . . . . . . . . . . . . . . . .   7
     5.  Applying Statements of Preference . . . . . . . . . . . . . .   7
       5.1.  Combining Preferences . . . . . . . . . . . . . . . . . .   8
       5.2.  More Specific Instructions  . . . . . . . . . . . . . . .   8
     6.  Exemplary Serialization Format  . . . . . . . . . . . . . . .   9
       6.1.  Usage Category Labels . . . . . . . . . . . . . . . . . .   9
       6.2.  Preference Labels . . . . . . . . . . . . . . . . . . . .   9
       6.3.  Text Encoding . . . . . . . . . . . . . . . . . . . . . .  10
       6.4.  Syntax Extensions . . . . . . . . . . . . . . . . . . . .  10
       6.5.  Processing Algorithm  . . . . . . . . . . . . . . . . . .  10
       6.6.  Alternative Formats . . . . . . . . . . . . . . . . . . .  12
     7.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
     8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
       9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13







  Keller & Thomson           Expires 4 June 2026                  [Page 2]


  Internet-Draft          AI Preference Vocabulary           December 2025


  1.  Introduction

     This document defines a vocabulary of preferences regarding how
     automated systems process digital assets -- in particular, the
     training and use of AI models.  This vocabulary can be used to
     describe the types of uses that a declaring party may wish to
     explicitly restrict or allow.

     The vocabulary is intended to be used in jurisdictions where
     expressing preferences results in legal obligations, as well as where
     there are no associated legal obligations.  In either case,
     expressing preferences is without prejudice to applicable laws,
     including the applicability of exceptions and limitations to
     copyright.

     Section 3 defines the data model for AI Preferences.  Section 4
     defines the terms of the vocabulary.  Section 5 explains how to use
     AI Preferences in a data processing application, and Section 6
     describes a way to serialize preferences into a string.  Section 5
     describes a process for determining the preference for a category of
     use.

     [ATTACH] defines mechanisms to associate preferences with assets.
     Other means of association might be defined separately in the future.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     This document uses the following terms:

     Artificial Intelligence (AI):
        An engineered system of sufficient complexity that, for a given
        set of human-defined objectives, learns from data to generate
        outputs such as content, predictions, recommendations, or
        decisions.
     AI Training:
        The application of machine learning to data to produce or improve
        a model for an artificial intelligence system.
     Asset:
        A digital file or stream of data, usually with associated
        metadata.
     Declaring party:
        The entity that expresses a preference with regards to an Asset.



  Keller & Thomson           Expires 4 June 2026                  [Page 3]


  Internet-Draft          AI Preference Vocabulary           December 2025


     Machine Learning (ML):
        The processing of data to produce or improve a model that encodes
        the relationship between the data and human-defined objectives.
     Search Application:
        A search application is a system that enables users locate items
        on the internet or in a specific data store.

  3.  Statements of Preference

     The vocabulary is a set of categories, each of which is defined to
     cover a class of usage for assets.  Section 4 defines the core set of
     usage categories in detail.

     A statement of preference -- or usage preference -- is made about an
     asset.  A statement of preference follows a simple data model where a
     preference is assigned to each of the categories of use in the
     vocabulary.  A preference is either to allow or disallow the usage
     associated with the category.

     A statement of preference can indicate preferences about some, all,
     or none of the categories from the vocabulary.  This can mean that no
     preference is stated for a given usage category.

     Some categories describe a proper subset of the usages of other
     categories.  A preference that is stated for the more general
     category applies if no preference is stated for the more specific
     category.

     For example, a more general category might be assigned a preference
     that allows the associated usage.  In the absence of any statement of
     preference regarding categories that are more specific subsets of
     that usage category, usage within those categories would be also be
     allowed.  An explicit preference regarding the more specific usage
     category can be used to disallow the more specific usage, while
     indicating that other usage within the more general category is
     permissible.

     After processing a statement of preferences the recipient associates
     each category of use one of three preference values: "allowed",
     "disallowed", or "unknown".  In the absence of a statement of
     preference, all usage categories are assigned a preference value of
     "unknown".

     The process for consulting a statement of preference is defined in
     Section 5.






  Keller & Thomson           Expires 4 June 2026                  [Page 4]


  Internet-Draft          AI Preference Vocabulary           December 2025


     Different declaring parties might each make their own statement of
     preference regarding a particular asset.  The process for managing
     multiple statements of preference is defined in Section 5.1.

     An exemplary syntax for statements of preference is defined in
     Section 6.

  3.1.  Conformance

     This document and [ATTACH] describe how statements of preference are
     associated with assets.  An implementation is conformant to these
     specifications if it correctly follows all normative requirements
     that apply to it.

     The process of obtaining a statement of preference has very limited
     scope for variation between implementations.

  3.2.  Applicability and Effect

     This specification provides a set of definitions for different
     categories of use, plus a system for associating simple preferences
     to each (allow, disallow, or no preference; see Section 3).

     This specification does not provide any enforcement mechanism for
     those preferences, and conformance to it does not encompass whether
     preferences are actually respected during data processing.

     Preferences do not themselves create rights or prohibitions, either
     in the positive or the negative.  Other mechanisms—technical, legal,
     contractual, or otherwise—might enforce stated preferences and
     thereby determine the consequences of following or not following a
     stated preference.

     An entity that receives usage preferences MAY choose to respect those
     preferences it has discovered, according to an understanding of how
     the asset is used, how that usage corresponds to the usage categories
     where preferences have been stated, and the applicable legal context.

     Usage preferences can be ignored due to express agreements between
     relevant parties, explicit provisions of law, or the exercise of
     discretion in situations where widely recognized priorities justify
     doing so.  Priorities that could justify ignoring preferences
     include—but are not limited to—free expression, safety, education,
     scholarship, research, preservation, interoperability, and
     accessibility.






  Keller & Thomson           Expires 4 June 2026                  [Page 5]


  Internet-Draft          AI Preference Vocabulary           December 2025


     The following lists examples of cases where other priorities could
     lead someone to ignore expressed preferences in a particular
     situation:

     *  People with accessibility needs, or organizations working on their
        behalf, might decide to ignore a preference in order to access
        automated captions or generate accessible formats.

     *  A cultural heritage organization might decide to ignore a
        preference in order to provide more useful, reliable, or
        discoverable access to historical web collections.

     *  An educational institution might decide to ignore a preference in
        order to enable scholars to develop or use tools to facilitate
        scientific or other types of research.

     *  A website that permits user uploads might decide to ignore a
        preference in order to develop or use tools that detect harmful
        content according to established terms of use.

     Because enforcement is not provided by this specification, the
     consequences of ignoring preferences could vary depending upon how a
     given legal jurisdiction recognizes preferences.

  4.  Vocabulary Definition

     This section defines the categories of use in the vocabulary.

  4.1.  Foundation Model Production Category

     The act of using an asset to train or fine-tune a foundation model.

     Foundation models are large models that are produced using deep
     learning or other machine learning techniques.  Foundation models are
     trained on very large numbers of assets so that they can be applied
     to a wide range of use cases.  Foundation models typically possess
     generative capabilities in one or more media.

     Fine-tuning can specialize a general-purpose foundation model for a
     narrower set of use cases.

  4.2.  Search

     Using one or more assets in a search application that directs users
     to the location from which the assets were retrieved.

     The presentation of any asset that is included in search output
     includes the following conditions:



  Keller & Thomson           Expires 4 June 2026                  [Page 6]


  Internet-Draft          AI Preference Vocabulary           December 2025


     *  A reference to the location that the asset was obtained is
        presented as part of the output.

     *  The asset can only be represented in the output with excerpts that
        are drawn verbatim from it.

     An asset can be used in ranking, but not present in output.

     Internal processing of assets to perform ranking and presentation can
     include the use and training of AI models.  This only includes any
     training that is necessary to produce models used in the search
     application.

     With both these conditions, a preference to allow Search usage
     enables the presentation of links and titles in what is considered
     "traditional" search results.

  4.3.  Vocabulary Extensions

     Extensions to this vocabulary need to be defined in an RFC that
     updates this document.

     Any future extensions to this vocabulary MUST NOT introduce
     additional categories that include existing categories defined in the
     vocabulary.  That is, new categories of use can be defined as a
     subset of an existing category, but not a superset.

     Systems that use this vocabulary might define their own extensions as
     part of a larger data model.  Section 6.6 describes how concepts from
     an alternative format might be mapped to this vocabulary.

  5.  Applying Statements of Preference

     After acquiring a statement of preference, which might use the
     process in Section 6.5, an application can determine the status of a
     specific usage category as follows:

     1.  If the statement of preference contains an explicit preference
         regarding that category of use -- either to allow or disallow --
         that is the result.

     2.  Otherwise, if the usage category is a proper subset of another
         usage category, recursively apply this process to that category
         and use the result of that process.

     3.  Otherwise, no preference is stated.





  Keller & Thomson           Expires 4 June 2026                  [Page 7]


  Internet-Draft          AI Preference Vocabulary           December 2025


     This process results in one of three potential answers: allow,
     disallow, and unknown.  Applications can use the answer to guide
     their behavior.

     One approach for dealing with an "unknown" outcome is to assign a
     default value.  This document takes no position on what default might
     be assigned.

  5.1.  Combining Preferences

     The application might have multiple statements of preference,
     obtained using different methods or from different declaring parties.
     This might result in conflicting answers.

     Absent some other means of resolving conflicts, the following process
     applies to each usage category:

     *  If any statement of preference indicates that the usage is
        disallowed, the result is that the usage is disallowed.

     *  Otherwise, if any statement of preference allows the usage, the
        result is that the usage is allowed.

     *  Otherwise, no preference is stated.

     This process ensures that the most restrictive preference applies.

  5.2.  More Specific Instructions

     A recipient of a statement of preferences that follows the model in
     Section 3 might receive more specific instructions in two ways:

     *  Extensions to the vocabulary might define more specific categories
        of usage.  Preferences about more specific categories override
        those of any more general category.

     *  Contractual agreements or other specific arrangements might
        override statements of preference.

     For instance, a statement of preferences might indicate a preference
     to disallow a category of use for an asset.  If arrangements, such as
     legal agreements, exist that explicitly permit the use of that asset,
     those arrangements likely apply despite the existence of machine-
     readable statements of preference, unless the terms of the
     arrangement explicitly say otherwise.






  Keller & Thomson           Expires 4 June 2026                  [Page 8]


  Internet-Draft          AI Preference Vocabulary           December 2025


  6.  Exemplary Serialization Format

     This section defines an exemplary serialization format for
     preferences.  The format describes how the abstract model could be
     turned into Unicode text or sequence of bytes.

     The format relies on the Dictionary type defined in Section 3.2 of
     [FIELDS].  The dictionary keys correspond to usage categories and the
     dictionary values correspond to explicit preferences, which can be
     either y or n; see Section 6.2.

     For example, the following states a preference to allow foundation
     model production (Section 4.1), disallow search (Section 4.2), and
     and states no preference for other categories other than subsets of
     these categories:

     train-ai=y, search=n

  6.1.  Usage Category Labels

     Each usage category in the vocabulary (Section 4) is mapped to a
     short textual label.  Table 1 tabulates this mapping.

           +=============================+==========+=============+
           | Category                    | Label    | Reference   |
           +=============================+==========+=============+
           | Foundation Model Production | train-ai | Section 4.1 |
           +-----------------------------+----------+-------------+
           | Search                      | search   | Section 4.2 |
           +-----------------------------+----------+-------------+

                       Table 1: Mappings for Categories

     These tokens are case sensitive.

     Tokens defined for a new usage category can only use lowercase latin
     characters (a-z), digits (0-9), "_", "-", ".", or "*".  These are
     encoded using the mappings in [ASCII].

  6.2.  Preference Labels

     The data model in Section 3 used has two options for preferences
     associated with each category: allow and disallow.  These are mapped
     to single byte Tokens (Section 3.3.4 of [FIELDS]) of y and n,
     respectively.






  Keller & Thomson           Expires 4 June 2026                  [Page 9]


  Internet-Draft          AI Preference Vocabulary           December 2025


  6.3.  Text Encoding

     Structured Fields [FIELDS] describes a byte-level encoding of
     information, not a text encoding.  This makes this format suitable
     for inclusion in any protocol or format that carries bytes.

     Some formats are defined in terms of strings rather than bytes.
     These formats might need to decode the bytes of this format to obtain
     a string.  As the syntax is limited to ASCII [ASCII], an ASCII
     decoder or UTF-8 decoder [UTF8] can be used.  This results in the
     strings that this document uses.

     Processing (see Section 6.5) requires a sequence of bytes, so any
     format that uses strings needs to encode strings first.  Again, this
     process can use ASCII or UTF-8.

  6.4.  Syntax Extensions

     There are two ways by which this syntax might be extended: the
     addition of new labels and the addition of parameters.

     New labels might be defined to correspond to new usage categories.
     Section 4.3 addresses the considerations for defining new categories.
     New labels might also be defined for other types of extension that do
     not assign a preference to a usage category.  In either case, when
     processing a parsed Dictionary to obtain preferences, any unknown
     labels MUST be ignored.

     The Dictionary syntax (Section 3.2 of [FIELDS]) can associate
     parameters with each key-value pair.  This document does not define
     any semantics for any parameters that might be included.  When
     processing a parsed Dictionary to obtain preferences, any unknown
     parameters MUST be ignored.

     In either case, new extensions need to be defined in an RFC that
     updates this document.

  6.5.  Processing Algorithm

     To process a series of bytes to recover the stated preferences, those
     bytes are parsed into a Dictionary (Section 4.2.2 of [FIELDS]), then
     preferences are assigned to each usage category in the vocabulary.

     This algorithm produces a keyed collection of values, where each key
     has at most one value and optional parameters.






  Keller & Thomson           Expires 4 June 2026                 [Page 10]


  Internet-Draft          AI Preference Vocabulary           December 2025


     To obtain preferences, iterate through the defined categories in the
     vocabulary.  For the label that corresponds to that category (see
     Table 1), obtain the corresponding value from the collection,
     disregarding any parameters.  A preference is assigned as follows:

     *  If the value is a Token with a value of y, the associated
        preference is to allow that category of use.

     *  If the value is a Token with a value of n, the associated
        preference is to disallow that category of use.

     *  Otherwise, no preference is stated for that category of use.

     Note that this last alternative includes the key being absent from
     the collection, values that are not Tokens, and Token values that are
     other than y or n.  All of these are not errors, they only result in
     no preference being inferred.

     It is important to note that if the same key appears multiple times,
     only the last value is taken.  This means that duplicating a key
     could result in unexpected outcomes.  For example, the following
     expresses no preferences:

     train-ai=y, train-ai="n", search=n, search

     If the parsing of the Dictionary fails, no preferences are stated.
     This includes where keys include uppercase characters, as this format
     is case sensitive (more correctly, it operates on bytes, not
     strings).

     This document does not define a use for parameters.  Where parameters
     are used, only those parameters associated with the value that is
     selected according to Section 4.2.2 of [FIELDS].  Parameters can
     therefore be carried for any preference value, including where no
     preference is expressed.

     For example, the following train-ai preference has parameters even
     though no preference is expressed:

     train-ai;has;parameters="?";

     This process produces an abstract data model that assigns a
     preference to each usage category as described in Section 3.








  Keller & Thomson           Expires 4 June 2026                 [Page 11]


  Internet-Draft          AI Preference Vocabulary           December 2025


  6.6.  Alternative Formats

     This format is only an exemplary way to represent preferences.  The
     data model described in Section 3, can be used without this
     serialization.

     Any alternative format needs to define the mapping both from that
     format to the model used in this document and from the model to the
     alternative format.  This includes any potential for extensions
     (Section 6.4).

     The mapping between the data model and the alternative format does
     not need to be complete, it only needs to be clear and unambiguous.

     For example, an alternative format might only provide the ability to
     convey preferences for a subset of the categories of use.  A mapping
     might then define that no preference is associated with other
     categories.

  7.  Security Considerations

     Preferences are not a security mechanism.  Section 3.2 addresses what
     it means to express a preference.

     Processing a concrete instantiation of the exemplary format described
     in Section 6 is subject to the security considerations in Section 6
     of [FIELDS].

  8.  IANA Considerations

     This document has no IANA actions.

  9.  References

  9.1.  Normative References

     [ASCII]    Cerf, V., "ASCII format for network interchange", STD 80,
                RFC 20, DOI 10.17487/RFC0020, October 1969,
                <https://www.rfc-editor.org/rfc/rfc20>.

     [FIELDS]   Nottingham, M. and P. Kamp, "Structured Field Values for
                HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
                <https://www.rfc-editor.org/rfc/rfc9651>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.



  Keller & Thomson           Expires 4 June 2026                 [Page 12]


  Internet-Draft          AI Preference Vocabulary           December 2025


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  9.2.  Informative References

     [ATTACH]   Illyes, G. and M. Thomson, Ed., "A Vocabulary For
                Expressing AI Usage Preferences", Work in Progress,
                Internet-Draft, draft-ietf-aipref-attach-00, 1 December
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                aipref-attach-00>.

     [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
                10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
                2003, <https://www.rfc-editor.org/rfc/rfc3629>.

  Acknowledgments

     The following individuals made significant contributions to this
     document:

     *  Lila Bailey
     *  Cullen Miller
     *  Laurent Le Meur
     *  Krishna Madhavan
     *  Felix Reda
     *  Leonard Rosenthol
     *  Sebastian Posth
     *  Erin Simon
     *  Timid Robot Zehta

  Authors' Addresses

     Paul Keller
     Open Future
     Email: paul@openfuture.eu


     Martin Thomson (editor)
     Mozilla
     Email: mt@lowentropy.net










  Keller & Thomson           Expires 4 June 2026                 [Page 13]


name: draft-ietf-aipref-attach
rev: 04
title: Associating AI Usage Preferences with Content in HTTP
time: 2025-11-03T09:31:21Z
group_uri: /api/v1/group/group/2440/
expires: 2026-05-01T17:09:17Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["A2A protocols", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:13.454083+00:00
abstract:
  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.

full_text:
  AI Preferences                                                 G. Illyes
  Internet-Draft                                                    Google
  Updates: 9309 (if approved)                                   M. Thomson
  Intended status: Standards Track                                 Mozilla
  Expires: 1 May 2026                                      28 October 2025


           Associating AI Usage Preferences with Content in HTTP
                        draft-ietf-aipref-attach-04

  Abstract

     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.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://ietf-wg-
     aipref.github.io/drafts/draft-ietf-aipref-attach.html.  Status
     information for this document may be found at
     https://datatracker.ietf.org/doc/draft-ietf-aipref-attach/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-wg-aipref/drafts.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.





  Illyes & Thomson           Expires 1 May 2026                   [Page 1]


  Internet-Draft          AI Preference Attachment            October 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 1 May 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
       1.1.  Statements of Preference  . . . . . . . . . . . . . . . .   3
       1.2.  Examples  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.3.  Other Mechanisms  . . . . . . . . . . . . . . . . . . . .   4
         1.3.1.  Embedded Preferences  . . . . . . . . . . . . . . . .   4
         1.3.2.  Registry-Based Preferences  . . . . . . . . . . . . .   4
       1.4.  Conventions and Definitions . . . . . . . . . . . . . . .   5
     2.  HTTP Content-Usage Header Field . . . . . . . . . . . . . . .   5
     3.  Robots Exclusion Protocol Content-Usage Rule  . . . . . . . .   5
       3.1.  Content-Usage Rule Semantics  . . . . . . . . . . . . . .   6
       3.2.  Processing Content-Usage Rules  . . . . . . . . . . . . .   7
       3.3.  When Preferences Apply  . . . . . . . . . . . . . . . . .   7
       3.4.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   8
     4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
     5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
       6.2.  Informative References  . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

  1.  Introduction

     The automated consumption of content by crawlers and other machines
     has increased significantly in recent years.  This is partly due to
     the training of machine-learning models.



  Illyes & Thomson           Expires 1 May 2026                   [Page 2]


  Internet-Draft          AI Preference Attachment            October 2025


     Content creators and other stakeholders, such as distributors, might
     wish to express a preference regarding the types of usage they
     consider acceptable.  Entities that might use that content need those
     preferences to be stated in a way that is easily consumed by an
     automated system.

     This document describes two mechanisms for associating preferences
     with content:

     *  A Content-Usage header field for HTTP [HTTP]; see Section 2.

     *  A Content-Usage directive for the Robots Exclusion Protocol
        (colloquially known as "robots.txt") [ROBOTS]; see Section 3.

     For automated systems that use HTTP to gather content, these allow
     for the automated gathering of preferences in the same way that
     content is obtained.

  1.1.  Statements of Preference

     The format of a statement of preference is defined in the preference
     vocabulary [VOCAB].  The preference vocabulary defines:

     *  a model for associating usage preferences with categories of use,

     *  some categories of use,

     *  how multiple statements of preference are combined, and

     *  how those preferences are turned into strings or byte sequences
        for use in a protocol.

     This document only defines how the strings or byte sequences are
     conveyed so that statements of preference can be associated with
     content.

  1.2.  Examples

     A server that provides content could signal preferences about how
     that content is used by the Content-Usage header field in the HTTP
     response:

     HTTP/1.1 200 OK
     Date: Wed, 23 Apr 2025 04:48:02 GMT
     Content-Type: text/plain
     Content-Usage: train-ai=n

     This is some content.



  Illyes & Thomson           Expires 1 May 2026                   [Page 3]


  Internet-Draft          AI Preference Attachment            October 2025


     Alternatively, or additionally, a server might include the same
     directive in its "robots.txt" file:

     User-Agent: *
     Allow: /
     Content-Usage: train-ai=n

  1.3.  Other Mechanisms

     This document provides two general purpose methods for associating
     statements of preference with assets that are transferred using HTTP.

     The mechanisms in this document can be applied to any content type,
     provided that the content is obtained using HTTP (and maybe FTP).
     Future work might define how preferences might be indicated for
     alternative content distribution or acquisition methods, such as
     email.

     The attachment mechanism in this document are intended to be
     complementary with other mechanisms.

  1.3.1.  Embedded Preferences

     Embedding preferences is expected to be an effective means of
     associating preferences with content, because it ensures that
     metadata is always associated with content.  This document, however,
     does not define any specific means of embedding preferences in
     content.

     The main challenge with embedding preferences is that a different
     method might be needed for each content type.  That is, a different
     storage or serialization model of conveying the preferences might
     need to be defined for each format whether it represent audio,
     documents, images, video, or other types of content.  Furthermore,
     some content types, such as plain text (text/plain), offer no
     standardized means of embedding preferences.

  1.3.2.  Registry-Based Preferences

     A preferences registry is a database that stores usage preference
     statements associated with both content identifiers and a means of
     identifying the declaring party.  Registry-based approaches might be
     applicable in certain contexts, particularly where embedding is
     impractical or unavailable.  Additionally, a registry might enable
     persistent association of preferences across distribution channels.






  Illyes & Thomson           Expires 1 May 2026                   [Page 4]


  Internet-Draft          AI Preference Attachment            October 2025


  1.4.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  2.  HTTP Content-Usage Header Field

     The Content-Usage field is a structured field dictionary, as defined
     in Section 3.2 of [FIELDS].  This field follows the vocabulary and
     processing rules in [VOCAB].

     This field indicates usage preferences regarding the content of the
     HTTP message.  That is, the field is representation metadata
     (Section 8.2 of [HTTP]) that applies the representation data
     (Section 8.1 of [HTTP]).  Informally, usage preferences apply to the
     content of a message, not the resource.

     Servers MUST retain any preferences associated with a request if the
     content of that request is used to answer later requests.  For
     example, the content of a PUT request that is used to answer
     subsequent GET requests.  Note that servers that have not been
     updated to understand this field will not comply with this
     requirement.

     The Content-Usage field does not have any special effect on caching.

  3.  Robots Exclusion Protocol Content-Usage Rule

     The core function of Robots Exclusion Protocol format [ROBOTS] (or
     the "robots.txt" file) is to describe the expectations of the server
     operator about which paths can be crawled.  This document adds a new
     rule that associates usage preferences with different paths.  This
     new rule applies to any paths that can be crawled; paths that cannot
     be crawled have no associated usage preferences.

     A Content-Usage rule is added to the set of potential rules that can
     be included in a Group for "robots.txt".

     The rule ABNF pattern from Section 2.2 of [ROBOTS] is extended as
     shown in Figure 1.








  Illyes & Thomson           Expires 1 May 2026                   [Page 5]


  Internet-Draft          AI Preference Attachment            October 2025


     rule =/ content-usage

     content-usage = *WS "content-usage" *WS ":" *WS
                     [ path-pattern 1*WS ] usage-pref EOL
     usage-pref    = <usage preference vocabulary from [VOCAB]>

                       Figure 1: Extended robots.txt ABNF

     Each group contains zero or more Content-Usage rules.  Each Content-
     Usage rule consists of a path and a usage preference.  The path might
     be absent or empty; if a path present, a SP or HTAB separates it from
     the usage preference.

     Note that the statement of preference encoding does not use an ABNF
     definition, relying instead on the definitions in [FIELDS].

  3.1.  Content-Usage Rule Semantics

     Each group in the file applies to a set of crawlers, identified by
     product token as defined in Section 2.2.1 of [ROBOTS].  The Allow and
     Disallow rules determine what resources can be crawled, using the
     rule that has the longest matching path prefix, as defined in
     Section 2.2.2 of [ROBOTS].

     This creates a two-stage arrangement that distinguishes acquisition
     and usage.  Acquisition relies on Allow/Disallow rules; usage
     preference relies on Content-Usage rules.

     Any Content-Usage rules determine the usage preferences for resources
     using the same path prefix matching rules as defined for Allow and
     Disallow.  That is, the path prefix length is determined by counting
     the number of bytes in the encoded path.

     Usage preferences apply only to those resources that can be crawled
     according to Allow/Disallow rules; no preferences are implied for
     resources that are disallowed.

     Paths specified for Content-Usage rules use the same percent-encoding
     rules as used for Allow/Disallow rules, as defined in Section 2.1 of
     [URI].  In particular, SP (U+20) and HTAB (U+09) characters need to
     be replaced with "%20" and "%09" respectively.

     The ordering of rules in a group carries no semantics.  Thus,
     Content-Usage rules can be interleaved with Allow and Disallow rules.







  Illyes & Thomson           Expires 1 May 2026                   [Page 6]


  Internet-Draft          AI Preference Attachment            October 2025


     If there are Content-Usage rules that have identical paths and
     conflicting usage preferences, these preferences apply separately
     according to the process defined in Section 7.1 of [VOCAB].  Note
     that this differs from the Allow/Disallow rules, where a conflict
     leads to the more permissive option, allowing crawling.

     A crawlers can cache a "robots.txt" file for up to 24 hours,
     following HTTP Cache-Control semantics defined in [HTTP-CACHE]; see
     Section 2.4 of [ROBOTS] for details.  Updates to preferences within
     the period that a file is cached might not be visible.

  3.2.  Processing Content-Usage Rules

     To process a Content-Usage rule, a parser identifies lines with the
     "Content-Usage" label.  This requires that SP and HTAB characters are
     ignored, before and after the label, in addition to before and after
     the COLON (":", U+3A) separator.

     The remainder of the line - up to either the first CR (U+0D), LF
     (U+0A), or octothorpe ("#", U+23) - is the rule value.

     The first character of the rule value will be "/" (U+2F) if a non-
     empty path is specified.  Paths always start with a "/" character, so
     a rule value that starts with any other character indicates that the
     path is absent.

     If a path is specified, the path ends immediately before the first SP
     (U+20) or HTAB ("U+09") character.  The remainder of the rule value
     is the statement of preference.  If a path is absent, the entire rule
     value is the statement of preference.

     The usage preference is encoded using the exemplary format defined in
     Section 6 of [VOCAB].  The parsing and processing rules from Sections
     6 and 7 of [VOCAB] apply.

     Note that a statement of preference is processed as a sequence of
     bytes, rather than Unicode text; see Section 6.3 of [VOCAB].

  3.3.  When Preferences Apply

     A crawler that fetches resources uses the copy of "robots.txt" that
     is current at the time of the fetch to determine which usage
     preferences apply to those resources.  Section 2.4 of [ROBOTS]
     defines how a "robots.txt" file can be cached.







  Illyes & Thomson           Expires 1 May 2026                   [Page 7]


  Internet-Draft          AI Preference Attachment            October 2025


     This means that updates to "robots.txt" do not retroactively apply to
     resources.  Changes to "robots.txt" that affect usage preferences
     therefore only apply after a crawler has retrieved the updated
     "robots.txt" and subsequently retrieved the affected resource again.

  3.4.  Example

     Figure 2 shows a simple "robots.txt" document.

     User-Agent: *
     Allow: /
     Disallow: /never/
     Content-Usage: train-ai=n
     Content-Usage: /ai-ok/ train-ai=y

     User-Agent: ExampleBot
     Allow: /
     Content-Usage: train-ai=y

                       Figure 2: Example robots.txt file

     A crawler that identifies as "ExampleBot" uses the second group.
     That crawler would be able to obtain all content and apply usage
     preferences of "ai=y" as defined in [VOCAB].

     All other crawlers use the first group.  This allows crawling of all
     content other than resources under "/never/".  Of those resources,
     those under "/ai-ok/" have an associated usage preference of "train-
     ai=y" and all other resources have a usage preference of "train-
     ai=n".

                  +=============+=======+==================+
                  | Path        | Crawl | Usage Preference |
                  +=============+=======+==================+
                  | /test       |  yes  | train-ai=n       |
                  +-------------+-------+------------------+
                  | /never/test |   no  | N/A              |
                  +-------------+-------+------------------+
                  | /ai-ok/test |  yes  | train-ai=y       |
                  +-------------+-------+------------------+

                     Table 1: Sample of usage preferences
                             for different paths








  Illyes & Thomson           Expires 1 May 2026                   [Page 8]


  Internet-Draft          AI Preference Attachment            October 2025


  4.  Security Considerations

     Processing usage preferences involves the parsing of text that is
     produced by potential adversaries.  Different guidelines for robust
     parsing can be found in Section 6 of [FIELDS] and Section 17 of
     [HTTP].

     Section 3 of [ROBOTS] describes security considerations for
     "robots.txt".  A "robots.txt" file can be up to 500KiB of text.  This
     specification does not increase this limit.

  5.  IANA Considerations

     The Content-Usage HTTP header field defined in Section 2 is added to
     the "HTTP Field Name" registry established in Section 18.4 of [HTTP]:

     Field Name:  Content-Usage
     Status:  permanent
     Structured Type:  Dictionary
     Reference:  Section 2
     Comments:  None

  6.  References

  6.1.  Normative References

     [FIELDS]   Nottingham, M. and P. Kamp, "Structured Field Values for
                HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
                <https://www.rfc-editor.org/rfc/rfc9651>.

     [HTTP]     Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Semantics", STD 97, RFC 9110,
                DOI 10.17487/RFC9110, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9110>.

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

     [ROBOTS]   Koster, M., Illyes, G., Zeller, H., and L. Sassman,
                "Robots Exclusion Protocol", RFC 9309,
                DOI 10.17487/RFC9309, September 2022,
                <https://www.rfc-editor.org/rfc/rfc9309>.



  Illyes & Thomson           Expires 1 May 2026                   [Page 9]


  Internet-Draft          AI Preference Attachment            October 2025


     [URI]      Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
                Resource Identifier (URI): Generic Syntax", STD 66,
                RFC 3986, DOI 10.17487/RFC3986, January 2005,
                <https://www.rfc-editor.org/rfc/rfc3986>.

     [VOCAB]    Keller, P. and M. Thomson, Ed., "A Vocabulary For
                Expressing AI Usage Preferences", Work in Progress,
                Internet-Draft, draft-ietf-aipref-vocab-04, 28 October
                2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
                aipref-vocab-04>.

  6.2.  Informative References

     [HTTP-CACHE]
                Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
                Ed., "HTTP Caching", STD 98, RFC 9111,
                DOI 10.17487/RFC9111, June 2022,
                <https://www.rfc-editor.org/rfc/rfc9111>.

  Authors' Addresses

     Gary Illyes
     Google
     Email: garyillyes@google.com


     Martin Thomson
     Mozilla
     Email: mt@lowentropy.net






















  Illyes & Thomson           Expires 1 May 2026                  [Page 10]


name: draft-madhavan-aipref-displaybasedpref
rev: 01
title: A Vocabulary for Controlling Usage of Content Collected by Search and AI Crawlers
time: 2025-09-22T23:43:28Z
group_uri: /api/v1/group/group/2440/
expires: 2026-03-25T07:19:01Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/134/"]
categories: ["Policy/governance", "ML traffic mgmt", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:13.454088+00:00
abstract:
  This document proposes a standardized vocabulary to express
     preferences for usage of digital content collected by Search and AI
     crawlers.  This vocabulary allows for the creation of structured
     declarations about restrictions or permissions for use of content
     retrieved by such systems.

full_text:
  AI Preferences                                               K. Madhavan
  Internet-Draft                                                  F. Canel
  Intended status: Informational                                 J. Gimbel
  Expires: 25 March 2026                                         S. Cooper
                                                     Microsoft Corporation
                                                         21 September 2025


  A Vocabulary for Controlling Usage of Content Collected by Search and AI
                                  Crawlers
                 draft-madhavan-aipref-displaybasedpref-01

  Abstract

     This document proposes a standardized vocabulary to express
     preferences for usage of digital content collected by Search and AI
     crawlers.  This vocabulary allows for the creation of structured
     declarations about restrictions or permissions for use of content
     retrieved by such systems.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://kmadhavan-
     msft.github.io/i-d-ietf-aipref-displaybasedpref/draft-madhavan-
     aipref-displaybasedpref.html.  Status information for this document
     may be found at https://datatracker.ietf.org/doc/draft-madhavan-
     aipref-displaybasedpref/.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (mailto:ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/kmadhavan-msft/i-d-ietf-aipref-displaybasedpref.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.




  Madhavan, et al.          Expires 25 March 2026                 [Page 1]


  Internet-Draft              displaybasedpref              September 2025


     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 25 March 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
     3.  Statements of Preference  . . . . . . . . . . . . . . . . . .   4
       3.1.  Conformance . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.  Applicability and Effect  . . . . . . . . . . . . . . . .   4
     4.  Vocabulary Definition . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Indexing and Retrieval  . . . . . . . . . . . . . . . . .   5
       4.2.  Display text  . . . . . . . . . . . . . . . . . . . . . .   5
       4.3.  Display text length . . . . . . . . . . . . . . . . . . .   5
       4.4.  Exact text match  . . . . . . . . . . . . . . . . . . . .   5
       4.5.  Image preview . . . . . . . . . . . . . . . . . . . . . .   6
       4.6.  Video preview . . . . . . . . . . . . . . . . . . . . . .   6
       4.7.  Generative AI training  . . . . . . . . . . . . . . . . .   6
     5.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  More specific instructions  . . . . . . . . . . . . . . .   6
       5.2.  Usage category labels . . . . . . . . . . . . . . . . . .   7
       5.3.  Consulting a Preference Expression  . . . . . . . . . . .   7
       5.4.  Combining Preferences . . . . . . . . . . . . . . . . . .   7
     6.  Applicability and Legal Effect  . . . . . . . . . . . . . . .   8
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.  Addendum - Explanatory Note . . . . . . . . . . . . . . . . .   8
     9.  Normative References  . . . . . . . . . . . . . . . . . . . .  10
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10




  Madhavan, et al.          Expires 25 March 2026                 [Page 2]


  Internet-Draft              displaybasedpref              September 2025


  1.  Introduction

     This document defines a common vocabulary of terms for search and AI
     systems that process digital content.  The primary purpose of this
     vocabulary is to enable machine-readable expressions of preferences
     about using digital content collected by Search and AI crawlers.

     The terms defined by the vocabulary can be used to describe, in a
     standardized way, the types of uses that a declaring party may wish
     to explicitly restrict or allow.  Preferences are then expressed as a
     grant or denial of permission concerning each of the types of use
     defined in the vocabulary.  This ensures that preferences can be
     communicated, processed, and stored in a consistent and interoperable
     manner.

     The vocabulary or the preferences that might be expressed do not
     proscribe how automated processing systems obtain or act on
     preferences.  Separate documents will describe how preferences might
     be associated with digital content.  It is designed to ensure that
     preference information can be exchanged between different systems and
     consistently understood.  A reader will also find that this document
     identifies existing implementations of certain vocabulary elements,
     helping readers connect these concepts to current preferences
     supported by most search engines and AI solutions.  The authors
     anticipate removing the references to existing implementations in the
     final version.

     Expressing preferences is without prejudice to applicable laws
     including the applicability of exceptions and limitations to
     copyright.

  2.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

     This document uses the following terms:

     Crawler:  A crawler is an automated program that scans the web,
        collecting content (web pages, images, documents etc.) or
        availability status per URI scanned.







  Madhavan, et al.          Expires 25 March 2026                 [Page 3]


  Internet-Draft              displaybasedpref              September 2025


  3.  Statements of Preference

     The vocabulary is a set of categories, each of which is defined to
     cover a class of usage for digital content.  The section on Section 4
     defines these categories in more detail.

     A statement of preference is made about a specific digital content.
     Statements of preferences can assign preferences to each of the
     categories of use in the vocabulary.

     A statement of preferences can express preferences about some, all,
     or none of the categories from the vocabulary.  This can mean that no
     preference is expressed for a given usage category.

     In the absence of a statement of preference, no preference is set.

  3.1.  Conformance

     TODO Conformance

  3.2.  Applicability and Effect

     This specification provides a set of definitions for different
     categories of use based on expressed display preferences.

     This specification does not provide any enforcement mechanism for
     those preferences, and conformance to it does not encompass whether
     preferences are actually respected during data processing.

     Preferences do not themselves create rights or prohibitions, either
     in the positive or the negative.  Other mechanisms—technical, legal,
     contractual, or otherwise—might enforce stated preferences and
     thereby determine the consequences of following or not following a
     stated preference.

     An entity that receives usage preferences MAY choose to respect those
     preferences it has discovered, according to an understanding of how
     the asset is used, how that usage corresponds to the usage categories
     where preferences have been stated, and the applicable legal context.

     Usage preferences can be ignored due to express agreements between
     relevant parties, explicit provisions of law, or the exercise of
     discretion in situations where widely recognized priorities justify
     doing so.  Priorities that could justify ignoring preferences include
     - but are not limited to - free expression, safety, education,
     scholarship, research, preservation, interoperability, and
     accessibility.




  Madhavan, et al.          Expires 25 March 2026                 [Page 4]


  Internet-Draft              displaybasedpref              September 2025


     Because enforcement is not provided by this specification, the
     consequences of ignoring preferences could vary depending upon how a
     given legal jurisdiction recognizes preferences.

  4.  Vocabulary Definition

     The following definitions apply to content collected by search and AI
     crawlers.  It does not include user-initiated access of content.  All
     these categories apply independently of each other with the most
     restrictive taking precedence in case all/some categories are
     present.

  4.1.  Indexing and Retrieval

     The act of allowing or disallowing content collected by web crawlers
     from being indexed or retrieved for purposes of display.  Such
     preference mechanism can also be applied for cases where digital
     content is not accessible.  In existing implementations, access
     preferences are typically expressed via the NOINDEX statement set in
     HTTP header or meta tags.

  4.2.  Display text

     The act of allowing or disallowing a reproduction of text content
     collected by a web crawler, except for the title if specified, from
     the whole or parts of the content to display portions of that
     content.  In existing implementations preference on which text can be
     used for caption are expressed via the NOSNIPPET statement set in
     http header, HTML meta tags, or HTML tags properties (data-
     nosnippet).

  4.3.  Display text length

     The act of limiting the number of characters as a textual display
     from content collected by a web crawler.  In existing implementations
     quotation length preferences are expressed via the max-snippet
     statement set in http header or HTML robots meta tags.

  4.4.  Exact text match

     The act of limiting text content to only an exact match if displaying
     text content from the document.  If this preference is present, text
     content must be quoted as is or use avoided and an explicit link back
     to the source of the document used in that instance.  One example of
     existing implementation of text quotation preferences is notranslate.






  Madhavan, et al.          Expires 25 March 2026                 [Page 5]


  Internet-Draft              displaybasedpref              September 2025


  4.5.  Image preview

     The act of limiting usage and size of images.  In existing
     implementations image preview preferences are typically expressed via
     the max-image-preview statement set in http header or HTML meta tags.

  4.6.  Video preview

     The act of limiting usage and length of videos.  In existing
     implementations video preview preferences are typically expressed via
     the max-video-preview statement set in http header or HTML robots
     meta tags.

  4.7.  Generative AI training

     The act of using content in training general purpose AI models that
     have the intent to generate text, images or other forms of synthetic
     content, or the act of training more specialized AI models that have
     the purpose of generating text, images or other forms of synthetic
     content.  In existing implementations preferences are communicated
     via robots.txt or via http header or HTML robots meta tags.

  5.  Usage

     The vocabulary is used by referencing the terms defined in the
     section on Section 4, directly or via mappings, in accordance with
     how they are defined in this document.

  5.1.  More specific instructions

     A recipient of a statement of preferences that follows this model
     might receive more specific instructions in two ways:  Extensions to
        the vocabulary might define more specific categories of usage.
        Preferences about more specific categories override those of any
        more general category.

        Statements of preferences are general purpose, machine-readable
        statements that cannot override contractual agreements or more
        specific statements.

     For instance, a statement of preferences might indicate that the use
     of a digital content is disallowed for Generative AI Training.  If
     arrangements, such as legal or business agreements, exist that
     explicitly permit the use of that digital content, those arrangements
     are likely to apply, unless the terms of the arrangement explicitly
     say otherwise.





  Madhavan, et al.          Expires 25 March 2026                 [Page 6]


  Internet-Draft              displaybasedpref              September 2025


  5.2.  Usage category labels

     Each usage category in the Section 4 is mapped to a short textual
     label.  The table below (Table 1) tabulates this mapping.

         +========================+===================+=============+
         | Category               | Label             | Reference   |
         +========================+===================+=============+
         | Indexing and retrieval | index             | Section 4.1 |
         +------------------------+-------------------+-------------+
         | Display text           | display-text      | Section 4.2 |
         +------------------------+-------------------+-------------+
         | Display text length    | max-text-length   | Section 4.3 |
         +------------------------+-------------------+-------------+
         | Exact text match       | match-text        | Section 4.4 |
         +------------------------+-------------------+-------------+
         | Image preview          | max-image-preview | Section 4.5 |
         +------------------------+-------------------+-------------+
         | Video preview          | max-video-preview | Section 4.6 |
         +------------------------+-------------------+-------------+
         | Generative AI training | train-genAI       | Section 4.7 |
         +------------------------+-------------------+-------------+

                        Table 1: Usage Category Labels

     An important note about this process and format is that, if the same
     key appears multiple times, only the last value is taken.  This means
     that duplicating the same key could result in unexpected outcomes.

  5.3.  Consulting a Preference Expression

     A single preference expression can be evaluated for a usage
     category as follows:  If the expression contains an explicit
        preference, that is the result.

        Otherwise, no preference is expressed.

  5.4.  Combining Preferences

     The application might have multiple preference expressions, obtained
     using different methods.

     If multiple preference expressions are active, all preference
     expressions are consulted as described in the section on
     Applicability and Legal Effect (Section 6).  This might result in
     conflicting answers.





  Madhavan, et al.          Expires 25 March 2026                 [Page 7]


  Internet-Draft              displaybasedpref              September 2025


     Absent some other means of resolving conflicts, the following
     process applies to each usage category:  If any preference expression
        indicates that the usage is restricted, the result is that the
        usage is restricted.

        Otherwise, if any preference allows the usage, the result is that
        the usage is allowed.

        Otherwise, no preference is set.

     This process ensures that the most restrictive preference applies.

  6.  Applicability and Legal Effect

     TODO

  7.  IANA Considerations

     This document has no IANA actions.

  8.  Addendum - Explanatory Note

     +=============+============+========================================+
     | Category    | Search     | AI Tool Experiences (such as Chat      |
     |             | Experience | experience) if preference set to       |
     |             | if         | disallowed                             |
     |             | preference |                                        |
     |             | set to     |                                        |
     |             | disallowed |                                        |
     +=============+============+========================================+
     | *Indexing   | Content is | Content may not be used or linked in   |
     | and         | not used   | response to a user query.              |
     | Retrieval*  | or linked  |                                        |
     |             | in         | Eg: Response in Copilot to the         |
     |             | response   | query, “Tell me what the mayor of SF   |
     |             | to a user  | said last night at city hall?” may     |
     |             | search     | not retrieve and use a relevant SF     |
     |             | query.     | Chronicle article to inform a user     |
     |             |            | response if this preference is set     |
     |             |            | to not allowed.                        |
     +-------------+------------+----------------------------------------+
     | *Display    | When       | Content cannot be used as a direct     |
     | Text*       | content is | input to generate an AI experience     |
     |             | shown in   | (such as an AI summary or overview)    |
     |             | response   | in response to a user query.  When     |
     |             | to a user  | content is shown in response to a      |
     |             | query,     | user query, only the title (if         |
     |             | only the   | specified) and URL may be displayed.   |



  Madhavan, et al.          Expires 25 March 2026                 [Page 8]


  Internet-Draft              displaybasedpref              September 2025


     |             | title (if  |                                        |
     |             | specified) | Eg: Response in Copilot to the         |
     |             | and URL.   | query, “Tell me what the mayor of SF   |
     |             |            | said last night at city hall?” may     |
     |             |            | only display the title and URL to a    |
     |             |            | SF Chronicle article if that article   |
     |             |            | is delivered in the response and it    |
     |             |            | will not serve as a direct input for   |
     |             |            | grounding, provided the whole          |
     |             |            | document is set to no display.         |
     +-------------+------------+----------------------------------------+
     | *Display    | Any        | Any display that includes a portion    |
     | Text        | display    | of the content must comply with the    |
     | Length*     | that       | specified character limit.             |
     |             | includes a |                                        |
     |             | portion of | Eg: Response in Copilot to the         |
     |             | the        | query, “Tell me what the mayor of SF   |
     |             | content    | said last night at city hall?” may     |
     |             | must       | use a SF Chronicle article for         |
     |             | comply     | grounding purposes to generate a       |
     |             | with the   | response, but any passage of the       |
     |             | specified  | article that is included as part of    |
     |             | character  | that response must comply with any     |
     |             | limit.     | established character limit.  The      |
     |             |            | response may go beyond the passage     |
     |             |            | from the content and include other     |
     |             |            | statements or information – whether    |
     |             |            | observations derived from examining    |
     |             |            | the article or not.                    |
     +-------------+------------+----------------------------------------+
     | *Exact Text | Any        | Any display that includes a portion    |
     | Match*      | display    | of the content must comply with the    |
     |             | that       | specified character limit.             |
     |             | includes a |                                        |
     |             | portion of | Eg: Response in Copilot to the         |
     |             | the        | query, “Tell me what the mayor of SF   |
     |             | content    | said last night at city hall?” may     |
     |             | must only  | use a SF Chronicle article for         |
     |             | present    | grounding purposes to generate a       |
     |             | the        | response, but any passage of the       |
     |             | designated | article that is included as part of    |
     |             | portions   | that response must only include        |
     |             | of the     | characters from the designated         |
     |             | content.   | portion of the content.                |
     +-------------+------------+----------------------------------------+
     | *Generative | Any text   | Any text included cannot be used for   |
     | AI          | included   | training of Generative AI models.      |
     | Training*   | cannot be  |                                        |



  Madhavan, et al.          Expires 25 March 2026                 [Page 9]


  Internet-Draft              displaybasedpref              September 2025


     |             | used for   |                                        |
     |             | training   |                                        |
     |             | of         |                                        |
     |             | Generative |                                        |
     |             | AI models. |                                        |
     +-------------+------------+----------------------------------------+

                 Table 2: Search and AI Tool Behavior Examples

  9.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  Acknowledgments

     TODO

  Authors' Addresses

     K. Madhavan
     Microsoft Corporation
     Email: krishna.madhavan@microsoft.com


     F. Canel
     Microsoft Corporation
     Email: fabrice.canel@microsoft.com


     J. Gimbel
     Microsoft Corporation
     Email: jordangimbel@microsoft.com


     S. Cooper
     Microsoft Corporation
     Email: sonia.cooper@skype.net







  Madhavan, et al.          Expires 25 March 2026                [Page 10]


name: draft-illyes-aipref-jafar
rev: 00
title: A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients
time: 2025-09-30T17:16:07Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-03T17:16:07Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Agent identity/auth", "ML traffic mgmt", "Data formats/interop"]
tags: []
fetched_at: 2026-03-03T15:50:13.454090+00:00
abstract:
  This document defines a standardized JSON format for automated HTTP
     client (e.g., web crawlers, AI bots) operators to disclose their IP
     address ranges publicly.  A consistent, machine-readable format for
     IP range publication simplifies the task of identifying and verifying
     legitimate automated traffic, thereby decreasing maintenance load on
     website operators while reducing the risk of inadvertently blocking
     beneficial clients.  This specification codifies and extends common
     existing practices to provide a simple yet extensible format that
     accommodates a variety of use cases.

full_text:
  AI Preferences                                                 G. Illyes
  Internet-Draft                                               Independent
  Intended status: Informational                         30 September 2025
  Expires: 3 April 2026


   A JSON-Based Format for Publishing IP Ranges of Automated HTTP Clients
                        draft-illyes-aipref-jafar-00

  Abstract

     This document defines a standardized JSON format for automated HTTP
     client (e.g., web crawlers, AI bots) operators to disclose their IP
     address ranges publicly.  A consistent, machine-readable format for
     IP range publication simplifies the task of identifying and verifying
     legitimate automated traffic, thereby decreasing maintenance load on
     website operators while reducing the risk of inadvertently blocking
     beneficial clients.  This specification codifies and extends common
     existing practices to provide a simple yet extensible format that
     accommodates a variety of use cases.

  Discussion Venues

     This note is to be removed before publishing as an RFC.

     Discussion of this document takes place on the AI Preferences Working
     Group mailing list (ai-control@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/ai-control/.

     Source for this draft and an issue tracker can be found at
     https://github.com/garyillyes/jafar.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."

     This Internet-Draft will expire on 3 April 2026.



  Illyes                    Expires 3 April 2026                  [Page 1]


  Internet-Draft                    JAFAR                   September 2025


  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.  Format  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.  Top-Level Object Definition . . . . . . . . . . . . . . .   3
       2.2.  The prefixes Array  . . . . . . . . . . . . . . . . . . .   4
       2.3.  The Prefix Object . . . . . . . . . . . . . . . . . . . .   4
     3.  Processing and Consumption Rules  . . . . . . . . . . . . . .   5
       3.1.  Fetching and Caching  . . . . . . . . . . . . . . . . . .   5
       3.2.  Handling Format Versioning  . . . . . . . . . . . . . . .   6
       3.3.  Prefix Aggregation and Specificity  . . . . . . . . . . .   6
     4.  Use Cases and Examples  . . . . . . . . . . . . . . . . . . .   6
       4.1.  Example 1: Basic Publication  . . . . . . . . . . . . . .   7
       4.2.  Example 2: Advanced Publication with Multiple Services  .   7
       4.3.  Example 3: Aggregated Publication by a Third Party  . . .   7
     5.  Conventions and Definitions . . . . . . . . . . . . . . . . .   7
     6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
     8.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

  1.  Introduction

     This document specifies a data format using the JavaScript Object
     Notation (JSON).  It is intended for the publication of IP address
     ranges associated with automated HTTP clients.  The scope of this
     specification is limited to the syntax and semantics of the JSON file
     itself.  It does not specify the transport mechanism for retrieving
     the file.  It also does not prescribe specific policies for how
     consumers should use the data (e.g., allowlisting, rate-limiting, or
     monitoring).  This format is intended to complement, not replace,
     other established methods for crawler verification.  Techniques such
     as forward-confirmed reverse DNS (FCrDNS) lookups remain a vital part
     of a comprehensive verification strategy.  This specification
     provides a scalable, machine-readable component that can be
     integrated into a multi-layered verification process.



  Illyes                    Expires 3 April 2026                  [Page 2]


  Internet-Draft                    JAFAR                   September 2025


  2.  Format

  2.1.  Top-Level Object Definition

     An IP range publication file MUST be a single JSON object.  The text
     encoding of the file MUST be UTF-8.  This top-level object serves as
     the root container for essential metadata and the list of IP
     prefixes.

     The top-level object contains the fields defined in Table 1.

     +===============+========+=============+===========================+
     | Field Name    | Type   | Requirement | Description               |
     +===============+========+=============+===========================+
     | formatVersion | String | MUST        | The version of this       |
     |               |        |             | specification that the    |
     |               |        |             | file conforms to,         |
     |               |        |             | represented as a string   |
     |               |        |             | in "major.minor" format   |
     |               |        |             | (e.g., "1.0").  Consumers |
     |               |        |             | MUST use this to handle   |
     |               |        |             | potential future breaking |
     |               |        |             | changes.  See Section 3.2 |
     |               |        |             | for processing rules.     |
     +---------------+--------+-------------+---------------------------+
     | synctoken     | String | MUST        | An opaque synchronization |
     |               |        |             | token that changes        |
     |               |        |             | whenever there is a       |
     |               |        |             | change to any metadata    |
     |               |        |             | associated with one or    |
     |               |        |             | more prefixes.            |
     +---------------+--------+-------------+---------------------------+
     | creationTime  | String | MUST        | An ISO 8601 timestamp in  |
     |               |        |             | the "Z" timezone (UTC)    |
     |               |        |             | indicating when the file  |
     |               |        |             | was generated (e.g.,      |
     |               |        |             | "2025-08-15T14:30:00Z").  |
     +---------------+--------+-------------+---------------------------+
     | notes         | String | OPTIONAL    | A human-readable string   |
     |               |        |             | containing any relevant   |
     |               |        |             | notes, disclaimers, or    |
     |               |        |             | comments from the         |
     |               |        |             | publisher.  This can be   |
     |               |        |             | used to provide context   |
     |               |        |             | that is not captured by   |
     |               |        |             | the structured data.      |
     +---------------+--------+-------------+---------------------------+
     | prefixes      | Array  | MUST        | An array of Prefix        |



  Illyes                    Expires 3 April 2026                  [Page 3]


  Internet-Draft                    JAFAR                   September 2025


     |               |        |             | Objects, as defined in    |
     |               |        |             | Section 2.3.  Each object |
     |               |        |             | in the array describes an |
     |               |        |             | IPv4 or IPv6 address      |
     |               |        |             | range.  This array MAY be |
     |               |        |             | empty if the publisher    |
     |               |        |             | currently has no active   |
     |               |        |             | IP ranges to declare.     |
     +---------------+--------+-------------+---------------------------+

                                   Table 1

  2.2.  The prefixes Array

     The prefixes member of the top-level object MUST contain an array of
     JSON objects.  Each of these objects is a Prefix Object, as defined
     in Section 2.3.

     To simplify implementation for consumers, there MUST be a single,
     unified array for both IPv4 and IPv6 prefixes.

  2.3.  The Prefix Object

     Each object within the prefixes array represents a single IP address
     range and its associated metadata.

     A Prefix Object MUST contain exactly one of either the ipv4Prefix
     field or the ipv6Prefix field.  An object containing both or neither
     of these fields is invalid and MUST be ignored by consumers.  The
     fields are defined in Table 2.





















  Illyes                    Expires 3 April 2026                  [Page 4]


  Internet-Draft                    JAFAR                   September 2025


     +============+========+=============+===============================+
     | Field Name | Type   | Requirement | Description                   |
     +============+========+=============+===============================+
     | ipv4Prefix | String | CONDITIONAL | The IPv4 address range in     |
     |            |        |             | Classless Inter-Domain        |
     |            |        |             | Routing (CIDR) notation       |
     |            |        |             | (e.g., "66.249.64.0/20").     |
     |            |        |             | This field MUST be            |
     |            |        |             | present if the ipv6Prefix     |
     |            |        |             | field is absent.              |
     +------------+--------+-------------+-------------------------------+
     | ipv6Prefix | String | CONDITIONAL | The IPv6 address range in     |
     |            |        |             | CIDR notation (e.g.,          |
     |            |        |             | "2001:4860:4000::/36").       |
     |            |        |             | This field MUST be            |
     |            |        |             | present if the ipv4Prefix     |
     |            |        |             | field is absent.              |
     +------------+--------+-------------+-------------------------------+
     | service    | String | OPTIONAL    | A publisher-defined,          |
     |            |        |             | case-sensitive string         |
     |            |        |             | that identifies the           |
     |            |        |             | specific service, bot, or     |
     |            |        |             | purpose associated with       |
     |            |        |             | this prefix.  Examples        |
     |            |        |             | could include "Bingbot",      |
     |            |        |             | "AdsBot-Google".  This        |
     |            |        |             | allows consumers to apply     |
     |            |        |             | more granular policies.       |
     +------------+--------+-------------+-------------------------------+

                                    Table 2

  3.  Processing and Consumption Rules

  3.1.  Fetching and Caching

     Consumers SHOULD fetch the IP range publication file from a stable
     URL provided by the publisher in a machine readable format.  The file
     location MUST be disclosed by the publisher of the file in the page
     that describes the crawler.

     Publishers SHOULD update the file when there's any change to the
     prefixes or every 24 hours, even if the only update is to
     creationTime.  Consumers SHOULD implement a polling mechanism to
     check for updates at a reasonable interval, such as once every 24
     hours.  Consumers MUST NOT poll more frequently than once per hour
     unless explicitly permitted by the publisher's documentation or HTTP
     caching headers.



  Illyes                    Expires 3 April 2026                  [Page 5]


  Internet-Draft                    JAFAR                   September 2025


     To minimize server load for the publisher and reduce unnecessary
     bandwidth usage for the consumer, consumers MUST respect standard
     HTTP caching headers that may be present in the response, such as
     Cache-Control, ETag, and Last-Modified.  Publishers SHOULD provide
     these headers to facilitate efficient caching.

  3.2.  Handling Format Versioning

     To ensure long-term stability and allow for future evolution of this
     specification, consumers MUST inspect the formatVersion field in the
     top-level object of the file.  The version is expressed as
     "major.minor".

     *  Major Version Changes: A change in the major version number (e.g.,
        from "1.0" to "2.0") indicates a non-backwards compatible change
        to the specification.  If a consumer encounters a file with a
        major version number greater than the major version it is
        programmed to handle, the consumer MUST NOT attempt to parse the
        file.  It SHOULD treat this situation as an error and MAY continue
        to use its last known valid list until it can be updated to
        support the new version.  This prevents the misinterpretation of
        data from a significantly altered schema.

     *  Minor Version Changes: A change in the minor version number (e.g.,
        from "1.0" to "1.1") indicates the addition of new features or
        fields that are backward-compatible.  For example, a new OPTIONAL
        field might be added to the Prefix Object.  A consumer programmed
        to handle version "1.0" MUST be able to correctly parse a file
        with version "1.1".  The minor version number increases
        numerically independently of the major version number, for
        instance: 1.9 -> 1.10 -> 1.11.  The consumer MUST ignore any
        unrecognized fields or properties within the JSON objects.

  3.3.  Prefix Aggregation and Specificity

     A publication file MAY contain overlapping IP address ranges.  For
     instance, a publisher might list a broad range like 198.51.100.0/22
     with a generic service tag, and also list a more specific range
     within it, such as 198.51.100.0/24, with a more specific service tag.

     When a consumer evaluates a specific IP address against the list, it
     MAY match multiple Prefix Objects.  In such cases, the consumer's
     logic SHOULD use the data from the Prefix Object with the most
     specific CIDR range (i.e., the one with the largest prefix length)
     for that IP address.

  4.  Use Cases and Examples




  Illyes                    Expires 3 April 2026                  [Page 6]


  Internet-Draft                    JAFAR                   September 2025


  4.1.  Example 1: Basic Publication

     This example demonstrates a minimal, valid file for a publisher with
     a single type of automated client.  It uses only the required fields,
     making it simple to generate and consume.

     { "formatVersion": "1.0", "creationTime": "2025-08-15T14:30:00Z",
     "prefixes": [ { "ipv4Prefix": "66.249.64.0/20" }, { "ipv4Prefix":
     "34.64.0.0/12" }, { "ipv6Prefix": "2001:4860:4000::/36" } ] }

  4.2.  Example 2: Advanced Publication with Multiple Services

     This example illustrates a more complex file from a large cloud
     provider that uses optional fields to provide richer context.  It
     differentiates between IP ranges used for a general web crawler, a
     specialized ads crawler, and a user-triggered fetching service.  This
     allows consumers to implement more granular access policies.

     { "formatVersion": "1.0", "creationTime": "2025-09-01T10:00:00Z",
     "notes": "IP ranges for ExampleCloud services.  For verification,
     FCrDNS is also recommended.", "Prefixes": "FILL OUT WITH EXAMPLE" }

  4.3.  Example 3: Aggregated Publication by a Third Party

     This example shows how a third-party security provider or an open-
     source project could aggregate IP lists from multiple publishers into
     a single file.  The service field is used to attribute each prefix to
     its original source, allowing consumers to apply policies based on
     the original publisher.  This reflects the use case of services that
     provide curated lists of known bots.

     { "formatVersion": "1.0", "creationTime": "2025-09-02T00:00:00Z",
     "notes": "Aggregated list of known good bots.  Data is updated daily
     from original publisher sources.", "Prefixes": FILL OUT WITH EXAMPLE
     }

  5.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in
     BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  6.  Security Considerations

     TODO Security




  Illyes                    Expires 3 April 2026                  [Page 7]


  Internet-Draft                    JAFAR                   September 2025


  7.  IANA Considerations

     This document has no IANA actions.

  8.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/rfc/rfc2119>.

     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

  Acknowledgments

     TODO acknowledge.

  Author's Address

     Gary Illyes
     Independent
     Email: synack@garyillyes.com



























  Illyes                    Expires 3 April 2026                  [Page 8]


name: draft-farzdusa-aipref-enduser
rev: 00
title: AI Preferences Signaling: End User Impact
time: 2025-11-27T04:36:55Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-31T04:36:55Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Policy/governance", "Human-agent interaction"]
tags: []
fetched_at: 2026-03-03T15:50:13.454093+00:00
abstract:
  Standards can have a major impact on end users across technological,
     legal, ethical, and governance dimensions, largely centering around
     access to information, control over their digital contributions, and
     data privacy.  The purpose of this Internet Draft is to document the
     potential impact of signaling AI preferences on end users other than
     publishers, and to suggest some principles for the ai-pref working
     group to consider when assessing proposed vocabulary and definitions
     IETF wishes to standardize for signaling.

full_text:
  AIPref                                                          F. Badii
  Internet-Draft                                            Digital Medusa
  Intended status: Informational                                 L. Bailey
  Expires: 30 May 2026                                    Internet Archive
                                                                   J. Levy
                                                          26 November 2025


                 AI Preferences Signaling: End User Impact
                      draft-farzdusa-aipref-enduser-00

  Abstract

     Standards can have a major impact on end users across technological,
     legal, ethical, and governance dimensions, largely centering around
     access to information, control over their digital contributions, and
     data privacy.  The purpose of this Internet Draft is to document the
     potential impact of signaling AI preferences on end users other than
     publishers, and to suggest some principles for the ai-pref working
     group to consider when assessing proposed vocabulary and definitions
     IETF wishes to standardize for signaling.

  About This Document

     This note is to be removed before publishing as an RFC.

     The latest revision of this draft can be found at https://farzaneh-
     unicode.github.io/enduser-AIpref/draft-farzdusa-aipref-enduser.html
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-farzdusa-aipref-enduser/.

     Source for this draft and an issue tracker can be found at
     https://github.com/Farzaneh-Unicode/enduser-AIpref.

  Status of This Memo

     This Internet-Draft is submitted in full conformance with the
     provisions of BCP 78 and BCP 79.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF).  Note that other groups may also distribute
     working documents as Internet-Drafts.  The list of current Internet-
     Drafts is at https://datatracker.ietf.org/drafts/current/.

     Internet-Drafts are draft documents valid for a maximum of six months
     and may be updated, replaced, or obsoleted by other documents at any
     time.  It is inappropriate to use Internet-Drafts as reference
     material or to cite them other than as "work in progress."



  Badii, et al.              Expires 30 May 2026                  [Page 1]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


     This Internet-Draft will expire on 30 May 2026.

  Copyright Notice

     Copyright (c) 2025 IETF Trust and the persons identified as the
     document authors.  All rights reserved.

     This document is subject to BCP 78 and the IETF Trust's Legal
     Provisions Relating to IETF Documents (https://trustee.ietf.org/
     license-info) in effect on the date of publication of this document.
     Please review these documents carefully, as they describe your rights
     and restrictions with respect to this document.  Code Components
     extracted from this document must include Revised BSD License text as
     described in Section 4.e of the Trust Legal Provisions and are
     provided without warranty as described in the Revised BSD License.

  Table of Contents

     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     2.  Who are the end users?  . . . . . . . . . . . . . . . . . . .   3
     3.  The IETF’s mandate and the Approach to Signaling AI
             Preferences . . . . . . . . . . . . . . . . . . . . . . .   4
     4.  The Right to Access Knowledge and Avoiding Internet
             Fragmentation . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Access to Information . . . . . . . . . . . . . . . . . .   5
       4.2.  Intellectual Property Overreach and Rights Delay  . . . .   5
       4.3.  Risk of Web Fragmentation . . . . . . . . . . . . . . . .   5
       4.4.  Impact on AI Tool Utility . . . . . . . . . . . . . . . .   6
       4.5.  Site operators don’t own everything on their website  . .   6
     5.  Impact on User Rights, Transformation, and Academic
             Research  . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.  Robots Rights to Read . . . . . . . . . . . . . . . . . .   6
       5.2.  Use in the public interest  . . . . . . . . . . . . . . .   6
     6.  Shortcomings of Restricting RAG and Inference . . . . . . . .   7
       6.1.  Collateral Damage to End Users and Beneficial
             Applications  . . . . . . . . . . . . . . . . . . . . . .   7
       6.2.  Risk to Automated Tools and Access to Knowledge (A2K) . .   7
       6.3.  Discouraging Personal Use of Automation . . . . . . . . .   7
       6.4.  Accessibility Concerns  . . . . . . . . . . . . . . . . .   8
       6.5.  Impact on Research and Flexibility  . . . . . . . . . . .   8
     7.  Technical and Definitional Instability  . . . . . . . . . . .   8
       7.1.  The Crawl Time vs. Inference  . . . . . . . . . . . . . .   8
       7.2.  Difficulty in Allowing Non-Commercial and Excluding
             Commercial Crawling . . . . . . . . . . . . . . . . . . .   8
       7.3.  Uncertainty in Definition . . . . . . . . . . . . . . . .   9
       7.4.  Asset level signaling . . . . . . . . . . . . . . . . . .   9
     8.  Case Studies  . . . . . . . . . . . . . . . . . . . . . . . .   9
       8.1.  Inhibition of Not-for-Profit Crawlers . . . . . . . . . .   9



  Badii, et al.              Expires 30 May 2026                  [Page 2]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


       8.2.  Opaque Robot Defenses . . . . . . . . . . . . . . . . . .   9
       8.3.  Collateral Damage to Beneficial Uses  . . . . . . . . . .   9
       8.4.  Threat to Public Archiving  . . . . . . . . . . . . . . .  10
       8.5.  Intermediaries Choosing for Smaller Site Operators  . . .  10
       8.6.  Platform Control over Creator Intent  . . . . . . . . . .  10
       8.7.  Creation of Quasi-IP Rights . . . . . . . . . . . . . . .  10
       8.8.  The Threat of Exclusionary Defaults . . . . . . . . . . .  10
     9.  The Impact on the Internet  . . . . . . . . . . . . . . . . .  11
     10. Proposed End User Impact Principles . . . . . . . . . . . . .  11
     11. Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     12. Conventions and Definitions . . . . . . . . . . . . . . . . .  12
     13. Security Considerations . . . . . . . . . . . . . . . . . . .  12
     14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
     15. Normative References  . . . . . . . . . . . . . . . . . . . .  12
     Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  13
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

  1.  Introduction

     As AI systems start becoming a primary way people access and interact
     with information online, mechanisms for signaling AI preferences risk
     shaping far more than technical coordination.  While the AI-Pref
     Working Group focuses on enabling content hosts to express their
     preferences, these signals operate at the protocol layer, where they
     can quietly restrict access, chill lawful uses, and unintentionally
     fragment the open web.  End users, understood broadly in RFC 8890 as
     the human beings whose activities Internet standards support, include
     not only publishers and AI developers but also researchers,
     educators, people with disabilities, small creators, and the global
     public.  Many of these communities rely on rights to access,
     transform, and analyze information that could be undermined if
     preference signaling is interpreted or implemented as a form of
     control.  This draft outlines the potential impact of AI signaling on
     end users and proposes principles to ensure that standardization
     preserves interoperability, openness, and user agency.

  2.  Who are the end users?

     Mark Nottingham the author of The Internet is for the End Users,
     proposes a definition for end users in RFC 8890: "end users" means
     human users whose activities IETF standards support, sometimes
     indirectly….End users are not necessarily a homogenous group; they
     might have different views of how the Internet should work and might
     occupy several roles, such as a seller, buyer, publisher, reader,
     service provider, and consumer.  An end user might browse the Web,
     monitor remote equipment, play a game, videoconference with
     colleagues, send messages to friends, or perform an operation in a
     remote surgery theater.  They might be "at the keyboard" or



  Badii, et al.              Expires 30 May 2026                  [Page 3]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


     represented by software indirectly (e.g., as a daemon)".

     This broad definition is especially useful to keep in mind as the
     outputs from the AI preferences working group are likely to have an
     impact on a broad range of end users.  The dominant voices in the AI-
     pref working group so far have been “publishers” and AI developers,
     each of which are a kind of end user.  Other end users’ rights,
     interests, and access have been discussed less frequently.  When
     rights and interests are discussed, in general the rights under
     consideration are those of Intellectual Property Rightsholders, while
     the discussions rarely mention other rightsholders, such as people
     with rights to access to knowledge and essential services, or
     interested parties.

     There is a need to ensure that property and economic interests are
     aligned with fundamental human rights, such as the right to freedom
     of opinion and expression under Article 19 of the Universal
     Declaration of Human Rights.  Intellectual-property and market-based
     mechanisms should function in a way that supports, rather than
     constrains, the free circulation of information and ideas.

     While AI Preference signaling mechanisms are intended to give content
     hosts (or site operators) a means to signal how content is used by AI
     systems, they can result in unintended consequences that
     disproportionately harm end users, including researchers, people with
     disabilities, and commercial and non-commercial actors, thereby
     undermining the open Internet.  Site operators may signal
     restrictions over content or uses that they do not have the legal
     right to control, such as text and data mining permitted under
     copyright exceptions, accessibility tools, public-domain materials,
     or facts and information not protected by intellectual property
     rights.  When interpreted strictly by AI systems, such signals can
     create a chilling effect: researchers, accessibility developers, and
     others may refrain from lawful uses simply because they believe the
     content is off-limits.  This misalignment between technical signals
     and actual rights risks fragmenting access to knowledge and
     undermining the open Internet.

  3.  The IETF’s mandate and the Approach to Signaling AI Preferences

     The IETF was never intended to serve as a forum for protecting
     business models from technological innovation or enforcing copyright
     regimes.  Its purpose is to maintain and advance the interoperability
     of the Internet, to ensure that diverse systems, services, and users
     can communicate seamlessly across technical and institutional
     boundaries.  A shift away from this focus risks turning what should
     be a technical coordination effort into a venue for regulating reuse
     at the protocol layer, well before any legal reasoning or due-process



  Badii, et al.              Expires 30 May 2026                  [Page 4]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


     safeguards can apply.  If the IETF shifts toward a regime that
     encourages blanket prohibitions on data processing, regardless of
     context, consequence, or user benefit, we risk hardcoding a “chilling
     effect” into the infrastructure of the web itself.  And unlike lawful
     reuses, which are typically adjudicated through downstream legal
     reasoning, signaling operates at the technical layer, where denial is
     fast, quiet, and hard to contest.

  4.  The Right to Access Knowledge and Avoiding Internet Fragmentation

     A major concern for end users is the potential restriction of access
     to information and essential services due to overly restrictive
     content signaling instituted by hosting platforms, creators and
     publishers.

  4.1.  Access to Information

     People globally are increasingly accessing essential services and
     knowledge through the Internet.  AI-enabled applications could
     potentially simplify access to knowledge and essential services
     provided online, such as healthcare and other services.  However, if
     signaling AI preferences reinforced by regulatory reference become
     too restrictive, it can have a chilling effect and the fundamental
     right to access information and essential services could be harmed.

  4.2.  Intellectual Property Overreach and Rights Delay

     Theorists of the Access to Knowledge (A2K) movement contend that
     current levels of Intellectual Property (IP) protection may be
     unbalanced regarding the right to access.  They argue that material
     interests are not simply equivalent to current IP provisions, and
     that "rights delayed are rights denied".  (Lea Shaver The Right to
     Science and Culture, 2010 Wis. L.  Rev. 121 (2010).

  4.3.  Risk of Web Fragmentation

     There is a tension between giving site operators and declarants
     (those who declare their preferences about AI data usage) granular
     control over content and maintaining an open Internet.  Implementing
     very restrictive mechanisms risks "building fortress walls around
     content" and sacrificing the open web, potentially throttling the
     future of knowledge and access to essential services.









  Badii, et al.              Expires 30 May 2026                  [Page 5]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


  4.4.  Impact on AI Tool Utility

     While large AI companies are the primary targets of restrictive
     preference signals, these controls can inadvertently restrict and
     harm end users who wish to use AI tools for common tasks like
     exploring content, summarizing, or translating documents or making
     services more accessible.  Setting a high bar for accessing and using
     information could negatively affect individual end users' ability to
     utilize these tools and overall experience when accessing the world
     wide web.  Ultimately, it is individual people who will pay the price
     for restricted access to AI tools, both financially and by IETF-
     endorsed limits on their ability to use AI to access the knowledge
     and information they seek.  Open source AI developers and others can
     also be disenfranchised if the preferences signals are not coherently
     implementable or if they have chilling effects.

  4.5.  Site operators don’t own everything on their website

     Any given web page has the technical capacity to contain content from
     a variety of different rightsholders.  A large platform can therefore
     contain content from millions, even billions, of different content
     creators.  Giving a website owner the ability to determine the AI
     preferences for potentially millions of different creators and their
     works risks centralizing a huge amount of control.

  5.  Impact on User Rights, Transformation, and Academic Research

     End users who are researchers are frequently hindered by licensing
     and contractual barriers, even when the underlying uses might be
     legally permissible under copyright law.

  5.1.  Robots Rights to Read

     Researchers and other end users face a tension when downloading and
     human (consumptive) reading is allowed, but machine (non-consumptive)
     reading is disallowed, leading to the slogan “let the robots read.”
     Robots are perhaps always the agents of human users and preventing
     them from reading could ultimately prevent the humans from access.

  5.2.  Use in the public interest

     The principle of allowing public interest uses of information has
     long supported knowledge production and freedom of expression.  These
     uses are without payment nor permission, rejecting the idea that
     access to information is "a privilege reserved for the well-behaved".
     In the AI-Pref discussions, many participants expressed a desire to
     differentiate between traditional search engine indexing—generally
     accepted as beneficial to the open web—and newer AI-enabled



  Badii, et al.              Expires 30 May 2026                  [Page 6]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


     summarization or answer generation.  Some content providers signaled
     that they may be open to appearing in classic search results but not
     in AI-driven outputs that repackage or synthesize their material.
     However, this signaling raises a deeper structural issue: by opting
     out, publishers and intellectual property rights holders and hosts
     effectively shift the burden of determining whether a use is
     permitted to the recipient of the signal.  While this may not be a
     significant obstacle for well-resourced actors like major platforms,
     it imposes disproportionate risks on small operators, open-source AI
     developers, and actors from the global majority, those who often lack
     the legal infrastructure, funding, or access to navigate complex
     copyright frameworks.

  6.  Shortcomings of Restricting RAG and Inference

     Restricting RAG and inference, uses that occur after the foundation
     model has been trained, is fundamentally challenging due to the fluid
     nature of these processes and the risk of unintended negative
     consequences for legitimate users and access to information.

  6.1.  Collateral Damage to End Users and Beneficial Applications

     One of the most significant shortcoming of restricting inference is
     the unintended curtailment of beneficial applications used everyday.

  6.2.  Risk to Automated Tools and Access to Knowledge (A2K)

     If restrictions on inference are applied too broadly, end users who
     wish to use AI tools for common tasks like discovering content,
     summarizing documents, or translation would be barred from doing so.
     This directly undermines the end user's right to access knowledge
     (A2K).

  6.3.  Discouraging Personal Use of Automation

     End users want to benefit from the efficiencies of automation, such
     as using bulk operations and automated search features, rather than
     having to rely solely on large, proprietary AI company tools.
     Placing the same restrictive bar on individual end users as on large
     AI developers for using information could negatively affect the
     ability of individuals to leverage these tools for personal or
     beneficial research purposes.









  Badii, et al.              Expires 30 May 2026                  [Page 7]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


  6.4.  Accessibility Concerns

     Overly restrictive inference controls, such as a complete opt-out of
     “all data mining, automation and processing”, carry the risk of
     affecting uses like spam filtering, harmful language detection, and
     accessibility tools.  For instance, if a tool that describes a
     website to a visually impaired user relies on inference, a broad
     restriction could prevent that legitimate use.

  6.5.  Impact on Research and Flexibility

     Researchers, when analyzing data, may be hindered if limitations
     block non-consumptive reading (TDM) but allow human reading.  The
     core issue remains that an overly restrictive environment risks
     constraining scholarship and academic communication.

  7.  Technical and Definitional Instability

     The attempt to restrict RAG/Inference runs into technical limitations
     regarding scope, authority, and implementation methods.

  7.1.  The Crawl Time vs. Inference

     Preference signals (like those in robots.txt or metadata) are
     available at crawl time, but they are often disassociated from the
     model when the content is actually used at inference time.  This
     could create mixed signals as to what the end user can do regarding
     the crawling vs inference and signaling about inference because of
     this time lag can create many problems for the end users, real time
     translation for example might not happen.

  7.2.  Difficulty in Allowing Non-Commercial and Excluding Commercial
        Crawling

     For a general-purpose foundational model (LLM), it is technically
     difficult to distinguish between commercial and non-commercial uses
     at either crawl or inference time.  Because models cannot selectively
     isolate or invoke portions of their training data based on the
     eventual use context, a blanket “No AI” or similar restrictive signal
     tends to apply universally — even to lawful, commercial and non-
     commercial, or public-interest uses.  This leaves developers and
     researchers with “unappealing choices,” such as omitting the data
     entirely or creating separate models for every potential use
     category, both of which are impractical and risk excluding socially
     beneficial applications.






  Badii, et al.              Expires 30 May 2026                  [Page 8]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


  7.3.  Uncertainty in Definition

     RAG is only one technique, and definitions of inference-time use are
     unstable.  The concept of "inference" is broad and covers a massive,
     conceptually fuzzy range of uses of material after training, making
     it difficult to develop a robust vocabulary term.  If standards focus
     too much on a specific technique like RAG, they risk becoming
     irrelevant as new techniques emerge.

  7.4.  Asset level signaling

     Inference is becoming increasingly local (e.g., self-hosted models or
     on-device processing).  Asset-level control or signaling could
     intervene with an individual’s device, and there might be attempts to
     ensure a user cannot override a "no inference" flag for personal use
     (like translating a document), which is highly problematic.

  8.  Case Studies

  8.1.  Inhibition of Not-for-Profit Crawlers

     Non-profit organizations dedicated to archiving and public benefit,
     such as the Common Crawl Foundation, the Internet Archive and Data
     Rescue Project, are often inadvertently blocked or disadvantaged by
     broad control mechanisms intended to stop commercial scraping.

  8.2.  Opaque Robot Defenses

     Modern “robot defenses” are increasingly used by websites to stop
     crawling instead of relying solely on the transparent robots.txt
     protocol.  Providers of these defenses sometimes treat legitimate
     archive crawlers, like Common Crawl’s CCBot, the same way as
     commercial bots crawling for specific AI companies.  This blocking
     process is considered opaque.

  8.3.  Collateral Damage to Beneficial Uses

     This conflation of uses often leads to "collateral damage" for non-AI
     uses, effectively "locking down the Web".  For example, the official
     2024 End of Term Archive has been inadvertently blocked from crawling
     some US government websites due to these defensive measures.










  Badii, et al.              Expires 30 May 2026                  [Page 9]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


  8.4.  Threat to Public Archiving

     Organizations providing vital public benefit, such as the Internet
     Archive's Wayback Machine, are constantly under threat because courts
     sometimes impose a duty to parse individualized, idiosyncratic Terms
     of Service (ToS) for every archived page.  Such enforcement would
     make the vital historical, academic, legal, and journalistic work
     provided by the Wayback Machine impossible.

  8.5.  Intermediaries Choosing for Smaller Site Operators

     A significant problem arising from this overreach is that creators
     and smaller site operators who wish to share their content for uses
     like AI training, or search indexing are often prevented from doing
     so because the hosting platform or site administrator chooses a
     restrictive standard for them by default.

  8.6.  Platform Control over Creator Intent

     Public websites, particularly those hosting user-generated content
     (UGC) like social media platforms, use broad Terms of Service (ToS)
     to assert extensive, contract-based control over content and data.
     If a site has content from many creators (e.g., social media
     platforms), the site administrator typically controls the location-
     based opt-out mechanisms (like robots.txt).  Consequently, the
     administrator "may not allow them [individual creators] to express
     their preferences fully, or at all".

  8.7.  Creation of Quasi-IP Rights

     Platforms use their ToS to create quasi-intellectual property rights
     intended to bind the public and impose constraints that stifle
     academic research and preservation, even over content they do not own
     the copyright to.

  8.8.  The Threat of Exclusionary Defaults

     When platforms implement restrictive measures (even if intended to be
     protective), they lock away valuable resources that could otherwise
     help the open web.  For instance, a valuable public-interest
     resource, such as a digital dictionary, could be blocked from all AI
     systems by the organizations hosting it, resulting in the resource
     being inaccessible to speakers, researchers, and language models that
     could otherwise preserve and revitalize the language.







  Badii, et al.              Expires 30 May 2026                 [Page 10]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


  9.  The Impact on the Internet

     Using Internet Society Internet Impact Assessment tool, we have done
     a brief Internet impact assessment on several concepts we have been
     discussing during the working group dialogues:

       +====================+=========================================+
       | Critical Property  | Potential Impact                        |
       | / Goal             |                                         |
       +====================+=========================================+
       | *CP1 – Accessible  | All-or-nothing AI-pref signals increase |
       | infrastructure*    | participation costs, especially for     |
       |                    | small/open-source actors.               |
       +--------------------+-----------------------------------------+
       | *CP2 –             | Broad bans reduce modular reuse (e.g.,  |
       | Interoperable      | summarization/translation), stifling    |
       | building blocks*   | recombination.                          |
       +--------------------+-----------------------------------------+
       | *CP3 –             | Platform-wide defaults override creator |
       | Decentralized      | intent; reduce autonomy in UGC          |
       | management*        | contexts.                               |
       +--------------------+-----------------------------------------+
       | *CP4 – Common      | No impact identified yet.               |
       | global             |                                         |
       | identifiers*       |                                         |
       +--------------------+-----------------------------------------+
       | *CP5 – Technology- | Banning “AI” as a category risks        |
       | neutral network*   | chilling general-purpose uses (e.g.,    |
       |                    | accessibility).                         |
       +--------------------+-----------------------------------------+

                                    Figure 1

  10.  Proposed End User Impact Principles

     To the greatest extent possible, the goal should be to keep public
     information public and to keep the open web open.  Vocabulary
     standardized by IETF should not unduly restrict end user access to
     and ability to use public knowledge and information.  Definitions
     should be clear and narrowly tailored to be fit for purpose, rather
     than vague and broad.  End users should be able to understand the
     definitions without having technical or legal expertise.  End users
     should be able to use general purpose, commercially available tools
     to accomplish their own lawful activities, regardless of preferences
     to the contrary.






  Badii, et al.              Expires 30 May 2026                 [Page 11]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


  11.  Conclusion

     AI Preference signaling, while conceived as a mechanism for
     expressing control and transparency over the use of online content,
     risks evolving into an instrument that fragments the open Internet
     and uses of information.  The IETF’s role has never been to protect
     business models from innovation or to enforce intellectual property
     regimes.  Its role is to ensure interoperability and resilience
     across technical systems.  When preference signaling becomes a
     vehicle for implementing legal or economic restrictions at the
     protocol layer, it moves the IETF into a domain of governance that
     undermines its core mission and values.

     End users, whether researchers, accessibility developers, educators,
     or ordinary participants in the digital commons, stand to lose most
     from these shifts.  Overly restrictive signaling can chill legitimate
     research, disable accessibility tools, and entrench barriers to
     knowledge that the Internet was designed to dismantle.  By conflating
     technical coordination with policy enforcement, we risk replacing
     openness and innovation with exclusion and opacity.

     The AI-Pref Working Group should therefore focus on preserving
     interoperability and user agency, ensuring that standards remain
     technology-neutral, modular, and open to innovation.

  12.  Conventions and Definitions

     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
     "OPTIONAL" in this document are to be interpreted as described in BCP
     14 [RFC2119] [RFC8174] when, and only when, they appear in all
     capitals, as shown here.

  13.  Security Considerations

     TODO Security

  14.  IANA Considerations

     This document has no IANA actions.

  15.  Normative References

     [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119,
                DOI 10.17487/RFC2119, March 1997,
                <https://www.rfc-editor.org/info/rfc2119>.




  Badii, et al.              Expires 30 May 2026                 [Page 12]


  Internet-Draft  AI Preferences Signaling: End User Impac   November 2025


     [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
                2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
                May 2017, <https://www.rfc-editor.org/info/rfc8174>.

  Acknowledgments

     TODO acknowledge.

  Authors' Addresses

     Farzaneh Badii
     Digital Medusa
     Email: farzaneh@digitalmedusa.org


     Lila Bailey
     Internet Archive
     Email: lila@archive.org


     Jo Levy
     Email: jlevy@nortonlaw.com





























  Badii, et al.              Expires 30 May 2026                 [Page 13]


