[ai-control] Re: Proposed language for Sec 3.2

[Andrew Campling <[e-mail]>]

To avoid straying into unnecessary complexity, I believe that the best wording covering both parts would be:

“This specification enables the expression of a defined set of preferences that can be
communicated and interoperably understood.”

If it is deemed essential to go further and include the entirety of the first part, I suggest that the second part, amending option 3, should be worded as follows:

“An entity that receives usage preferences has may have a choice whether to follow those
preferences. Multiple factors could influence that decision, but the decision
itself is outside the scope of this document.”

The reason to change “has” to “may have” is that this may vary by jurisdiction, so it would be wrong to assert that the entity always has that choice when it may not.

An alternative form of words for both parts could combine the above as follows:

“This specification enables the expression of a defined set of preferences that can be
communicated and interoperably understood.  An entity that receives usage preferences
may have a choice whether to follow those preferences. Multiple factors could influence
that decision, but the decision itself is outside the scope of this document.”


Andrew

From: Timid Robot Zehta <[e-mail]>
Sent: 29 July 2026 14:54
To: ai-control <[e-mail]>
Subject: [ai-control] Re: Proposed language for Sec 3.2

Following the Jul 24 Fri meeting, the currents status of Update §3.2 Applying Preferences and §4 Vocabulary Definition by TimidRobot · Pull Request #213 · ietf-wg-aipref/drafts<https://github.com/ietf-wg-aipref/drafts/pull/213> is:
Largely uncontested first part:
This specification enables the expression of a defined set of preferences that
can be communicated and interoperably understood. Readers of this
specification should understand that it does not:

- provide for enforcement of these preferences;
- address if, how, or when preferences should be followed or not-followed;
- address technical, legal, contractual, or other mechanisms that might create
  a stronger requirement to follow or not follow preferences;
- consider situations or purposes that might justify following or not-following
  expressed preferences.


with three proposals for the last part:
1) original

Because of this, stakeholders need to decide when and how to follow or
not-follow preferences in the context of legal, institutional, ethical, or
other interests and commitments.


2) Sebastian's

An entity that receives usage preferences has a choice whether to follow those
preferences. This specification does not determine how that choice is made.
Whether and under which circumstances a preference is followed is outside the
scope of this specification.


3) Martin's

An entity that receives usage preferences has a choice whether to follow those
preferences. Multiple factors could influence that decision, but the decision
itself is outside the scope of this document.


Please help narrow the three options down to one. If you give a preference, please also state whether you object to any of the others.

Thank you,

-Timid Robot

On Fri, Jul 24, 2026 at 1:33 PM Sarah McK <[e-mail]<mailto:[e-mail]>> wrote:
+1 to this: " lacks the ability to consult with the wide range of stakeholders" -- the IETF is a very valuable organization precisely because they are one of very few valid global technical standards setting bodies but the fact that they require stakeholders to discover their working groups and send emissaries to participate is probably the biggest weakness, there is no funding for outreach/participation to ensure affected parties have adequate representation.  That said, I am not sure there is a better place for this work...

On Thu, Jul 23, 2026 at 9:28 AM Chris Needham <chris.needham=[e-mail]<mailto:[e-mail]>> wrote:
I very much agree with Andrew. Not only does IETF lack the competence to address policy matters, its consensus based approach is the wrong structure to resolving what are a set of competing interests. It also lacks the ability to consult with the wide range of stakeholders needed. The small self selected set of individuals in this working group isn't that.

Chris


________________________________
From: Andrew Campling <[e-mail]<mailto:[e-mail]>>
Sent: 22 July 2026 10:47
To: Deen, Glenn (Comcast Cable) <Glenn.Deen=[e-mail]<mailto:[e-mail]>>; Victoria Noble <[e-mail]<mailto:[e-mail]>>; Brandon Butler <[e-mail]<mailto:[e-mail]>>; Sebastian Posth <[e-mail]<mailto:[e-mail]>>; ai-control <[e-mail]<mailto:[e-mail]>>
Cc: Leonard Rosenthol <[e-mail]<mailto:[e-mail]>>; Laurent Le Meur <[e-mail]<mailto:[e-mail]>>; Deen, Glenn (Comcast Cable) <[e-mail]<mailto:[e-mail]>>
Subject: [ai-control] Re: Proposed language for Sec 3.2


External: Think before clicking

+1 to Glenn’s point below.



In my view, the IETF lacks competence to address such matters of policy and should leave the topic to other fora.  If the community is determined to proceed with Section 3.2, it really ought to broaden the text to cover all the related policy, legal regimes etc.  This would be unwise and reaching consensus with any such content is improbable.





Andrew



From: Deen, Glenn (Comcast Cable) <Glenn.Deen=[e-mail]<mailto:[e-mail]>>
Sent: 22 July 2026 06:44
To: Victoria Noble <[e-mail]<mailto:[e-mail]>>; Brandon Butler <[e-mail]<mailto:[e-mail]>>; Sebastian Posth <[e-mail]<mailto:[e-mail]>>; ai-control <[e-mail]<mailto:[e-mail]>>
Cc: Leonard Rosenthol <[e-mail]<mailto:[e-mail]>>; Laurent Le Meur <[e-mail]<mailto:[e-mail]>>; Deen, Glenn (Comcast Cable) <[e-mail]<mailto:[e-mail]>>
Subject: [ai-control] Re: Proposed language for Sec 3.2



I agree that the discussion should focus on the meaning of the vocabulary. However, once we begin introducing language about when expressed preferences should be followed and when they may be disregarded, we have moved beyond questions of meaning and into questions of enforcement and policy.



Determining when expressed preferences can be ignored falls outside the scope of this working group’s mission. A vocabulary definition document defines terms and concepts; it does not define the circumstances under which statements made using that vocabulary must be followed, enforced, or set aside.

For example, Webster’s Dictionary defines words but does not address when ideas expressed in English should be heeded or ignored. The HTML specification defines the elements of a web page but does not establish access-control policies for websites built with HTML. Likewise, a description of a car’s components—its wheels, tires, and engine—does not include the legal requirements governing who may drive it.

In the same way, a vocabulary definition document is not the appropriate place to establish policy regarding the treatment of preferences expressed through that vocabulary.

This topic is outside the scope of this group’s charter. Just as we have deliberately avoided debating how copyright, database rights, and other legal regimes apply to AI, we should avoid debating when expressed preferences may be overridden.

Including language that specifies circumstances under which expressed preferences can be bypassed would give one policy issue preferential treatment while excluding discussion of other equally relevant policy considerations raised by stakeholders. Early in the chartering process, the group agreed to set aside questions relating to copyright and other legal rights regimes. The question of when preferences may be disregarded is closely intertwined with those same policy and legal issues.

I very much appreciate the importance of such issues and do not want to imply they are not important.   They are very much central to the broader discussion of AI’s use of content, but inserting a very specific policy into the vocabulary definition work now, complicates the small step forward we are working on by opening the door to those other commingled policy topics.

If we choose to include such language now, we risk reopening the broader set of policy debates that the group intentionally decided were outside its scope. That would undermine the boundary the charter established and draw the working group into precisely the “can of worms” it agreed not to address.



regards

Glenn







From: Victoria Noble <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 21, 2026 at 11:52 PM
To: Brandon Butler <[e-mail]<mailto:[e-mail]>>; Sebastian Posth <[e-mail]<mailto:[e-mail]>>
Cc: ai-control <[e-mail]<mailto:[e-mail]>>; Leonard Rosenthol <[e-mail]<mailto:[e-mail]>>; Laurent Le Meur <[e-mail]<mailto:[e-mail]>>; Deen, Glenn (Comcast Cable) <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [ai-control] Re: Proposed language for Sec 3.2

Strongly agree with Brandon. I can’t see a path towards consensus on a document that doesn’t include section 3.2, and in particular, language that recognizes that the public interest may take precedence over preferences under certain circumstances. Protecting these public interest uses is extremely important to me and others from the public interest community.



Victoria (Tori) Noble

Electronic Frontier Foundation

My working hours may not match yours. Please respond at your convenience.

From: Brandon Butler <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 21, 2026 at 2:38 PM
To: Sebastian Posth <[e-mail]<mailto:[e-mail]>>
Cc: ai-control <[e-mail]<mailto:[e-mail]>>; Leonard Rosenthol <lrosenth=[e-mail]<mailto:lrosenth=[e-mail]>>; Laurent Le Meur <[e-mail]<mailto:[e-mail]>>; Deen, Glenn (Comcast Cable) <Glenn.Deen=[e-mail]<mailto:Glenn.Deen=[e-mail]>>
Subject: [ai-control] Re: Proposed language for Sec 3.2

Agreed. This discussion is about the meaning of the vocabulary, not how it is attached. Also, as someone  especially invested in this issue, I’m not sure folks like me are going to be able to join a consensus around a document that omits it, in hopes that the next phase might correct the omission.



On Tue, Jul 21, 2026 at 4:42 PM Sebastian Posth <[e-mail]<mailto:[e-mail]>> wrote:

I don't quite understand why a general discussion of the vocabulary's applicability (however limited or extended that would be defined) would be better suited to the context of the attachment draft, which focuses specifically on describing methods for binding the vocabulary's expressions to content. – I rather believe that section 3.2 of the vocabulary draft is the right place for this statement. Moreover I believe that this discussion should not be postponed.

Kind regards,

Sebastian





On Tue, 21 Jul 2026 at 20:23, Laurent Le Meur <[e-mail]<mailto:[e-mail]>> wrote:

I like Leonard's proposal.



The "vocabulary" specification is a dictionary of terms that will be used in different contexts.

Most of us would like this specification to be completed asap by important missing terms (ai-grounding and maybe ai-input).



It makes sense to move the current discussion to the "attachment" specification, which provides a specific context (robots.txt, web crawlers ...) for the use of the vocabulary.



Best regards

Laurent Le Meur

EDRLab



Le 20 juil. 2026 à 17:14, Leonard Rosenthol <lrosenth=[e-mail]<mailto:[e-mail]>> a écrit :



The more I listen to this conversation, the more I wonder if this entire thread is happening at the wrong time (i.e., premature).  More specifically, it seems more closely tied to the attachment work, rather than the vocabulary work.



Vocabulary is just that - vocabulary.  It shouldn’t, IMO, say anything about HOW or WHERE it will be used.   Think Dictionary - nothing in a dictionary instructs the use (or lack thereof) of any given words/terms.



Attachment is where we get into more “nitty gritty” about the actual usage of the terms from the Vocab.  I could very well see us talking about this sort of stuff there as that is about how the consumers will find the data and what to do with it.



Discuss 😉.



Leonard



From: Deen, Glenn (Comcast Cable) <Glenn.Deen=[e-mail]<mailto:[e-mail]>>
Date: Monday, July 20, 2026 at 11:02 AM
To: ai-control <[e-mail]<mailto:[e-mail]>>
Subject: [ai-control] Re: Proposed language for Sec 3.2

EXTERNAL: Use caution when clicking on links or opening attachments.



@EKR - Thanks for asking about if this is argument over wording or something deeper.   - From my perspective it’s something deeper, but is also tied into the wording being proposed.



I agree and recognize that this is not a specification that includes any sort of technical enforcement mechanism. We have nothing about enforcement mechanisms in the charter, and to be clear, I am not suggesting that the specification should define one.



However, the absence of an enforcement mechanism is not the same thing as declaring that publishers' expressed preferences are merely optional and may be ignored whenever doing so is convenient for a consumer of the published content.



That distinction is a large part of why I have concerns with the proposed language in Section 3.2. I will say that Chris's suggestion comes closer than any of the other proposals to addressing some of those concerns.



My biggest difficulty is reconciling two seemingly contradictory goals. On the one hand, we are creating a vocabulary specifically to allow content publishers to express their preferences. On the other hand, we are considering language that appears to encourage consumers of those preferences to disregard them when it suits their interests.



If the purpose of this work is to provide a mechanism for publishers to communicate their preferences, then those preferences must carry some meaningful weight. Otherwise, it is unclear what value the vocabulary provides or the publishing of preferences provides.



Put another way: if a consumer intends to ignore AI Preferences regardless of their content, why read them at all? Conversely, if a consumer chooses to read the preferences, what is the justification for disregarding them? The specification may not enforce compliance, but it should not undermine the very purpose of expressing preferences in the first place.



I’m here at IETF126 if anyone wants to discuss in person.



regards

Glenn



From: Eric Rescorla <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 17, 2026 at 6:52 PM
To: Brandon Butler <[e-mail]<mailto:[e-mail]>>
Cc: Timid Robot Zehta <[e-mail]<mailto:[e-mail]>>; Jo Levy <jlevy=[e-mail]<mailto:[e-mail]>>; Deen, Glenn (Comcast Cable) <Glenn.Deen=[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>; Deen, Glenn (Comcast Cable) <[e-mail]<mailto:[e-mail]>>; Chris Needham <[e-mail]<mailto:[e-mail]>>
Subject: Re: [ai-control] Re: [EXTERNAL] Proposed language for Sec 3.2

Yes, this seems good.



Glenn, Chris, I'm trying to figure out whether this is an argument over wording

or something deeper. My understanding of this spec has always been that

this is merely an expression of preference with no intrinsic normative

force, even beyond that of ordinary IETF specs.



What I mean by that is that it's common for specs to say "if you implement this

protocol you MUST do X" but that you're free to not implement the protocol

at all, in which case you don't need to do X. So, for instance, you can't

be a conformant implementation of TLS 1.3 unless you implement P-256.



However, I had always understood the agreement to be that you could be a

conformant implementation of AIPREF that decided to ignore some set of

preferences for <reasons>, and that the specification would not restrict what

those reasons were.



Do you disagree with this?



-Ekr







On Fri, Jul 17, 2026 at 9:41 AM Brandon Butler <[e-mail]<mailto:[e-mail]>> wrote:

Exactly - indeed, it may be worth another slight tweak to make that clear. Perhaps the wording of the last paragraph could be:



Because of this, stakeholders need to decide when and how to follow or

not-follow preferences in the context of other legal, institutional, or

ethical, or other interests and commitments.





Take care,

Brandon



On Jul 17, 2026 at 12:28:21 PM, Eric Rescorla <[e-mail]<mailto:[e-mail]>> wrote:



On Fri, Jul 17, 2026 at 9:23 AM Brandon Butler <[e-mail]<mailto:[e-mail]>> wrote:

Agreed. In the absence of legal or regulatory requirements to follow preferences, users are free under this standard to choose not to follow preferences based on ethical or institutional commitments.



Or really, for any reason whatsoever.



-Ekr





--
ai-control mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>



--
ai-control mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

--
ai-control mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
--
ai-control mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>
--
ai-control mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>