[KonstantinMirin]

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

What this changes

channel and environments now have definitions, in AdCOM 1.0 terms, so two sellers give the same impression the same label and a buyer can check delivery against it. A first-match table (§ 5.1.1) gives each impression one channel from its distribution channel, the media of the ad served, and its device type. Each environment (§ 5.2.1) is a set of (distribution channel, device type) pairs. The six channel labels stay. audio_streaming is removed, and the Summary Representation (§ 2.1) carries environments.available[].

Related issue

Refs #90, a change request from Postindustria (IAB Tech Lab member). The text follows #90 as revised on the thread: ctv covers Connected TV (3), Connected Device (6), and Set Top Box (7), and there is no connected_device value. Proposes a definition rule for OQ-7 (#8, from @Sirajmx), removes audio_streaming, and leaves the rest of the value list, such as app_tablet, to #8.

The text states some points of #90 more precisely, without changing what #90 asks for:

• [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 says a consumer MUST skip an unknown channel, "not reject the proposal". The text states that outright as MUST NOT reject.
• [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 says "A line item MUST serve only impressions of its channel". The text names the seller as the party that serves.
• An impression that accepts several media, such as banner and video, takes its media from the ad served. Otherwise a display line item could never serve multi-format inventory.
• Linear TV is outside the table, so addressable linear on a Set Top Box (7) does not match the ctv row.
• Each environment is a set of (distribution channel, device type) pairs, as in the #90 supporting material, and not two independent lists.

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.1 and new § 5.1.1, § 5.2 and new § 5.2.1
• Appendix A (field index) matches the body — no field added and no marker changed; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — counts unchanged, 71 fields
• Any affected example in examples/ is updated and still parses — the audio example lists web_mobile and app_mobile in place of audio_streaming; the CTV and display examples already conform, and so do the examples in PR § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 (CTV bonus line) and the PR for [Change] § 5.2 — Say what each impression is: rewarded, interstitial, video placement, skippability, API frameworks, refresh #89 (rewarded video)
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds — each line item states its own channel and environments
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — environments stays selectable; no new fields
• No confidential or commercially sensitive content

Knock-on effects

• Breaking. audio_streaming is removed. A video line item can no longer select ctv, because a video ad on a TV device is ctv.
• Allowed pairs. The consistency rule in § 5.2.1 allows these environments per channel: display, video, and native select web_desktop, web_mobile, or app_mobile. audio selects those three or ctv. ctv selects only ctv, and dooh selects only dooh.
• Cross-screen video becomes a video and a ctv line item, tied by linked_execution or requires from [Change] § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (linked_execution, requires) #23 (@Sirajmx, PR § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70). @fgranata reports on #90 that their exchange already sells TV as its own lane by device type Connected TV (3), Connected Device (6), or Set Top Box (7), and withdraws the alternative raised on OQ-7 — environments[] needs validation against real inventory #8.
• ctv in both fields. @fgranata noted on #8 that ctv and audio_streaming repeat the channel. audio_streaming goes. ctv stays in both, because frequency_cap.basis and serving_mode differ on TV, and an audio line item can select the ctv environment.
• dooh in both fields. @premesh makes the same point for dooh on #8: once channel: dooh is set, the dooh environment says nothing more, and buyers filter on venue type. @premesh proposes pointing the DOOH environment at the OpenOOH venue taxonomy that OpenRTB 2.6 carries in venuetax and venuetypeid. This PR keeps dooh as [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 filed it. See question 10.
• Device targeting. A seller that separates consoles and streaming devices from TVs narrows with device (§ 5.5). Postindustria's reply on #58 (typed geo codes, from @dtbarne) proposes to type device on AdCOM device types. On main, device is still an untyped list of device categories.
• Linear TV has no value in 3.0. Its scope stays with [Comment] § 1, § 5.1 — State whether linear and addressable linear TV are in scope for 3.0-line summary #44 (@bhillman-TelevisaUnivision); if [Comment] § 1, § 5.1 — State whether linear and addressable linear TV are in scope for 3.0-line summary #44 brings it in, a later change adds a value with its own condition.
• Uncovered pairs. These impressions match no environment: an App on a Personal Computer (2), a Site or App on an OOH Device (8), and any Site or App impression that carries no device type.
• Downstream. Each condition maps to OpenRTB 2.6: site, app, or dooh; the imp media objects and, for the ad served, bid.mtype; device.devicetype. device.devicetype is optional there, so the label is checkable only where the impression carries it. See question 11.
• Format namespace. § 5.4 namespaces format ids by channel. The namespace follows the line item's channel, as the CTV example's ctv/instream-15s already does, so a static pause ad on TV is a ctv/ format and a video spot on a transit screen is a dooh/ format.
• Summary Representation. The summary carries environments.available[], the offered set, while it carries formats.included[], the base-rate set. [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 asks for the offered set because screening is on where the line item can run. As for the other summary keys, the § 5.2 row is not marked REQUIRED, but the summary can't be built without environments.
• Docs. docs/open-questions.md OQ-7 drops audio_streaming from its list and points to § 5.2.1. OQ-7 stays open.
• Other PRs.
  • PR § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 (@Sirajmx) appends has_requires to the same § 2.1 list. This PR inserts its key without rewrapping the list, so the two merge cleanly.
  • The PR for [Change] § 5.2 — Say what each impression is: rewarded, interstitial, video placement, skippability, API frameworks, refresh #89 also adds a § 5.2.1 (placement). Because the environments row comes before the placement row, environments stays § 5.2.1 and placement becomes § 5.2.2. If [Change] § 5.2 — Say what each impression is: rewarded, interstitial, video placement, skippability, API frameworks, refresh #89 merges first, this PR renumbers it and updates its one reference, See 5.2.1 in the § 5.2 placement row. The § 2.1 additions of the two PRs merge cleanly.
  • PR § 5.2 — App identity on properties (#15) #17 (@Sirajmx) adds an App identity block after the § 5.2 table. Git merges the two without a conflict but puts App identity under § 5.2.1. App identity belongs directly under the § 5.2 table, above § 5.2.1; whichever PR merges second moves it.
  • PR § 2.3 — Static manifest at a well-known URL for standard proposals (#29) #76 (@Kishore-2572) publishes Summary Representations in its manifest. Once both merge, examples/manifest.json gains environments.available[]: ["ctv"] on weather-app-ctv, and ["web_mobile", "app_mobile"] on streaming-audio.

For the working group

Open on #90 and its supporting material:

1. Keep the six channel labels with the first-match table, or replace channel now with separate media, distribution, and device fields? (#90, question 1)

2. Is the first-match order right: audio before ctv, and native before video? @fgranata takes no position on audio. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 2)

3. Should this change drop audio_streaming, or should OQ-7 (OQ-7 — environments[] needs validation against real inventory #8) settle the value list, including app_tablet, which @fgranata asks for on #8? The connected_device part is answered in our device-type revision: no value is added. app_tv in place of ctv belonged to the alternative @fgranata withdrew on [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 4)

4. When a consumer skips a line item with an unknown channel, should the text say it can't commit a [Change] § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (linked_execution, requires) #23 linked_execution or requires, or a commitment set, that contains it? ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 5)

5. Add an app_desktop row (App on Personal Computer (2)) now, or wait for OQ-7 — environments[] needs validation against real inventory #8? ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 supporting material, question 2)

6. Should a seller delivering a ctv line item send device.devicetype (SHOULD), since OpenRTB 2.6 makes it optional? ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 supporting material, question 3)

7. Should native stay a channel value, or fold into display as AdCOM does? ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 supporting material, question 4)

8. Must a channel value's condition be stated in AdCOM terms, or may OpenProposal define its own condition? Static OOH ([Comment] § 1 — Add OOH as a distinct channel alongside DOOH #49, from @clerongi) and print ([Change] § 1.1, § 5.1, § 5.9, new § 5.11 — Add a print channel: enum, print extension object, downstream row #102) no longer wait on this: our print and OOH revision puts them outside the first-match table (question 15). ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 supporting material, question 5)

9. Is audio over a DOOH venue's speakers dooh or audio? It ties to the screen-based properties in [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 supporting material, question 6)

10. Should dooh stay an environment value, which repeats channel: dooh, or should the DOOH environment use the OpenOOH venue taxonomy (venuetax, venuetypeid), as @premesh proposes on #8? This PR keeps dooh as filed.

11. Should channel stay a closed list with a skip rule, or become an open, namespaced vocabulary like the one [Change] § 5.6 — Give cost_method an extensible vocabulary, and say what several pricing[] entries mean #94 proposes for cost_method? The channel row is still typed Enum, so a schema built from it rejects a value that the skip rule tells a consumer to skip. environments has no skip rule, though OQ-7 — environments[] needs validation against real inventory #8 expects more values. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 supporting material, question 7)

12. With Connected Device (6) in ctv, a smart-speaker audio line item selects the ctv environment. Is that intended, or does audio on connected devices need its own value? This follows from the #90 revision. The audio example leaves out smart speakers to avoid the question. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 7)

13. What happens when an impression doesn't carry an attribute that a condition names? A TV video impression without device.devicetype falls through to video, and an impression without a device type matches no environment except dooh. Should a missing attribute fail the condition, or should the seller classify the impression from what it knows about the property? This goes with question 6. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 8)

14. Should an impression served to a line item stay within the line item's selected environments, as well as its channel? § 5.2.1 constrains which environments a line item may offer, not where it serves. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 9)

15. Channels without an AdCOM impression. Print ([Change] § 1.1, § 5.1, § 5.9, new § 5.11 — Add a print channel: enum, print extension object, downstream row #102, from @matthew-iabtechlab) and static OOH ([Comment] § 1 — Add OOH as a distinct channel alongside DOOH #49, from @clerongi, with @premesh's proof-of-posting scenario) sell inventory with no ad-served impression. Our print and OOH revision on [Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90 puts such channels outside the first-match table and the environment rule, with delivery shown by proof of performance. A field with no meaning for such a channel is absent from its line items. The revision asks whether proof of performance is one field across channels or part of each channel's own object. This PR's text doesn't include it. ([Change] § 5.1, § 5.2 — Define channel and environments in AdCOM terms, so one impression gets one label #90, question 6)

Answered on #90: a cross-screen deal is two line items (#90, question 3, answered by @fgranata), and Connected Device (6) belongs to ctv (#90 supporting material, question 1, answered in our device-type revision).

---

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.