OQ-1 — Does per-field mutability belong in 3.0? #2

Activity

1. Sirajmx

   added

   open-questionRelates to one of the 7 open questions in § 8Relates to one of the 7 open questions in § 8

   section:3-mutability

   on Sep 24, 2026
2. Sirajmx

   added a commit that references this issue on Sep 24, 2026

   Link the seven open-question tracking issues

   ...

   ebb9e2f
3. Sirajmx

   pinned this issue on Sep 24, 2026
4. aleksUIX commented on Oct 14, 2026

   

   aleksUIX

   on Oct 14, 2026

   More actions

   The per-field model needs a rule for combinations of choices, not only membership in each available[] list.

   Consider a seller offering two audiences and two activation routes. Both audiences appear in audiences.available[], and both routes appear in activation_route.available[], but one audience can be activated only through the clean room. Selecting that audience with publisher_side passes the independent membership checks and still produces a composition the seller cannot deliver. This is a constructed example.

   properties.available[].supported_formats already describes one such relationship. Is the intention that every other combination of declared choices is valid, or can the seller declare additional dependencies?

   For 3.0, I would require all restrictions needed to validate a composition to be available in the full representation. Where the specification cannot express a restriction, the seller should publish separate line items with compatible choices. An invalid combination should be rejected with the conflicting fields identified, without silently replacing the buyer's selections.

   That would preserve the claim that composition resolves locally. It is separate from #23, which links different line items, and builds on the selection syntax in #22.

   Commenting in a personal capacity.
5. dtbarne commented on Oct 22, 2026

   

   dtbarne

   on Oct 22, 2026

   More actions

   For a line item bought through an SSP, the seller has to set up the agreed deal against a specific DSP and seat. The draft doesn't say what the identifiers in these fields refer to. The example uses dsp-a, dsp-a-prod and seat-99812, which read as placeholders. A seller agent receiving them has no way to tell which DSP is meant without a lookup agreed outside the protocol.

   Defining some standards could help:

   • dsp_id and dsp_allowed[]: state what the value identifies, for example the DSP's primary domain, or an IAB Tech Lab registry id once one exists for DSPs. Either works if the spec names it.
   • dsp_seat_id: the seat id as the DSP issues it, the same value OpenRTB 2.6 carries in deal.wseat. It is only meaningful together with dsp_id, and the spec should say so.
   • eligible_bidders[] versus dsp_allowed[]: § 5.8 lists "permitted seat or buyer ids" and § 5.9 lists allowed DSPs. Both restrict who can buy, with overlapping meanings. Either say how they combine, or fold one into the other.

   Concrete scenario

   A buyer agent commits to a preferred deal with dsp_id: "dsp-a-prod" and dsp_seat_id: "seat-99812". To create the deal and sync it to the DSP, the seller has to map dsp-a-prod to one of its connected DSPs by hand. If the draft said dsp_id is the DSP's domain, the deal could be set up from the agreed proposal alone.
6. KonstantinMirin commented on Nov 4, 2026

   

   KonstantinMirin

   on Nov 4, 2026

   More actions

   Postindustria (IAB Tech Lab member): yes, per-field mutability belongs in 3.0. Our filings rest on § 3's markers: #60 (who revises what), #64 (a version's terms stay frozen), #68 (what stays fixed after agreed), and #91 and #99 (selectable fields).

   On @aleksUIX's question: every combination is valid, apart from rules the spec states. The coming selection PR says options of different fields combine freely. A seller whose options don't combine publishes separate line items. The PR removes supported_formats, so the spec has no syntax for dependencies between options.

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