Protocol filing status ledger

Last verified: 2026-08-22 UTC.

This ledger records direct upstream reads for the protocol-contribution threads that back the RFCs in this directory. It is reference material and intentionally factual: record a state here only after fetching the upstream discussion, PR, or issue directly.

What changed since the 2026-07-25 read. Two threads moved and the rest sat still.

• A2A #2028 is the busiest thread and the hardest to read. Twelve new comments through 2026-08-20 took it from 12 to 24. Two participants posted executable vectors for the well-formedness/authority split and reported no divergences between them, an originAnchor slot was reserved and pinned inert, and a review from the ZeroID side supplied a correction to the extension text: per-hop scopes are derived from a validated credential, never authorization-bearing. Weigh that volume against who is in the thread before treating it as demand. The drafting action was claimed by a third party, not by us.
• oauth-wg #73 handed the ball back to us. A draft author replied on 2026-07-25, after our answer the same day, redirecting the actor-chain half to draft-mcguinness-oauth-actor-profile and its receipts, proofs, and authority-bounds companions. That repository has no thread from us, so the invitation is unanswered.
• Everything else — ACP #1220, #1224, #1233, #1261; A2A #1857, #1858, #2027; MCP #3007, #3008 — is unchanged. MCP #2736 is closed from our side.

Public follow-up posture#

Upstream comments and PRs should use neutral ecosystem evidence, peer behavior, and public prior art. Do not lead with Harn or Burin-specific adoption claims. A local implementation can inform our internal confidence, but public posts should stand on protocol semantics and independently checkable examples.

One qualification, from reading the MCP SEP process on 2026-07-25: a prototype offered as feasibility evidence is not an adoption claim, and the SEP process explicitly requires one before acceptance ("pseudocode alone" and "a design document without code" are called out as insufficient). Offering a runnable proof-of-concept is in-posture; citing internal usage numbers as an argument is not.

Every filing at a glance#

Nothing has been rejected anywhere, and across twelve threads the pattern is consistent: proposals draw third-party comment and no maintainer verdicts. Read the third-party column as a count of commenters, not as a quality signal — track records vary sharply between threads, and #2028 carries the caveat in Who is in #2028. One thread, oauth-wg #73, is waiting on us, by direct invitation from a draft author.

One correction to that read, found 2026-07-25. "Maintainer attention is the binding constraint" is not the diagnosis everywhere. MCP #2736 was silent because the feature it extends was deprecated by SEP-2577 on 2026-05-15, which no amount of maintainer attention would have changed. Before attributing silence to bandwidth, confirm the target surface still has a future. See lifecycle status of target surfaces.

ACP#

Context as of 2026-07-25: unchanged from the 2026-07-03 read. The v2 RFD collection is the most active area of the repo, but every v2 RFD PR merged since 2026-06-01 was maintainer-authored. Externally-authored RFD PRs (including #1261) sit in review while their content gets absorbed into unstable-v2 commits. Plan for discussions to be the unit of influence, not PR merges. Two v2 docs matter for our filings: the merged session-resume-replay RFD (unified session/load + session/resume, optional replayFrom cursor) is the substrate any session/suspend follow-up must sit on, and open PR #1237 (client-provided system prompt) overlaps the session/remind territory and should be differentiated against, not ignored.

A2A#

Context as of 2026-07-25: unchanged from the 2026-07-03 read. A2A v1.0.0 shipped 2026-03-12 (v1.0.1 on 2026-05-28), which predates our 2026-05-17 filings. v1.0 renamed operations to PascalCase across all bindings (message/send → SendMessage, subscription → SubscribeToTask), moved enums to SCREAMING_SNAKE_CASE per ProtoJSON, removed kind discriminators, and made a2a.proto the normative source of truth. Both filed discussions and the RFCs in this directory originally used pre-1.0 naming; the RFCs were revised to v1.0 conventions on 2026-07-03, and any follow-up upstream post should use v1.0 names.

Extension mechanics, read 2026-07-25: extensions are declared as AgentExtension entries under AgentCapabilities (URI, description, required flag, params) and activated by A2A-Extensions header negotiation, with the agent echoing back what it activated. Four categories exist — data-only, profile, method, and state-machine extensions. Only the canonical https://a2a-protocol.org/extensions/ prefix is reserved for official extensions under a2aproject governance; community extensions may be self-published under their own URI, with permanent-identifier services such as w3id.org recommended. A new URI MUST be used for any breaking change to an extension's logic, data structures, or required params. This matters for #1858 and #2028: both have a path that does not depend on a TSC answer.

Who is in #2028#

Recorded because the comment count on this thread is the strongest-looking number in the ledger and it does not mean what a reader would assume. Verified 2026-08-23 against the GitHub API.

• All 24 comments carry author_association: NONE. No maintainer, member, owner, or collaborator of a2aproject has ever replied. The "No" in the maintainer column is not "not yet" — it is fourteen months of silence on a thread the ledger elsewhere calls the busiest.
• Two accounts wrote 15 of the 24 comments: navigatorbuilds (8) and giskard09 (7). They are also the "two implementations" whose agreement the ledger cited. Two parties who have been in continuous conversation since 2026-07 corroborating each other is weaker evidence than the phrase "independent implementations" suggests, and this ledger should not have used it. We authored exactly one comment (2026-07-25).
• Several participants have very new accounts: navigatorbuilds created 2026-01-26 (1 follower), 0xbrainkid 2026-01-27, giskard09 2026-03-23. Their comments are long, uniformly formatted, and some carry AI-assistance disclosures. That is not proof of anything, and none of it makes the technical content wrong — the well-formedness/authority split stands on its own reasoning. It does mean the thread is not evidence of ecosystem demand.
• The one participant with a long track record and a real project, rsharath (account 2013, ZeroID), commented once, on 2026-08-20, and supplied the most useful correction in the thread.

Practical consequence: treat #2028 as a design conversation that produced one good correction, not as upstream traction. Volume of agreement in a thread with no maintainer in it is not a signal to invest against.

MCP and OAuth Identity#

MCP process facts (read 2026-07-25)#

Recorded here because both open MCP items are process-blocked rather than substance-blocked, per the SEP guidelines:

• A SEP is a PR adding seps/0000-title.md, renamed to the PR number once opened — not an issue and not a discussion.
• Required sections: Preamble, Abstract (~200 words), Motivation, Specification, Rationale, Backward Compatibility, Reference Implementation, Security Implications. Insufficient motivation is called out as grounds for outright rejection.
• A sponsor is mandatory to move Awaiting Sponsor → draft: a Core Maintainer or Maintainer from MAINTAINERS.md. Tag 1–2 relevant maintainers, not everyone; if no response in two weeks, ask in #general on Discord.
• No sponsor within 6 months means dormant, which the process states explicitly is not rejection and is revivable.
• Discussing with the relevant working/interest group on Discord first is described as "the single best way to refine your proposal and build early support," and a cold PR submission is the weakest entry point.
• A prototype is required before acceptance (not before submission); pseudocode or a design document alone is insufficient.
• Standards Track SEPs with observable protocol behavior additionally need a merged conformance scenario plus a sep-NNNN.yaml traceability file mapping every MUST/SHOULD before Final — not before acceptance.

IETF draft facts (read 2026-07-25)#

The actor-chain gap has partly resolved upstream in our favour. The representation half is being standardized; the semantic half is explicitly out of scope, and that is the half we have implementation experience in.

• ID-JAG (draft-ietf-oauth-identity-assertion-authz-grant) is at revision 04, 2026-05-21, an active OAuth WG draft with no intended RFC status set. actor_token is now OPTIONAL and permitted, but the draft deliberately stops there: "This specification does not define normative processing requirements for actor_token or whether an act claim is included in the issued ID-JAG." It defers to profiles. This supersedes our original premise that ID-JAG "explicitly disables actor_token," which was true of an earlier revision.
• The Actor Profile (draft-mcguinness-oauth-actor-profile, 2026-04-30, expires 2026-11-01) is that profile, and covers more than we assumed. Multi-hop chains are specified: "Delegation chains MUST be represented by nesting act objects... the outermost act object identifies the immediate actor; inner act objects represent prior actors." Implementations "SHOULD support a local maximum of at least depth 4." Preservation is mandated more strongly than we asked for: "The AS MUST NOT silently drop an inbound act claim; if it cannot preserve or extend the chain, it MUST reject the request." The canonical actor identifier is the (act.iss, act.sub) pair, not act.sub alone.
• What the profile explicitly declines to standardize, and therefore remains open: (1) per-hop scope narrowing — "This document does not standardize the policies by which systems determine whether a given actor is permitted to act for a subject," scope reduction is deployment-specific; (2) per-hop proof-of-possession — "Other members carried inside an act object... do not have standardized proof-of-possession semantics," only the top-level cnf conveys the current presenter's key.

Lifecycle status of target surfaces#

Verified 2026-07-25 against the MCP deprecated-features registry. Check this before any further work on a filing: a proposal that extends a deprecated surface cannot land, regardless of its merits or its support.

MCP deprecated three features in SEP-2577 as of protocol version 2026-07-28, each with earliest removal in the first revision released on or after 2027-07-28:

MCP #2736 is dead. It proposed budget caps on sampling/createMessage. The feature is deprecated and the migration path is to stop using it. Recorded in full in the budget-caps RFC, retained as a design record rather than deleted.

MCP #3007 needs to differentiate or be dropped. It proposes notifications/reminder, a new server-to-client notification. Logging — the existing server-to-client notification channel — was deprecated in the same SEP, with observability pushed to OpenTelemetry. The proposals are not the same thing: ambient context injection into an agent's turn is not observability, and OpenTelemetry is not a substitute for it. But the directional signal is real, and a thread proposing a new push channel in the revision that removed the old one plausibly reads as swimming upstream. That is a better explanation of its zero comments than cold-start alone. Any revival must answer "why is this not OpenTelemetry, and why is this not a tool result?" in the first paragraph.

MCP #3008 is unaffected. InitializeResult is not deprecated. One adjacent change worth tracking: client capabilities now ride in _meta.io.modelcontextprotocol/clientCapabilities on each request rather than solely in the handshake, so the handshake payload is under active restructuring even though the surface survives.

Adjacent finding, not a filing. Dynamic Client Registration is now deprecated in favour of Client ID Metadata Documents. That shifts the premise of harn#4432 (MCP OAuth loopback robustness, which includes DCR redirect-URI and ephemeral-port drift): hardening a deprecated registration path is worth less than it was when that issue was written.

A2A: no deprecation risk, two corrections#

Checked 2026-07-25 against the current A2A specification.

A2A has a formal deprecation lifecycle in Appendix A: a renamed message or field keeps its old name, marked deprecated, until the next major release. Two breaking changes are recorded there, both already known to us — the kind discriminator removal and the extended-agent-card field relocation. Nothing we target is deprecated.

TASK_STATE_PAUSED still does not exist. The current enum is UNSPECIFIED, SUBMITTED, WORKING, COMPLETED, FAILED, CANCELED, INPUT_REQUIRED, REJECTED, AUTH_REQUIRED. There is no caller-initiated pause and no mechanism for one, so the gap #1858 describes is intact and unclaimed after two months.

Correction to #1857's premise. The filing implies no idempotency handle exists. The spec actually says Send Message operations MAY be idempotent and that agents may use messageId to detect duplicates. So a handle exists; what is missing is any obligation to honour it or any specification of the dedupe window and collision behaviour. That makes the right ask considerably smaller than the filing's: specify dedupe semantics for the existing messageId, rather than add a new Idempotency-Key. Recorded on harn#5540 — it partially reopens the option A versus B decision, since "tighten what already exists" is a much easier sell than "add a field."

Watch item for #2028. The actor-chain extension is declared through AgentExtension entries under AgentCapabilities. One of A2A's two recorded breaking changes relocated an extended-agent-card field, so confirm the declaration location against the current schema before any follow-up post cites it.

ACP: no deprecation risk, and an open invitation#

Checked 2026-07-25 against the v2 overview RFD.

session/load is removed in v2, with session/resume subsuming it via an optional replayFrom cursor. We already accounted for that in the 2026-07-03 realignment on #1233, so no rework is needed.

session/prompt and session/cancel continue unchanged in v2, which are the surfaces the inject and suspend proposals sit beside. The v2 baseline session method set is session/new, session/list, session/resume, session/close, session/prompt, session/cancel, and session/update. Every one of our ACP proposals is an addition to a live surface rather than an extension of a deprecated one. Nothing is deprecated.

The v2 "RFDs to be Written" list now reads "MCP: tool timeouts, more lifecycle methods." That second item is an open slot that session/suspend fits directly, and it is a stronger position than the thread has had. It also indicates the truncate/edit item previously on that list has been claimed, consistent with htahaozlu re-basing the rewind proposal onto the v2 lifecycle in the #1261 thread.

Net result of the lifecycle sweep#

One filing died (MCP #2736), one is at risk and needs to differentiate (MCP #3007), one gained a stronger framing (ACP #1233, which fits a named open slot), and one had its premise corrected in a way that shrinks the ask (A2A #1857). The remaining seven are unaffected.

Local follow-up candidates#

Ordered by whether they depend on someone else moving first.

Unblocked — no maintainer required:

• MCP #2736: closed out, not filed. The target feature is deprecated. A close-out note on the thread asks whether budget semantics matter for whatever replaces Sampling; no further work otherwise. Tracked in harn#5539.
• MCP #3007: decide whether to differentiate against the Logging deprecation or drop it. Do not revive it without answering the OpenTelemetry question.
• A2A #2028: fold "per-hop scopes are derived from the validated credential, never authorization-bearing" into the extension text, with RFC 8693 act cited for the identity half only. Offered upstream on 2026-08-20; the thread is waiting on the revision, not on a maintainer.
• oauth-wg #73: the draft author invited the actor-chain conversation into draft-mcguinness-oauth-actor-profile on 2026-07-25. Nothing from us is there yet. Accepting that invitation is the next step, and it also decides whether the companion-profile draft we offered belongs in that repo.
• ACP #1233: replied 2026-07-25 adopting the acknowledged-request shape. No follow-up until someone answers.
• MCP #3008: begin auth-area sponsor outreach via the relevant WG/IG rather than waiting for the discussion to attract one.
• #3347: write the IETF draft-watch note; three of five tracked drafts are still unpinned (WIMSE WIT/WPT, transaction-tokens-for-agents, draft-klrc-aiagent-auth).
• Audit item from the Actor Profile read: the canonical actor identifier is the (act.iss, act.sub) pair. Anywhere our internal chain keys an actor by subject alone is a latent interop bug; check against Epic A / C under harn#3326.

Blocked on maintainers — hold:

• ACP #1261: keep conflict-free against upstream main, keep the public framing anchored in existing editor/agent behavior. Three unprompted third-party adoption reports now sit in the thread; that is the argument, and it does not need restating by us.
• ACP #1224: the maintainer asked for time on 2026-07-06. Do not re-ping.
• A2A #1858: draft PR stays ready-to-cut but uncut until the draft-PR-vs-extension question is answered — or until we decide to self-publish under our own extension URI.
• A2A #2027, MCP #3007: cold with no venue warming. Leave parked or warm the venue first; no re-pings without new substance.

Standing rule: no re-pings without new substance. Third-party feedback arriving in a thread is new substance; the passage of time is not.

Not yet filed#

• session/inject_host_event — documented in typed host-event injection as a shipped Harn extension, the only doc in this directory with no upstream filing and no tracking issue. It is the host-originated sibling of session/inject: same delivery seams, opposite initiator. Natural follow-on RFD if #1261 lands; premature while #1261 is unreviewed.
• MCP suspend/resume — deliberately not filed. MCP tools are request/response with no agent-lifecycle surface to extend. Recorded so the absence is not mistaken for an oversight.