[Sirajmx]

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

What this changes

A buyer can now carry its block lists into the proposal. The seller declares which exclusion types it accepts, how many entries, and how it enforces each (exclusions_accepted, seller-set); the buyer supplies its lists within that declaration (exclusions, supplied): domains, apps, content categories, keywords, or a hash-pinned list_ref for large lists. A type the seller doesn't accept is rejected, never silently ignored, and best_effort enforcement is never presented as a guarantee. Exclusions are recompute inputs (§ 3.3) and are never disclosed to anyone but the buyer (§ 5.8).

Related issue

Refs #25

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 — two rows; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 29 → 30, supplied 3 → 4; 71 → 73 fields; buyer-touched 23 → 24; resolved without a round trip 20 → 21
• Any affected example in examples/ is updated and still parses — the display example declares and supplies lists
• 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) — exclusions is supplied, bounded by exclusions_accepted
• No confidential or commercially sensitive content

Knock-on effects

• App identity. Blocked apps are { platform, bundle }. This goes beyond [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25 as filed, which had a flat list, and comes from the issue's discussion: @aleksUIX proposed it (a bare store id can't say whether it is a Roku or an iOS app), and @fgranata, who first preferred a flat list, agreed on 22 Oct. Both also suggested allowing a flat string where the list declares a single platform; that is not added here and is left to the working group. The platform values match those draft PR § 5.2 — App identity on properties (#15) #17 proposes for properties.available[].apps[].
• Content categories use iab_content_category[] as filed in [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25: IAB Content Taxonomy ids. Which taxonomy version to reference is for the working group. [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48 proposes a version-pinned taxonomy_ref for seller-side content categories.
• CTV example: pending. [Change] § 5.5 — Buyer-supplied block lists (exclusions_accepted, exclusions) #25 asks for the display and CTV examples to be updated, with CTV showing keyword as unsupported or best_effort. Only the display example is updated here, because draft PR § 5.2 — App identity on properties (#15) #17 also edits the CTV example; the CTV change follows once § 5.2 — App identity on properties (#15) #17 lands.
• Guaranteed enforcement is a measurement question, deferred to 4.0 ([Comment] Whole document — Feedback from the Agentic Bootcamp, 24 September 2026 #20 item 9).
• Related: [Change] § 5.2 — separate brand safety / suitability disclosure from content_detail #46 and [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48 (seller-side content signals), [Comment] § 5.2 — Support placement-specific advertising restrictions #53 (OOH placement restrictions).
• Appendix B: other open change requests also change these counts; whichever merges later recounts.

---

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