[KonstantinMirin]

What this changes

Draft 1 doesn't say what a rejection carries, or what a reader does with a key the draft doesn't define. This PR answers both.

• § 2.4 defines errors[], one or more ErrorObjects, with ten core codes and a retry value. HTTP fits are informative. A decline isn't an error.
• § 5.5, § 5.6.1, and § 5.6.3 name the code each rejection returns. § 5.6.3 drops the requires cycle ban; our packages PR replaces requires.
• § 2.2 adds Ext, and § 2.5 states its rules. The proposal (§ 4.1) and each line item (§ 5.1) MAY carry ext.
• spec_version is a REQUIRED proposal field (§ 4.1). § 8 question 8 asks how a receiver reads a later release.
• § 2.7 adds informative security considerations.
• The docs word the open questions without a count.
• scripts/check_examples.py checks Ext, and treats ErrorObject as open.

Related issue

Closes #130, a change request from Postindustria (IAB Tech Lab member).

Refs #131, our extensions change request. This PR carries its text, and OQ-8 keeps tracking its question there.

Refs #33, #71, #73, #70.

Builds on

This PR builds on our shared types PR. It carries #71 by @Sirajmx and #73 by @Kishore-2572, at their heads. The merges give their new rows Type and Required cells. #71 drops its catalog_ref clause, and #73's valid_until reads offer_window.end. Review the last commit and the merges of #71 and #73.

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 — § 2, § 2.2, § 2.4, § 2.5, § 2.7, § 4.1, § 5.1, § 5.5, § 5.6.1, § 5.6.3, § 8
• Appendix A (field index) matches the body — three rows: spec_version, and ext on the proposal and the line item; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 33 → 36; 76 → 79 fields
• Any affected example in examples/ is updated and still parses — proposal.yaml gains spec_version and ext, line-item-display.yaml gains ext; scripts/check_examples.py passes
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — it names spec_version among what the proposal supplies; each object carries its own ext
• 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 proposal without spec_version is invalid. So is a key outside ext that a key table doesn't list. A stale or expired commitment returns a code, not prose.
• Filings this answers.
  • ext takes the reserved-container answer of @VJAlkimi's #33. The skip bullet in § 2.5 follows @jaanijuk's implementation evidence.
  • ErrorObject builds on the shape in @VJAlkimi's #32. It answers the asks for a structured error from @aleksUIX and @fgranata on [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25, and from @EvgenyAndroid on #128.
  • Dropping the cycle ban follows our review of #70.
• Changes from the filed text. A record_digest mismatch is record_mismatch, not validation. not_eligible answers [Change] § 2, § 5.5, § 5.6 — One error object for rejections: code, pointer, current version, retry #130's question 4. idempotency_conflict tests "a different body", as § 4.1, § 5.6.1 — Commitments carry proposal_id and version (#24) #73 defines it.
• What later PRs of ours complete.
  • Our lifecycle PR adds record_digest and § 4.1.1, which the record_mismatch row cites. It points stale_version at § 4.1.3, and extends not_committable and not_offered.
  • Our parties PR adds the check behind not_eligible, and the key a seller uses for its own ext entries.
  • Our PR on what is signed makes idempotency_conflict test "a different Commit".
  • Our holds and audience PRs add clauses to not_offered. The audience PR also types exclusions_accepted and exclusions, which stay pending.
  • Our post-agreement PR puts ext on change_requests[] entries (§ 4.4).
• Downstream standards. ext follows OpenRTB 2.6, AdCOM 1.0, and OpenDirect 2.1, and adds keys by owner domain. The binding carries errors[], so nothing ties it to HTTP.

---

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

Analyzed and generated with the help of Claude, fully reviewed by me.