[Uri-review] [IANA #1451407] URI Scheme Registration Request: agtp (provisional)

[David Dong via RT <[e-mail]>]

Hi Chris,

We've added provisional URI scheme "agtp" to the registry:

https://www.iana.org/assignments/uri-schemes/prov/agtp

Registry: https://www.iana.org/assignments/uri-schemes

Per the designated expert for URI Schemes registry, we're also notifying the [e-mail] mailing list that this provisional registration has been completed.

Best regards,

David Dong
IANA Services Sr. Specialist

On Fri May 01 20:14:32 2026, [e-mail] wrote:
> Hi David,
> 
> Thanks for the follow-up.
> 
> AGTP does not have constrained-environment use cases that would
> require a CRI
> number from the 0-999 range.
> Please proceed with the next available value from the 1000-20000
> range.
> 
> Best regards,
> 
> Chris Hood
> 
> 
> 
> On Fri, May 1, 2026 at 1:05 PM David Dong via RT <iana-prot-
> [e-mail]>
> wrote:
> 
> > Hi Chris,
> 
> > With the registration of a URI scheme, IANA assigns a numeric
> > identifier
> > for URI scheme as well: the CRI scheme number.
> 
> > Unless the registrant indicates special requirements for the CRI
> > scheme
> > number (https://datatracker.ietf.org/doc/draft-ietf-core-href/)
> > associated
> > with the URI scheme (typically for a CRI scheme number with a short
> > encoding in a CRI), IANA will assign the next available value from
> > the
> > 1000-20000 range.
> 
> > Does this URI scheme need a CRI number from the 0-999 range? If so,
> > we'll
> > ask the expert for that field to approve that aspect of the request
> > before
> > we register the URI scheme.
> 
> > Best regards,
> 
> > David Dong
> > IANA Services Sr. Specialist
> 
> > On Fri May 01 17:25:04 2026, [e-mail] wrote:
> > > Hello IANA,
> > >
> > > I would like to register the URI scheme "agtp" in the provisional
> > > URI
> > > schemes registry per the procedures in RFC 7595.
> > >
> > > Below is the registration template completed per RFC 7595 §7.4.
> > >
> > > URI scheme name: agtp
> > >
> > > Status: provisional
> > >
> > > Applications/protocols that use this scheme name:
> > >
> > > The Agent Transfer Protocol (AGTP), an application-layer protocol
> > > for AI agent traffic. AGTP is specified in Internet-Draft
> > > draft-hood-independent-agtp-06 (Independent Submission Stream).
> > >
> > > AGTP URIs identify AI agents by their canonical 256-bit
> > > cryptographic identifier (the agent-id URI component,
> > > rendered as the agent_id field in the corresponding Agent
> > > Document body). Resolution proceeds via an AGTP registry
> > > service that maps the Agent ID to a serving host:port, after which
> > > the client opens a TLS-protected connection to that host on the
> > > IANA-registered AGTP port (4480/TCP for `agtp`, 4480/UDP for
> > > `agtp-quic`) and exchanges AGTP wire-format messages.
> > >
> > > Contact:
> > > Chris Hood
> > > [e-mail]
> > >
> > > Change controller:
> > > Chris Hood (provisional registration; permanent registration would
> > > require a published RFC).
> > >
> > > References:
> > >
> > > [AGTP] Hood, C., "Agent Transfer Protocol (AGTP)",
> > > >> Work in Progress, Internet-Draft,
> > > >> draft-hood-independent-agtp-06, May 2026.
> > > >> <https://datatracker.ietf.org/doc/draft-hood-independent-agtp/>
> > >
> > > [AGTP-PORT] IANA Service Name and Transport Protocol Port Number
> > > >> Registry, "agtp" and "agtp-quic", port 4480 (TCP/UDP),
> > > >> registered 2026-04-30.
> > >
> > > URI scheme syntax (ABNF, per RFC 5234 and RFC 3986):
> > >
> > > AGTP-URI = "agtp://" agent-id [ "@" host [ ":" port ] ] [ "?" query
> > > ]
> > > agent-id = 64HEXDIG-LC
> > > HEXDIG-LC = DIGIT / %x61-66 ; lowercase hex only
> > > host = <as defined in RFC 3986>
> > > port = <as defined in RFC 3986>
> > > query = <as defined in RFC 3986>
> > >
> > > Examples:
> > > > agtp://
> > d8dc6f0df55d66c7b30100db3cffbe383c5f814e6e58a08521fb7636c3bcc230
> > > > agtp://[e-mail]
> > > > agtp://d8dc6f0d...c3bcc230?format=agent.yaml
> > >
> > > URI scheme semantics:
> > >
> > > AGTP URIs identify AI agents by their canonical 256-bit
> > > cryptographic identifier. It is the canonical, content-addressed
> > > identity of the agent and is intended to remain stable across
> > > the agent's lifetime.
> > >
> > > When the URI lacks an explicit host (Form 1), clients resolve the
> > > agent-id against an AGTP registry service to obtain the serving
> > > host:port. When the URI includes "@host[:port]" (Form 1a), clients
> > > connect directly to the named host, bypassing the registry. Form 1a
> > > is intended for testing and pre-registry deployments.
> > >
> > > Dereferencing an AGTP URI invokes the DESCRIBE method on the
> > > identified agent's serving server. The DESCRIBE method returns the
> > > Agent Document — a structured identity record carrying the agent's
> > > name, principal, capabilities, accepted scopes, status, and issuer.
> > >
> > > The optional `format` query parameter signals the desired
> > > representation of the Agent Document (`agent.json`, `agent.yaml`,
> > > or `html`). Content negotiation via the Accept header is the
> > > canonical mechanism; the query parameter is a convenience.
> > >
> > > Encoding considerations:
> > >
> > > The agent-id component MUST consist solely of 64 lowercase
> > > hexadecimal characters. No percent-encoding is required for the
> > > agent-id since all characters in 0-9 and a-f are in the unreserved
> > > set.
> > >
> > > The host and query components follow standard URI encoding rules
> > > per RFC 3986. AGTP URIs are intended to be transmitted as 7-bit
> > > ASCII; no internationalized identifiers are defined in this
> > > registration.
> > >
> > > Interoperability considerations:
> > >
> > > AGTP is a new protocol with limited deployment as of registration.
> > > A reference implementation is publicly available at
> > > <https://github.com/nomoticai/agtp> with a live deployment at
> > > registry.agtp.io and agents.agtp.io.
> > >
> > > Clients that do not implement AGTP cannot dereference these URIs.
> > > Generic URI parsers can extract the agent-id, host, and query
> > > components per the syntax above without requiring AGTP-specific
> > > knowledge.
> > >
> > > Security considerations:
> > >
> > > AGTP requires TLS 1.3 or higher for all connections to AGTP servers
> > > per the AGTP specification. Plaintext AGTP is permitted only for
> > > development; production deployments MUST encrypt the transport.
> > >
> > > The 256-bit agent-id is content-addressed (derived from a signed
> > > Agent Genesis document in the AGTP-LOG companion specification).
> > > This provides cryptographic integrity for the agent's identity:
> > > the agent-id cannot be claimed by an entity that does not control
> > > the corresponding Genesis document.
> > >
> > > Registry-based resolution (Form 1) introduces a trust dependency
> > > on the registry service. Clients SHOULD verify the registry's TLS
> > > certificate and SHOULD consider supporting multiple registries for
> > > resilience. Form 1a (explicit @host) bypasses the registry and is
> > > appropriate when the client has out-of-band knowledge of the
> > > serving host.
> > >
> > > AGTP URIs should be treated with the same caution as other
> > > resource-locating URIs: dereferencing initiates a network
> > > connection, which has privacy and security implications. AGTP
> > > Agent Documents are public by design (they are the agent's
> > > identity card); they SHOULD NOT be expected to remain confidential.
> > >
> > > Renderings of Agent Documents in the `text/html` representation
> > > are intended for display in trust-aware clients (such as the
> > > reference "elemen" browser). HTML Agent Documents are static
> > > identity cards and SHOULD NOT contain executable scripts;
> > > receiving clients SHOULD render HTML Agent Documents in
> > > sandboxed contexts.
> > >
> > > Thank you for your consideration. Happy to provide additional
> > > information.
> > >
> > > Best regards,
> > > Chris Hood
> > > Author, draft-hood-independent-agtp
> > > [e-mail]