[KonstantinMirin]

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

What this changes

A line item states what every impression is: rewarded, interstitial, video placement subtype, skippability, playback, API frameworks, and refresh. New § 5.2.1 defines placement, a seller-set object keyed to AdCOM 1.0 Placement and OpenRTB 2.6 Imp.

• A present key holds for every impression. An absent key doesn't constrain it.
• The seller MUST NOT deliver the line item to an impression that doesn't match a present key. The text defines a match for each key.
• plcmt is REQUIRED for video ads.
• Unless api[] includes OMID 1.0 (7), a line item that commits viewable_rate on app_mobile or ctv SHOULD NOT offer a third-party measurement_source.
• The Summary Representation (§ 2.1) carries reward, instl, plcmt, and skip when present.

New § 6.5 shows placement on in-app rewarded video.

Related issue

Refs #89, a change request from Postindustria (IAB Tech Lab member).

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.1, § 5.2 and new § 5.2.1, new § 6.5
• Appendix A (field index) matches the body — one row, placement seller-set; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — seller-set 29 → 30; 71 → 72 fields
• Any affected example in examples/ is updated and still parses — the CTV example gains placement: { plcmt: 1 } (Instream (1)); new line-item-rewarded-video.yaml (§ 6.5)
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — placement sits on the line item; nothing comes from the proposal or a property
• 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

• Answered on [Change] § 5.2 — Say what each impression is: rewarded, interstitial, video placement, skippability, API frameworks, refresh #89. @fgranata confirms that they hold these keys per placement. placement sits on the line item, and a multi-app line item omits the keys its apps don't share. An absent reward or instl means either value, and maps to one OpenDirect 2.1 Placement per value. The OM SDK rule stays a SHOULD, because some vendors still measure in-app with their own SDKs.
• What builds on this PR. This PR merges first. Our video and audio PR then makes these changes:
  • placement is REQUIRED when channel is video or audio, and plcmt is REQUIRED when channel is video.
  • feed, which our audio change request (#101) defines, joins placement.
  • placement.ssai replaces the client_side and ssai terms of serving_mode.
• Measurement. Our settlement PR replaces the measurement_source vendor with measured_by, where a seller writes seller. The OM SDK rule then reads "an option whose measured_by is not seller".
• OQ-4 — The format registry has no entries for audio/*, ctv/* or dooh/* #5. placement answers @fgranata's either/or on OQ-4 — The format registry has no entries for audio/*, ctv/* or dooh/* #5 without a placement_type enum or placement in format ids.
• Channels. Our channel definitions PR (#119) puts Connected Device (6) in ctv, so the OM SDK rule's ctv covers it.
• Merging with other open PRs.
  • § 2.1, § 5.1, § 5.2 — Define channel and environments in AdCOM terms (#90) #119 also adds a § 5.2.1 and edits the § 5.2 table beside the new row. environments keeps § 5.2.1 and placement becomes § 5.2.2, whichever merges first.
  • § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 and § 2.3 — Static manifest at a well-known URL for standard proposals (#29) #76 each add a § 6.5, so the rewarded example becomes § 6.7 after both.
  • Whichever of this PR and § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 merges later adds placement: { plcmt: 1 } (Instream (1)) to line-item-ctv-bonus.yaml. Likewise with § 2.3 — Static manifest at a well-known URL for standard proposals (#29) #76 for its weather-app-ctv manifest entry.
  • Whichever of this PR and § 5.2 — App identity on properties (#15) #17 merges later gives puzzle-pack an apps[] entry, and moves § 5.2 — App identity on properties (#15) #17's App identity paragraph above § 5.2.1.

For the working group

Open on #89 and its supporting material:

1. Should the OM SDK rule also cover a controlling_measurement option whose counted_by is not seller (our settlement change request (#95)), or stay limited to measurement_source? (#89, question 2)
2. When @unreconciled's interactive and verification format spec keys on #5 and placement.api[] disagree, which governs, or should the spec carry only one? (#89, question 4)
3. Should creative review check MRAID and SIMID creatives against placement.api[], although #32 limits review to content and policy? (#89 supporting material, question 1)
4. Should app-open ads get a value in AdCOM, or stay a registry format id with instl: 1? (#89 supporting material, question 2)
5. Should plcmt be REQUIRED on dooh video line items, and on native line items with video assets? Our channel definitions PR (#119) assigns them to those channels, where plcmt stays OPTIONAL. The OpenRTB 2.6 implementation guide's DOOH video example sends no plcmt. (#89 supporting material, question 3)
6. Should refresh stay one minimum interval, or also name the triggers in AdCOM List: Auto Refresh Triggers? (#89 supporting material, question 4)
7. Answered in our video and audio PR. No field says whether a ctv line item sells video, which the REQUIRED condition on plcmt depends on. Should the condition key on the format ids in formats.available[], or should plcmt be RECOMMENDED on ctv? Neither: plcmt is REQUIRED when channel is video, and its presence states that a line item is video. (#89, question 6)
8. Should plcmt stay one value, or become plcmt[], like playmethod[]? As one value, a video line item whose impressions differ in plcmt splits into one line item per value, as @fgranata does when apps disagree. (#89, question 7)

---

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

Revised 2026-11-03: Rewritten against the PRs that build on this one: knock-on effects say what our video and audio PR and our settlement PR change here. Question 7 is answered, and question 1 uses counted_by.

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