Resources

Governance

Found a problem or want to extend AEP? Choose a route that matches the effect on the protocol, then give reviewers the evidence they need.

The public aep-specs repository maintains the Internet-Drafts and their supporting artifacts. A typo, an ambiguous rule, a new Grant Type, and a vulnerability need different review. This page directs you to the right process; it does not replace the repository governance policy.

Start with the protocol's source of authority

The Internet-Drafts define AEP behavior. Schemas validate stable wire objects; vectors, examples, guides, and conformance checks help implementers test and understand that behavior. They do not override a draft. If two artifacts disagree, identify the exact requirement and propose a coordinated correction rather than treating an SDK or example as an independent protocol definition.

Evaluate compatibility from wire behavior, not the number of changed files. An editorial correction may leave the protocol unchanged. A changed field, command, error, security rule, or registry entry can affect existing Agents and Services even when the diff is small. AEP protocol versions and official SDK package versions are independent; matching version numbers do not prove compatibility.

Choose the route for your change

Start with the effect you intend, then use the corresponding repository process:

Change	First step
Editorial correction	Open a focused pull request against main. Keep the meaning unchanged and check affected links or generated output.
Ambiguous or changed core behavior	Open an issue or discussion first. State the ambiguity or proposed wire change and its Agent–Service compatibility effect before drafting a solution.
Grant Type, identity method, binding, or extension	Use the appropriate specification class and registration guidance. Define advertisement, messages, errors, security behavior, and support artifacts for the new capability.
Security-sensitive flaw	Report it privately under the security policy. Do not publish an exploitable authentication, replay, credential, or identity-probing issue first.

For ordinary pull requests, follow Contributing. A new Internet-Draft uses the draft addition guide; a revision of a published draft uses the draft revision guide.

Bring the affected artifacts into review

A protocol proposal should say which wire behavior changes, which Agents and Services are affected, and whether it changes authentication, privacy, replay protection, anti-enumeration, or credential handling. Identify the draft sections and update relevant schemas, vectors, examples, registry entries, and conformance checks when they encode the changed behavior. A clarification needs the same alignment check even when its intended behavior stays the same.

Run the repository check from the root of aep-specs after installing its documented build dependencies:

make -C ietf check

This checks draft structure and supporting artifacts; it does not decide whether a proposed behavior is desirable or backward compatible. If you changed a published draft, also follow the revision guide's render, reference, date, and publication checks. Review the final diff, including intentionally generated website files, before requesting review.

Separate registration from publication

The repository-local registry records AEP identifiers as governance support. The extension registration guidance describes proposals while formal IANA registries are not yet established. Once an applicable IANA registry and its review process exist, they take precedence over this temporary process. An extension cannot redefine core command semantics or core authentication rules simply by registering a new identifier.

Merging a repository pull request does not itself publish a new Internet-Draft revision. The IETF Datatracker determines what revision is published. The addition and revision guides cover the separate preparation, rendering, and submission work; keep repository links and support artifacts aligned with the revision that is actually published.

Use the policy for the question at hand

Use Governance for change classes and compatibility review; Contributing for pull-request preparation; and extension registration for a new protocol capability. The SDK support policy addresses language releases and maintenance, not changes to the protocol draft. For a security-sensitive issue, use the private reporting route.