[ai-control] Re: Proposal: AI Preference Attachments for Source Code and VCS (Seeking Co-editors)

[Felix Reda <[e-mail]>]

Dear Thomas,

Thanks a lot for driving this work forward. I had the opportunity to comment on an early draft of this proposal and I support its approach. Software code has particularities that require a different approach from robots.txt, as developers rarely have access to the robots.txt file of the domains through which their code is distributed. At the same time, I really appreciate that this proposal focuses on the attachment mechanism and is open to adopting any vocabulary of preferences that this working group is ultimately going to agree on.

As regards to the question of the working group charter, I am not 100% sure, because the description of the charter supports this work ("The Working Group will focus on attaching preferences to content either by including preferences in content metadata or by signaling preferences using the protocol that delivers content"), while the deliverables are more narrowly tailored to "means of attaching or associating those preferences with content in IETF-defined protocols and formats“. Perhaps the chairs can provide clarity here.

Either way, without wanting to distract one bit from the important work on the vocabulary, I hope members of this group with an interest in software preferences will engage with the proposal and help develop it.

Best,
Felix

From: Thomas Aynaud <[e-mail]>
Date: Monday, 30. March 2026 at 09:54
To: [e-mail] <[e-mail]>
Subject: [EXTERNAL] [ai-control] Proposal: AI Preference Attachments for Source Code and VCS (Seeking Co-editors)

Hi everyone,

As the working group continues to make excellent progress on draft-ietf-aipref-attach, we’ve been looking closely at how to apply these mechanisms to software source code and version control systems.

In Section 1.3.1 of the current attachment draft, it is noted that embedding preferences directly into content is highly effective but requires format-specific methods. We believe source code fits precisely into this scope.

A fundamental difference between source code and other media is how copyright owners traditionally communicate usage rights. In the software ecosystem, there is a decades-long precedent of declaring reuse permissions inside the artifact itself (e.g., via LICENSE files or SPDX headers).

If an AI preference is declared exclusively via the Content-Usage HTTP header (Section 2) or robots.txt (Section 3), it does not follow this established developer workflow. Furthermore, because code is distributed via git clone, package managers, or archive downloads, transport-layer metadata is inherently stripped. The preference vanishes the moment the repository is cloned, or used in any of the various phases of software development, not to mention vendoring.

To bridge this gap, Software Heritage and partners that are involved in the CodeCommons project (see https://codecommons.org) have drafted a specification for an in-repository attachment mechanism that survives at rest.

Working Specification: https://gitlab.softwareheritage.org/teams/codecommons/cc-public-resources/-/tree/main/specifications/aiprefs

We are bringing this to the list with two goals:

1. To get the working group's initial feedback on the technical approach of an in-repo file constraint.
2. To ask if this software-specific attachment mechanism is within the scope of the IETF working group, and if so, whether anyone with experience authoring IETF drafts would be interested in co-editing this document with us. We have the core specification mapped out in GitLab, but we would greatly appreciate a co-editor to help translate this into the formal IETF XML/RFC format for an official -00 submission. If the chairs conclude that this proposal is outside the scope of the AIPREF working group, we would appreciate advice on appropriate venues to advance this specification.

Thanks for your time and the great work on the core drafts so far,

--
Thomas Aynaud

--
ai-control mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]