[Kishore-2572]

Draft. Do not merge until the working group confirms the disposition of #24.

What this changes

A commitment now names the proposal and version it was priced against (proposal_id, version, § 5.6.1). The seller rejects a new commitment attempt on a stale version, or past valid_until or pricing[].price_valid_until, and returns the current version so the buyer can fetch it again. A replay of an attempt already processed (same idempotency_key, same terms) returns the stored result without re-running those checks, and the same key with different terms is an explicit conflict, as @aleksUIX suggested on #24. idempotency_key values are opaque and scoped to one buyer and seller pair, in line with iab-agentic-primitives FD-12. § 4.1 states that each revision while published increments version.

Related issue

Refs #24. #23 (draft PR #70) relies on these version rules for "same proposal and version".

Type

• Editorial — no normative effect
• Normative — changes what the spec requires
• Breaking — would break an implementation already built to this draft
• Examples / schema / docs only

Checklist

• The body section is updated
• Appendix A (field index) matches the body — no new rows, as the new keys sit inside commitment; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — counts unchanged
• Any affected example in examples/ is updated and still parses — the display, CTV and audio commitments carry proposal_id and version; § 6.3 points to the CTV example
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — no new selectable or settable fields
• No confidential or commercially sensitive content

Knock-on effects

• Breaking: a commitment without proposal_id and version is rejected.
• Revision on another line item: as written, any revision increments version, so a revision to one line item rejects a commitment on an unchanged one (Postindustria on [Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24). Not resolved here, for the working group:
  • commitment.offer_digest, which depends on the binding record in [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63;
  • per-line-item staleness ([Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65);
  • which changes create a new version ([Change] § 4.1 — Freeze a version's offered terms; changes create version n+1 and a revised entry #64).
• Not included, for the working group:
  • how long a seller keeps idempotency_key values (Postindustria suggests at least until valid_until);
  • moving idempotency_key from commitment to the request (Postindustria on [Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24);
  • the related proposals that a commitment is an offer until the seller accepts it ([Change] § 3, § 5.6.1, Appendix B — A resolved commitment is an offer until the seller accepts #67), whose status gates the freeze ([Change] § 3, § 2.2, § 5.6.1 — Name whose status gates seller-set revisions #60), and proposal_id on every line item ([Change] § 2, § 4.1, § 5.1 — Name the line-item container (line_items[]) and carry proposal_id and seller_id on every line item representation #31).
• Authentication: @aleksUIX's wording said "an authenticated replay". The specification does not define authentication yet (WS1; see [Change] § 5.8 — required_credentials[].scheme is an eligibility credential, not agent authentication #62), so the rule applies to a replay from the same buyer.
• Examples: the commitments use version: 1, matching examples/proposal.yaml.

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.