[dmsc] Re: [agent2agent] Re: [SAMP] Discussion moving to the DMSC mailing list

[Chris Hood <[e-mail]>]

Orie,
Well aware of the process, and yes, all individual drafts today, deliberately. 
Your question, which list fits AGTP now. The answer is all of them, and none of them. And this is the larger problem these groups are debating. Agent communication requires knowing the agent. You cannot find an agent (dawn) without identity (wimse), to manage it (dmsc, agentproto), and then to audit it. The dependencies are real. AGTP argues that we should intentionally build this into one substrate.
There are over 230 active drafts across these lists, overlapping heavily, because each charter assumes a transfer substrate below its own scope. I catalog this here: https://github.com/nomoticai/ietf-agent-landscape [https://github.com/nomoticai/ietf-agent-landscape] and the problem statements here: https://github.com/nomoticai/ietf-agent-usecases [https://github.com/nomoticai/ietf-agent-usecases]
That is also why I would gently push back on the SAMP framing. SAMP, AGTP, and half the drafts in the catalog keep landing between charters because the layer question has been ignored. I requested a non-WG list (Agent Transfer Architecture / [e-mail]) for exactly this conversation. It has not come to life yet. The summary of that request is below. If you think it's worth having and can support, that would move it more than anything I can do.
I have been quiet on these lists for a few weeks, partly frustration with direction, and partly because I would rather ship than argue. And I agree that the agent2agent list is extremely difficult to follow, in my opinion, decimated by enterprise first positioning and AI generated messages.

But since Leslie asked the two questions directly, here is my answer, and it is one level up from where the thread is working.
The charter defines agentproto around dialog and communication modalities, voice, video, text. That is one piece of what an agent needs, and this is the same pattern every list follows. DAWN takes discovery. WIMSE takes identity. DMSC takes management. AUDIT takes records. Agentproto takes dialogs. Each group derives its piece carefully, each assumes the other pieces exist somewhere, and nobody owns how they integrate. The interoperability problem inside each piece is real, but the larger problem is between the pieces. A dialog that resumes across an administrative boundary needs the identity layer to verify who resumes it, the authority layer to check the resumption is covered, and the audit layer to record it. That is one flow in practice and four charters here.
So the concrete question is architectural. Do agents get five protocols mixed and matched per deployment, or one substrate where discovery, identity, sessions, communication, and records are designed as an integrated package? I have argued for the second and built it. Reasonable people argue for the first. What is unreasonable is five groups each choosing their own agenda without any consideration of alternative opportunity.
Most of these primitives exist in my session and communication drafts (https://www.ietf.org/archive/id/draft-hood-agtp-communication-00.html) over a dedicated transfer protocol (AGTP) rather than HTTP, for reasons argued in the use case suite. I am not asking anyone to adopt AGTP. I am saying the primitives this group is deriving have running implementations worth evaluating, and the layer question underneath them deserves a separate list.

The larger question, as a hypothetical. What happens if a dedicated transfer protocol makes the separate efforts unnecessary? Mail answered it once. Competing transfer schemes collapsed into SMTP, and everything since, MIME, SPF, DKIM, DMARC, became extensions of one substrate instead of parallel inventions. The pieces became better after the layer question was solved. That's my proposal for AGTP.
-

Summary (for the non-WG list table): Discussion of the Agent Transfer Architecture (ATA): whether AI agents require a dedicated transfer-layer protocol or can effectively operate over existing application-layer protocols (HTTP, MoQ, WebTransport, and others), and the architectural requirements and layering consequences of each approach.

Detailed purpose (for the mailman page and community announcement): This list is for technical and architectural discussion of the transfer-layer question for AI agents. Existing efforts (agentproto for session and communication, DAWN for discovery, DMSC for gateway-mediated collaboration, WIMSE for workload and agent identity, and others) each assume some transfer substrate below their scope. This list will examine what that substrate should be, without presupposing a specific answer. Scope includes: architectural requirements analysis, comparison of candidate approaches (HTTP-derived, MoQ- and QUIC-derived, purpose-built), layering and composition consequences, and community consensus on whether any dedicated transfer-layer work belongs in the IETF at all. Reference materials from existing individual Internet-Draft submissions (including AGTP) may inform the discussion but the list is scoped to the architectural question rather than to any specific proposal. Participation is open to anyone interested in agent coordination and its intersection with web and transport protocols.

Chris
On 9/4/2026 7:03:02 AM, Orie <[e-mail]> wrote:
Hi Chris, 

I love what you have done with https://agtp.io/ [https://agtp.io/] but just a word of caution.
Your drafts are currently individual internet drafts, right? -- see: https://www.ietf.org/process/process/ [https://www.ietf.org/process/process/]
Ideally you would get them adopted by a working group, and transfer change control to the IETF before we could say they are fully "in IETF".

- https://mailarchive.ietf.org/arch/browse/agentproto/ [https://mailarchive.ietf.org/arch/browse/agentproto/]
- https://mailarchive.ietf.org/arch/browse/audit/ [https://mailarchive.ietf.org/arch/browse/audit/]
- https://mailarchive.ietf.org/arch/browse/dmsc/ [https://mailarchive.ietf.org/arch/browse/dmsc/]
- https://mailarchive.ietf.org/arch/browse/dawn/ [https://mailarchive.ietf.org/arch/browse/dawn/]

We have many non-working group mailing lists discussing AI, and trying to define charter scope.
It's probable that the charter scopes will not cover the full space of agtp as you currently define it, but I have not checked all your drafts.

I am happy to see SAMP moving to a different list, I think it's been hard to follow the discussion on agent2agent, because of the scope being non-working group.
Chris, do you have a sense of which of the lists above is the best fit for agtp, now?
Perhaps parts of agtp are best described on specific lists.
You might consider updating the agtp website to relate to these lists (though I'm not sure exactly what that would look like).

Regards,

OS



On Fri, Sep 4, 2026 at 2:25 AM Chris Hood <[e-mail] [mailto:[e-mail]]> wrote:

I case you haven't familiarized yourself yet, I point you to AGTP.io which is one of the primary agent management protocols in IETF. 

Chris




-------- Original message --------
From: IETF Account <ietf=[e-mail] [mailto:[e-mail]]>
Date: 9/4/26 12:12 AM (GMT-08:00)
To: [e-mail] [mailto:[e-mail]]
Subject: [agent2agent] [SAMP] Discussion moving to the DMSC mailing list

Hello all,
Following earlier feedback, further discussion and development updates concerning the Simple Agent Management Protocol (SAMP) will continue on the DMSC mailing list:
[e-mail] [mailto:[e-mail]]
Those interested in following or contributing to SAMP can subscribe here:
https://mailman3.ietf.org/mailman3/lists/dmsc.ietf.org/ [https://mailman3.ietf.org/mailman3/lists/dmsc.ietf.org/]
The current SAMP Internet-Draft remains available at:
https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/ [https://datatracker.ietf.org/doc/draft-efstathiou-samp-agent-management/]
Thank you to everyone who has reviewed or commented on the work through the agent2agent mailing list.
Best regards,
Stelio E. Efstathiou
Author, Simple Agent Management Protocol (SAMP)
https://samp-protocol.org [https://samp-protocol.org]

_______________________________________________
agent2agent mailing list -- [e-mail] [mailto:[e-mail]]
To unsubscribe send an email to [e-mail] [mailto:[e-mail]]

_______________________________________________ agent2agent mailing list -- [e-mail] To unsubscribe send an email to [e-mail]
[242b2320-67dd-4eb0-8a7d-b3a28fbe7c91]