Extension Key Registry
The Manifest (extensions object) and other AITP wire artifacts permit
agents to advertise non-normative capabilities or out-of-band endpoints
without colliding with normative fields. This registry pins the keys
that AITP-defined extensions use, so independent implementations
discover each other's optional features without ad-hoc string matching.
| Key | Object | Type | RFC | Status |
|---|---|---|---|---|
rfc-aitp-0005.verify_uri | Manifest extensions | HTTPS URL | RFC-AITP-0005 | Provisional |
rfc-aitp-0005.renew_uri | Manifest extensions | HTTPS URL | RFC-AITP-0004 §8.1 (non-normative; eventual standardization reserved as RFC-AITP-0013) | Provisional |
rfc-aitp-0006.delegation_verify_uri | Manifest extensions | HTTPS URL | RFC-AITP-0006 | Provisional |
rfc-aitp-0008.revocation_list_uri | Manifest extensions | HTTPS URL | RFC-AITP-0008 | Provisional |
rfc-aitp-0010.bundle_uri | Manifest extensions | HTTPS URL | RFC-AITP-0010 §4.3 (Draft; post-v0.1) | Provisional |
Rules
- All values MUST be HTTPS URLs except in localhost development mode
(
http://localhost*orhttp://127.0.0.1*), where deployments MAY use plain HTTP for testing. - Extension keys MUST follow the
rfc-aitp-NNNN.<short_name>form when they are introduced by an AITP RFC. Keys outside that namespace SHOULD use vendor-prefixed reverse-domain names (e.g.com.example.feature, per README.md naming conventions). - Unknown extension keys MUST be ignored by consumers (RFC-AITP-0001 §7). Treating an unknown key as a hard failure is non-conformant.
- An extension key being present in this registry does NOT make the underlying extension part of v0.1 conformance. The cited RFC controls conformance scope.
Adding a key
Open a PR adding a row above. Include:
- the key string,
- which wire object hosts it,
- the value type (URL, integer, JSON object, etc.),
- the RFC or document that defines its semantics,
- the status (
Proposed,Provisional,Stable, orDeprecated).