Start here — OpenProposal 3.0 public comment (closes 2026-10-22) #11

Activity

1. Sirajmx

   pinned this issue on Sep 24, 2026
2. KonstantinMirin commented on Oct 25, 2026

   

   KonstantinMirin

   on Oct 25, 2026

   Last edited by KonstantinMirin

   More actions

   Postindustria (IAB Tech Lab member) offers this map of our filings, grouped so the working group can read them by topic. Our schema implementation feedback (#121) applies to every group.

   How the groups depend on each other

   An arrow points from a group to the group it relies on.

   flowchart LR
       LC["Lifecycle and the binding record"]
       ID["Identity and transport"]
       PR["Pricing and composition"]
       DG["Delivery and guarantees"]
       CH["Channels and placements"]
       DO["DOOH"]
       TA["Targeting and audiences"]
       LC <-->|"signer, record_digest"| ID
       PR -->|"acceptance, record"| LC
       DG -->|"baseline after agreed"| LC
       DG -->|"cost methods"| PR
       TA -->|"rate derivation"| PR
       CH -->|"device codes"| TA
       CH -->|"measurement"| DG
       DO -->|"dooh channel"| CH
       DO -->|"share of voice, counter"| DG
       DO -->|"PLAY cost method"| PR
   

   Loading

   Lifecycle and the binding record

   What both parties agree to, and who moves each status.

   1. Scope comment (#59): which Proposal definition governs what.
   2. Binding record (#63): record_digest and signed assent[].
   3. Frozen versions (#64): a change creates a new version.
   4. Seller-set gate (#60): whose status gates a seller revision.
   5. Assent digest reply (#45): revisions can't alter agreed line items.
   6. Commitment acceptance (#67): an offer until the seller accepts.
   7. Lifecycle (#65): who moves each status.
   8. Commitment digest reply (#24): offer_digest and one replay rule.
   9. Issued proposals reply (#26): a proposal issued to that buyer.
   10. Hold states (#66): refused, and re-entry to requested.
   11. Agreed baseline (#68): agreed is terminal.
   12. Change-path reply to @dineshbhat (#68): a change-path column in § 1.1.
   13. Operations table reply to @dineshbhat (#113): maps to [Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65, [Change] § 5.6.2 — hold_status needs refused and re-entry to requested #66, and [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63.
   14. Dated inventory reply to @matthew-iabtechlab (#105): date moves after agreed go downstream.
   15. External references reply to @franks33 (#124): external_references stay unsigned.
   16. Error object (#130): one rejection object with a retry rule.
   17. ext container (#131): @VJAlkimi's ext, keyed by domain.
   18. Deal handoff (#132): deal ID, origin, and buyer seats.
   19. Flight dates reply to @EvgenyAndroid (#127): flight_end is inclusive.
   20. Idempotency reply to @EvgenyAndroid (#128): their retention floor matches [Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24.

   Identity and transport

   Name the seller by domain; leave signing to one AAMP profile.

   1. Seller identity (#61): seller_domain identifies the seller.
   2. Signing profile (AAMP #3): IETF Web Bot Auth as one profile.
   3. Credential schemes (#62): eligibility, not agent authentication.
   4. Manifest reply (#29): binds the well-known file to seller_domain.
   5. Authorization evidence reply (#57): the mandate binds to record_digest.
   6. Seller relationship (#88): checkable against ads.txt and sellers.json.
   7. Delegation reply to @aeoess (AAMP #3): identity is not authority.
   8. Delegation answers to @aeoess (#57): a commitment must fit every delegation link.
   9. Attestations reply to @peterduhon (#116): a buyer agent's reference is a claim.

   Pricing and composition

   What a rate counts, and how line items share terms.

   1. Counter and floor reply (#30): composes floor like agreed_rate.
   2. Floor and rate-basis reply (#30): a visible floor is a posted offer.
   3. Cost methods (#94): an extensible cost_method vocabulary.
   4. Commitment-set reply (#23): one currency, whole acceptance.
   5. Cross-media package reply (#86): maps asks to commitment sets.
   6. Cancellation and exclusivity (#98): stepped fee[] tiers.
   7. Cancellation penalties reply (#85): 60-, 30-, and 7-day tiers.
   8. Ordered adjustments reply to @matthew-iabtechlab (#103): machine-readable rate conditions.
   9. commitment.amount reply to @dineshbhat (#115): conflicts with [Change] § 5.6 — Give cost_method an extensible vocabulary, and say what several pricing[] entries mean #94.
   10. CTV pod reply to @franks33 (#5): [Change] § 5.6 — Give cancellation_policy and exclusivity options a typed shape #98 sells in-pod separation.
   11. Deal price (#133): agreed_rate as dealfloor.
   12. Review of @Sirajmx's PR (#18): points to [Change] § 5.6, § 1.1, § 2.1 — Say which price a deal carries: agreed_rate as the Deals API dealfloor, with its pricetype; rename floor to min_rate #133.

   Delivery and guarantees

   What the seller promises, and whose count settles it.

   1. Delivery type (#93): a seller-set delivery_type.
   2. Settlement (#95): metric direction and remedy order.
   3. Audience counts reply (#38): podcasts count server-log downloads.
   4. Delivery schedule reply to @dineshbhat (#114): a seller-set binding flag per phase.

   Channels and placements

   Label each impression in AdCOM terms.

   1. Channel definitions (#90): values by AdCOM channel and device type.
   2. Impression placement (#89): a placement object.
   3. Format spec versions (#87): pins format spec versions.
   4. Creative approval reply (#32): approvers, and what silence means.
   5. Break position (#99): pre-roll, mid-roll, and pod slot.
   6. Programs and live events (#100): what happens if one doesn't air.
   7. Audio feed (#101): when an ad is recorded in.
   8. Print channel reply to @matthew-iabtechlab (#102): circulation guarantees settle under [Change] § 5.7 — Make a guarantee settleable: direction, controlling measurement, remedy order #95.
   9. Channel definitions PR (#119) and placement PR (#120): implement [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 and [Change] § 5.2 — Say what each impression is: rewarded, interstitial, video placement, skippability, API frameworks, refresh #89.

   DOOH

   Define a play, and how plays become impressions.

   1. DOOH properties (#96): venue, screens, hours, loop, and allocation.
   2. Plays and impressions (#92): defines a play and its multiplier.
   3. Screen loop reply (#79): how the loop sets plays.
   4. Station-level buying reply (#81): a station is a selectable property.
   5. OTS-based CPM reply (#82): what a DOOH CPM must state.
   6. Physical availability reply (#77): maps three of four asks.
   7. Second reply (#79): points to the [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96 and [Change] § 5.9, § 5.6, § 2.1 — Add delivery_type: guaranteed, share_of_voice, non_guaranteed #93 revisions.
   8. Third reply to @premesh (#79): points to dayparted share of voice.
   9. Categories reply to @esteininger (#96): categories follow [Change] § 5.2, § 5.5: Structured content categories (taxonomy_ref) on inventory, and a contextual targeting bound #48.
   10. Venue type pointer to @premesh (#8): [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96 puts venue type on each property.
   11. Sync groups reply to @premesh (#92): folds sync groups into plays.
   12. Static OOH reply to @premesh (#125): proof of posting uses [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90's one proof_of_performance object.
   13. DOOH test reply to @jaanijuk (#134): a metric term says rate or count.

   Targeting and audiences

   Type targeting values; say how audiences combine and disclose.

   1. Typed targeting reply (#58): dayparts, device types, and frequency periods.
   2. Audience combination (#91): AND or OR from seller-declared operators.
   3. Audience disclosure (#97): reuses the Data Transparency Standard label.
   4. Device and daypart reply to @dineshbhat (#111): agrees on device types; differs on midnight.
   5. Daypart clock PR (#123): implements our [Change] § 5.5 — Typed geo codes aligned with the OpenRTB 2.6 Geo object #58 daypart clock.

   The seven open questions

   Open question	Our filings
   OQ-1: mutability (#2)	No direct answer; #60, #64, and #68 build on § 3 markers.
   OQ-2: catalogs (#3)	No direct answer; #60 and #87 shape the catalog freeze.
   OQ-3: cross-channel guarantees (#4)	No direct answer; our #86 reply asks if it belongs here.
   OQ-4: format registry (#5)	#87 pins versions; #89 keeps placement out of format IDs.
   OQ-5: min_line_items (#6)	Our #23 reply: linked_execution: all is one set.
   OQ-6: payment terms (#7)	No direct answer.
   OQ-7: environments[] (#8)	#90 gives a definition rule.

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