Problem
An implementer runs two agent-to-agent paths. One delivers over ordinary mail — email, settled. The other maps channel verbs onto their own in-application messaging surface, where a human reads the message in their client. Not mail, not any of the other six, and not service (RFC 0002 drew that line at "terminates at a service"; this terminates at a human reader).
That path currently carries email, which parses, verifies, and is false — it names a medium the message never touches. RFC 0002 already rejected exactly this in its own alternatives: "Borrow an existing channel kind. Rejected. It puts a false statement inside [the signature]."
Why this is reach, not bookkeeping
The request is not "let us label our own traffic." It is that a user's agent should be able to hold an APH-notarized conversation with another organization's agent on this medium, and have the recipient's verifier make a real §8.3.1 step-4 decision about it. Today that cannot be expressed conformantly — either the envelope names a medium that is not involved, or the traffic stays outside APH entirely.
Every kind in §7.1.5 exists so a recipient can decide about traffic on that medium. A medium carrying real cross-org agent-to-human messages, with no entry, is reach the protocol does not have.
Design
One additive value: squillo. It sits beside discord as a peer, not across the set as a modifier — six of the seven existing kinds are already vendor in-application surfaces.
The generalization test that killed a2a_email was decomposition: recipient class would have required a2a_slack, a2a_discord, … so the set doubled. This does not decompose. The set grows by one and stays the same shape.
A generic in_app value was drafted and rejected: kind is where a recipient's policy decision reads, and a generic bucket would force every recipient into the addressing block to recover a distinction kind exists to carry.
⚠ The governance limitation, stated up front
The applicant and the registry owner are the same organization. RFC 0004, published the same day, states that a request from the authoring org gets more scrutiny, not less, and that a variant would not be minted by fiat. This was decided by one person, who is that organization, with no second reviewer.
The full record is in the RFC's Decision block, unsoftened. The structural fix is not another RFC — it is moving this vocabulary to a registry its curator does not also apply to. Provisional IANA drafts are already prepared.
Full draft: rfcs/0007-in-app-channel-kind.md
Problem
An implementer runs two agent-to-agent paths. One delivers over ordinary mail —
email, settled. The other maps channel verbs onto their own in-application messaging surface, where a human reads the message in their client. Not mail, not any of the other six, and notservice(RFC 0002 drew that line at "terminates at a service"; this terminates at a human reader).That path currently carries
email, which parses, verifies, and is false — it names a medium the message never touches. RFC 0002 already rejected exactly this in its own alternatives: "Borrow an existing channel kind. Rejected. It puts a false statement inside [the signature]."Why this is reach, not bookkeeping
The request is not "let us label our own traffic." It is that a user's agent should be able to hold an APH-notarized conversation with another organization's agent on this medium, and have the recipient's verifier make a real §8.3.1 step-4 decision about it. Today that cannot be expressed conformantly — either the envelope names a medium that is not involved, or the traffic stays outside APH entirely.
Every kind in §7.1.5 exists so a recipient can decide about traffic on that medium. A medium carrying real cross-org agent-to-human messages, with no entry, is reach the protocol does not have.
Design
One additive value:
squillo. It sits besidediscordas a peer, not across the set as a modifier — six of the seven existing kinds are already vendor in-application surfaces.The generalization test that killed
a2a_emailwas decomposition: recipient class would have requireda2a_slack,a2a_discord, … so the set doubled. This does not decompose. The set grows by one and stays the same shape.A generic
in_appvalue was drafted and rejected:kindis where a recipient's policy decision reads, and a generic bucket would force every recipient into the addressing block to recover a distinctionkindexists to carry.⚠ The governance limitation, stated up front
The applicant and the registry owner are the same organization. RFC 0004, published the same day, states that a request from the authoring org gets more scrutiny, not less, and that a variant would not be minted by fiat. This was decided by one person, who is that organization, with no second reviewer.
The full record is in the RFC's Decision block, unsoftened. The structural fix is not another RFC — it is moving this vocabulary to a registry its curator does not also apply to. Provisional IANA drafts are already prepared.
Full draft:
rfcs/0007-in-app-channel-kind.md