[Agentproto] Re: Session lifecycle [was: Re: Sussing out points of disagreement on the charter]

[Eliot Lear <[e-mail]>]

I think we're agreeing on one point:

  * Only binding session state to TCP connections is a bad idea.

I think you have the messaging aspects about right.  That said, Ican 
WebTransport/Custom streams/H3 accomplish the same goal?  That'd be a 
HUGE win.  Sorry if this has been asked before.

Eliot

On 17.08.2026 08:06, Chris Hood wrote:
> Nope. I was pointing to AGTP that already does that as a dedicate 
> transport for agents.
>
>
> -------- Original message --------
> From: Eliot Lear <[e-mail]>
> Date: 8/16/26 10:25 PM (GMT-08:00)
> To: Chris Hood <[e-mail]>, [e-mail]
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: [Agentproto] Re: Session lifecycle [was: Re: Sussing out 
> points of disagreement on the charter]
>
> I can't tell if you're being flippant, but presumably you would like 
> some state to carry across TCP connections, or not require a single 
> TCP connection for each type of authorization.  Henri is offering one 
> way, by binding authorizations to specific requests.  From a 
> performance perspective that makes a lot of sense for agents that have 
> long-lived and high volume relationships with other agents.
>
> But the semantics of that authorization remain a big question.
>
> Eliot
>
>
> On 16.08.2026 23:42, Chris Hood wrote:
>> Imagine a transport protocol that was stateful....
>>
>>
>> -------- Original message --------
>> From: Henri Sirkkavaara <[e-mail]>
>> Date: 8/16/26 1:02 AM (GMT-08:00)
>> To: Bradley B <[e-mail]>
>> Cc: [e-mail], [e-mail], 
>> [e-mail], [e-mail]
>> Subject: [Agentproto] Re: Session lifecycle [was: Re: Sussing out 
>> points of disagreement on the charter]
>>
>> On what is worth exchanging at the application layer, one concrete 
>> thing: which party's authority a step was taken under, carried per 
>> request rather than established once per session.
>>
>> Statelessness removes the session identifier and it does not remove 
>> the question. When a workflow crosses domains, the receiving side 
>> still has to decide whether this request is covered by an authority 
>> granted earlier, and correlation metadata that only groups messages 
>> cannot answer that. Grouping tells you these events belong together. 
>> It does not tell you the second one was permitted by the first.
>>
>> That is the piece I would not push to another working group. 
>> Correlation and binding can ship as separate deliverables, and the 
>> base needs to leave room for the second, because an identifier 
>> assigned by one party is not something the other party can check. If 
>> the base pins correlation as sufficient, implementations will read 
>> the identifier as authority and the interop failure appears at the 
>> domain boundary, which is exactly where nobody owns it.
>>
>> Concrete example, since you asked for those: a task moves from one 
>> operator's agent to another's and back. The return step needs to 
>> establish that it is resuming work the first operator authorised, 
>> across a gap where neither side holds the other's state.
>>
>>
>>
>> On Saturday, August 15th, 2026 at 02:48, Bradley B 
>> <[e-mail]> wrote:
>>
>> > Mirja, Suresh, Sumit,
>> >
>> > Agreed with Sumit that statelessness moves the question up rather than
>> > removing it. I want to name the case that decides where it lands,
>> > because I do not think correlation metadata alone can carry it.
>> >
>> > Mirja, on failure detection at the HTTP layer, agreed as far as it
>> > goes. Transport failure is HTTP's job and the local reaction to it is
>> > a local decision. The distinction I would add is between a request
>> > that failed and a request that was refused, because HTTP cannot
>> > separate those in the direction that matters.
>> >
>> > Sumit's case is the clearest version of the first half: domain B
>> > admits the work, returns success, and never schedules it. That is a
>> > 200. Mine is the mirror. We emit signed decision records for both
>> > allow and deny, and the deny records are the ones auditors ask for. A
>> > denial correlates with nothing, because there is no subsequent action
>> > to associate it with. The whole point of the record is that nothing
>> > happened.
>> >
>> > A status code closes neither gap. It is hop-scoped, so it describes
>> > the outcome between two endpoints and does not survive the hop, and
>> > the third party who needs the record was never on that connection. It
>> > is unsigned and unattributable, so nobody can check it afterwards or
>> > be held to it. And at that layer silence and denial are the same
>> > shape.
>> >
>> > So scope to correlation alone, and the refused action, which is the
>> > record most often needed across a trust boundary, is unrepresentable
>> > by construction. Not hard to represent. Unrepresentable, because
>> > correlation metadata attaches to pairs and there is no second half of
>> > the pair.
>> >
>> > That is one property, and it is narrower than session lifecycle, which
>> > I agree should leave the charter as a term: entering a state a relying
>> > party may need to reason about produces an artifact rather than
>> > silence. Not the states, not the transitions, not full session
>> > semantics.
>> >
>> > On OAuth. Agreed that grants, issuance and revocation belong there,
>> > and I would not ask this group to define them. But OAuth defines
>> > whether an authority exists. It does not define whether a refusal is
>> > stated on the wire between two agents, and that is the part only this
>> > group can decide, because it is a question about what the protocol
>> > carries rather than about what the authorization model says. If a
>> > refusal is never emitted, no audit model downstream can reconstruct
>> > it, because the fact was never stated by anyone. AUDIT can define what
>> > a record must contain. Only this group can decide whether the protocol
>> > carries enough for that record to be honest.
>> >
>> > Grounding rather than assertion: our allow and deny records were
>> > independently compared against a frozen build and a shared evidence
>> > record by a third party in the current interop event. That establishes
>> > the records are portable and checkable by someone who is not us. It
>> > does not establish more than that.
>> >
>> > Sumit, your partition is the right frame and I think refusal is a
>> > third case in it. What carries across, what is discarded, and
>> > separately, what must be stated at all rather than inferred from
>> > silence.
>> >
>> > Happy to contribute text on the refusal-artifact property if it would
>> > help make it concrete.
>> >
>> > IPR disclosure covering the material behind this:
>> > https://datatracker.ietf.org/ipr/7500
>> >
>> > Bradley B
11 AI Blockchain Developments LLC
>> >
>> >
>> > On Fri, Aug 14, 2026 at 2:26 PM Sumit Ahuja
>> > <sumit=[e-mail]> wrote:
>> > >
>> > > Suresh,
>> > >
>> > > On failure and migration needing cross-domain agreement rather 
>> than being an implementation choice, one thing from the serving side 
>> that I think sharpens what has to be agreed, and Mirja's 
>> statelessness point makes it sharper.
>> > >
>> > > What a migration needs both sides to agree on is not how the 
>> migration is performed but what survives it. Those are separable, and 
>> only the second has to be common.
>> > >
>> > > The division I have used is that the commitment survives and the 
>> accumulated work does not. On unplanned failure the record of what 
>> was granted moves to the resuming party, deliberately excluding 
>> accumulated intermediate state and progress, and the resuming party 
>> continues under the original grant without re-entering admission. The 
>> flow loses unpinned progress; it does not lose its contract. That is 
>> one answer rather than the answer, but the shape is the part that has 
>> to be agreed: a resuming party that does not know whether it 
>> inherited a commitment or only a task cannot behave correctly either 
>> way, and a requester that does not know which it will get cannot 
>> decide whether to retry.
>> > >
>> > > Mirja's point about MCP going stateless is where this bites. If 
>> the workflow's identity is metadata one endpoint adds to correlate 
>> request and response pairs, then a migration has nothing to migrate: 
>> the new handler did not supply the correlation and has no 
>> protocol-level obligation to recognise it. Statelessness at the 
>> transport is the right call and it does not settle this, because it 
>> moves the question up rather than removing it. The higher layer she 
>> describes is where a workflow either has an identity that outlives 
>> the party currently holding it, or it does not, and migration is the 
>> case that makes the difference observable.
>> > >
>> > > So if failure and migration are in scope, the minimum I would 
>> want agreed is what a resuming party inherits, stated as a partition 
>> rather than a mechanism: what carries across, what is discarded, and 
>> whether the original grant continues or a new one is required. 
>> Everything about how the handoff is executed can stay local.
>> > >
>> > > Sumit P. Ahuja
>> > > Main Labs
>> > >
>> > > On Aug 14, 2026, at 07:34, Mirja Kuehlewind (IETF) 
>> <ietf=[e-mail]> wrote:
>> > >
>> > > I think detecting a  “failure” could be handled on the HTTP 
>> layer, as this is a common case that all protocols need to support. A 
>> local reaction when the failure is detected is a local implementation 
>> decision. So I guess the question would be is there any other 
>> information about the session lifecycle that would be valuable to 
>> exchange on the higher/application layer that would be needed to make 
>> the right decision to handle the failure (or any other decision 
>> within one session). Where I would see a session as actually a set of 
>> point-to-point agent communications that are belong to the same 
>> workflow (which is probably slightly different then Johnathan’s 
>> definition but I would be interested to he this thoughts!). I think 
>> this leads then to the question we want need to standardize a request 
>> and response/accept protocol on the application layer that is not 
>> bind to one http/transport communication.
>> > >
>> > > MCP itself is now stateless, meaning that they don’t have this 
>> notion of session to covers multiple HTTP request anymore. That means 
>> they have removed the initialization workflow (which I would rather 
>> see as part of a discovery process anyway) and they removed the 
>> Mcp-Session-Id. This totally make sense because statefulness is an 
>> attack vector. Stateful request/response is also the model used for 
>> the same reason on the web. However, agents workflow can be more 
>> complex than request a web resource. As such session management is 
>> now explicitly left to the higher layer. This is where we should 
>> consider additional standardization.
>> > >
>> > > In case of MCP they have a minimum json-based request/response 
>> protocol like this (some of this might have changed in the latest 
>> version but the details don’t mater too much for this discussion right):
>> > >
>> > > Request:
>> > >
>> > > { jsonrpc: "2.0"; id: string | number; method: string; params?: { 
>> [key: string]: unknown; }; }
>> > >
>> > > Response:
>> > >
>> > > { jsonrpc: "2.0"; id: string | number; result: { [key: string]: 
>> unknown; } }
>> > >
>> > > Error:
>> > >
>> > > { jsonrpc: "2.0"; id?: string | number; error: { code: number; 
>> message: string; data?: unknown; } }
>> > >
>> > > I believe the id in these messages would be unique per http 
>> request/response in the new stateless version of MCP. So you would 
>> probably want to add additional
>> > > metadata that can correlate multiple request/reponse pairs to one 
>> session.
>> > >
>> > > A2A specifies aSendMessageRequest object and the response is send 
>> as either a Task or Message object (they also have errors).
>> > >
>> > > I think these are good things a as starting point and we could 
>> specify something on top to provide a common standard to enable 
>> interoperability between these protocols with the goal that it should 
>> be easy to be translated/mapped to the existing base pattern in these 
>> already deployed protocols.
>> > >
>> > > Mirja
>> > >
>> > >
>> > > On 14. Aug 2026, at 05:19, Suresh Krishnan 
>> <[e-mail]> wrote:
>> > >
>> > > Hi Mirja,
>> > >
>> > > On Aug 12, 2026, at 10:05 AM, Mirja Kuehlewind (IETF) 
>> <[e-mail]> wrote:
>> > >
>> > > Hi Suresh, hi Rob, hi all,
>> > >
>> > > I think all the points discussed below are needed in some way, 
>> but the real questions is: what needs to be standardized?
>> > >
>> > > I think the correlation bit if the most important piece here that 
>> we identified as needed for inter domain workflows (without providing 
>> a clear definition of “workflow” at this point). Yes, proof of 
>> binding is needed as well but maybe we can separate this out and rely 
>> on existing (or new) work of other working groups?
>> > >
>> > > On the session lifecycle question: Initially I thought this is 
>> the main piece but the more we talk about it, the less I’m actually 
>> sure what we mean. Do people have concrete examples what is needed, 
>> and again more importantly, what needs to be standardized here to 
>> survive cross-domain rather than just being an implementation choice?
>> > >
>> > >
>> > > I think this is where I see some divergence between what Jonathan 
>> and Brian proposed. If you think the failure+migration use case is in 
>> scope, there is a need for this to be agreed across domains (and not 
>> simply an implementation choice) since the other party also needs to 
>> agree with how it is done. If your point is that there might already 
>> be mechanisms that can be used that is something we can discuss.
>> > >
>> > > Thanks
>> > > Suresh
>> > >
>> > > _______________________________________________
>> > > Agentproto mailing list -- [e-mail]
>> > > To unsubscribe send an email to [e-mail]
>> > >
>> > >
>> > > _______________________________________________
>> > > Agentproto mailing list -- [e-mail]
>> > > To unsubscribe send an email to [e-mail]
>> > >
>> > >
>> > > _______________________________________________
>> > > Agentproto mailing list -- [e-mail]
>> > > To unsubscribe send an email to [e-mail]
>> >
>> >
>> >
>> > --
>> >
>> >
>> > 11 AI Blockchain Developments LLC
>> >
>> > Brad B - Inventor
>> >
>> > 📧 [e-mail]
>> > 🌐 https://11aiblockchain.com
>> >
>> > DUNNS @- 144921555
>> >
>> > 11 AI Blockchain Developments LLC ,11/11 AI Research Division
>> > Copyright (c) 2026 11 AI Blockchain Developments Land and IP Trust.
>> >
>> > “We control whether AI decisions are allowed to execute”
>> >
>> > _______________________________________________
>> > Agentproto mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>> >
>>
>> Henri Sirkkavaara
>> Vaara - Runtime execution layer for AI agents
>> Built to see over the noise.
>> vaara.io
>> Helsinki, Finland
>>
>> _______________________________________________
>> Agentproto mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>> _______________________________________________
>> Agentproto mailing list [e-mail]
>> To unsubscribe send an email [e-mail]
>
> _______________________________________________
> Agentproto mailing list [e-mail]
> To unsubscribe send an email [e-mail]