Review feedback for Activity Protocol Schema v5 proposal (issue #472)

[Copilot]

Issue #472 proposes Activity Protocol v5: a minimal symmetric envelope with payload-first multimodal content, unified relatesTo correlation, and typed entities for metadata. No code changes are made — this PR documents the review findings.

Critical Issues

• Section 15 missing: TOC references "Open Questions for the Committee" but the section body is absent
• Conflicts with accepted Extend Activity Schema to Support Multimodal Interactions with Streaming - Final Proposal (Revision) #416: relatesTo.stream (v5) vs. entities[streamInfo] (Extend Activity Schema to Support Multimodal Interactions with Streaming - Final Proposal (Revision) #416); payload.contentType (v5) vs. value/valueType (Extend Activity Schema to Support Multimodal Interactions with Streaming - Final Proposal (Revision) #416) — incompatible designs, one already accepted
• relatesTo semantic collision: v3 A5200 explicitly prohibits intra-conversation references; v5 redefines it entirely for that purpose without retiring A5200
• name field violates A6311: Examples use weather.getForecast / calendar.createEvent — not MIME media type format as required
• id / timestamp ownership flip: v3 requires channels to set these, SHOULD NOT for agents/clients; v5 makes them required for all senders — no migration rationale provided

Major Concerns

• No AXXXX numbered requirements: The entire proposal has zero normative AXXXX markers — the current spec has hundreds; this is untraceable as a committee draft
• 13 activity types silently dropped: typing, trace, invoke, handoff, endOfConversation, messageDelete, messageUpdate, messageReaction, etc. — no mapping or retirement guidance
• v: 5 required with no negotiation strategy: Hard break for all existing implementations; no guidance on how dual-stack receivers gate behavior
• JWT tokens in delegationChain.proof.token: Raw tokens embedded in durable activity bodies expire before replay; potential logging/forwarding exposure
• payload conditionality undefined: "Required for content-bearing activities" — what makes an activity content-bearing? No normative definition

Design-Level Feedback

• to as object | object[]: Union type forces Array.isArray() guards everywhere in SDKs; prefer always-array
• Section 8 (Streaming) is 4 bullets: Missing ordering guarantees, out-of-order handling, concurrent stream semantics, and flow control
• causedBy has no normative semantics: Defined in the shape but Section 6 has no MUST/SHOULD for it
• delivery.ttlMs units: Milliseconds for TTL is error-prone; ISO 8601 duration (PT10M) is consistent with the rest of the spec
• commandResult success/error envelope (§6.4.1): Labeled "interop guidance" but should be normative SHOULD to achieve its stated goal

Suggested Before Committee Approval

1. Add Section 15 content
2. Reconcile with or explicitly supersede Extend Activity Schema to Support Multimodal Interactions with Streaming - Final Proposal (Revision) #416
3. Retire conflicting v3 requirements (A5200, A6311, A2031, A2041)
4. Add AXXXX requirements for all normative statements in §5–11
5. Provide explicit migration mapping for each removed activity type
6. Define payload conditionality with normative requirements
7. Complete §8 Streaming with ordering/recovery/termination semantics
8. Address JWT token security in durable/store-and-forward scenarios
9. Standardize to to always-array
10. Add a machine-readable JSON Schema

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.