Skip to content

§ 5.2.4 to § 5.2.8 — Property option: seller relationship, app identity, and screens (#88) - #149

Open
KonstantinMirin wants to merge 268 commits into
IABTechLab:mainfrom
KonstantinMirin:op30-property-option
Open

KonstantinMirin wants to merge 268 commits into
IABTechLab:mainfrom
KonstantinMirin:op30-property-option

Conversation

@KonstantinMirin

@KonstantinMirin KonstantinMirin commented Nov 4, 2026 •

Copy link
Copy Markdown

What this changes

Draft 1 lets a seller list any domain without saying by what right it sells it. Its property keys sit in prose. This PR gives the property option one key table, and each part of it a numbered section.

  • § 5.2.4: PropertyOption has one key table. Each property states seller_relationship and child_audience, and carries domains[], apps[], or both. When properties is absent, the seller promises no property.
  • § 5.2.4: a property MAY carry tv_channel and tv_network, AdCOM 1.0 Channel and Network matched by domain, so a buyer can tell when two sellers offer one channel, from @unreconciled, who corrected the matching key.
  • § 5.2.5: AppId is { store, bundle }, and App adds store_url and developer_domain. store, a VocabularyTerm, names the app store.
  • § 5.2.6: a buyer can check the seller relationship against the governing ads.txt or app-ads.txt. SellerAccount names the accounts it checks. An app's governing developer domain comes from its store listing.
  • § 5.2.7: child-directed status, and what it means for audiences and buyer-supplied data.
  • § 5.2.8: the DOOH keys move into Screen, Loop, and SyncGroup tables.
  • § 5.5: a block list's app_bundle[] becomes apps[] of AppId.
  • § 2.6: a key table follows a bold lead-in that names its type, and the type of an object option ends Option. scripts/check_appendix.py lints both.
  • § 2.1: a summary lists each property's apps, child_audience, and seller_relationship. § 2.7 covers store_url as an author-chosen URL.

Related issue

Closes #88.

Refs #15, #17, #96, #97, and #71.

Builds on

This PR builds on our DOOH PR and, through it, on these PRs of ours:

It merges #17 by @Sirajmx. Through our PRs it carries #18, #70, #71, and #72 by @Sirajmx, #73, #74, #75, and #76 by @Kishore-2572, and #117 and #118 by @aleksUIX. Review the commits "Give the property option one key table and one app identity", "Let a property name the TV channel and network it carries", "Match TV channels and networks by domain", "Record the property option changes the changelog left out", "Write the movable condition on lat and lon as a value", and "Reject coordinates on a movable screen".

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, § 2.6, § 2.7, § 5.2, new § 5.2.4 to § 5.2.8, § 5.5, § 5.6, and § 5.6.4
  • Appendix A (field index) matches the body — no field is added or removed, and properties keeps Selectable[PropertyOption]; scripts/check_appendix.py passes
  • Appendix B (fields by marker, and the counts) matches the body — no marker or count changes
  • Any affected example in examples/ is updated and still parses. Each property gains seller_relationship, child_audience, and seller_accounts[]. platform: roku becomes store: roku_channel_store, and the audio example names a property. manifest.json is regenerated, and both proposal examples carry a recomputed record_digest. scripts/check_examples.py reads the new tables and passes. scripts/check_pricing_fixtures.py passes 60 of 60
  • RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms. The MUST and SHOULD sentences are those filed in [Change] § 5.2 — State the seller's relationship to each property, checkable against ads.txt #88, [Change] § 5.2, § 5.5 — DOOH properties: venue type, screens, operating hours, and loop #96, and [Change] § 5.2, § 5.3 — Disclose audience taxonomy, data label, sensitive categories, and child-directed properties #97. The block list rejects an entry whose store the seller doesn't know.
  • The no-inheritance rule (§ 2) still holds — every key sits on its property option; nothing comes from the proposal
  • Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — properties keeps both; no new selectable or settable fields
  • No confidential or commercially sensitive content

Knock-on effects

Open questions

  1. [Change] § 5.2 — State the seller's relationship to each property, checkable against ads.txt #88's questions 1, 2, 3, and 5 carry over to this PR. It follows the filed proposal on 2 and 3: seller_relationship is REQUIRED, and inventory_partner_domain sits on the property. Question 4 is settled here: this PR merges § 5.2 — App identity on properties (#15) #17 and makes developer_domain informative.
  2. properties is OPTIONAL, so a line item with no property states no seller relationship or child-directed status. Should properties be REQUIRED, so that every line item states a seller relationship and a child-directed status?

Contribution Terms

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

aleksUIX and others added 30 commits October 24, 2026 11:37
Read the media condition from the ad served when an impression accepts
several media, name the seller as the party that serves, place linear TV
outside the table, and state environments as (distribution channel,
device type) pairs. Insert environments.available[] into the summary
list without rewrapping it, shorten the changelog entry and drop
audio_streaming from OQ-7 in docs/open-questions.md.

Refs IABTechLab#90
time_zone is the line item's clock for daypart windows and
frequency_cap.period: an IANA time zone name or viewer_local. A window
is { days[], start, end } in civil time with an exclusive end later
than start, up to 24:00; a window that crosses midnight is two windows.
List the `days[]` values once in the `daypart` row, as `monday` | ... |
`sunday`. Write HH:MM, America/New_York, and UTC as plain text, since
they're a format and examples, not field names. The meaning is
unchanged.
"At least one of" an empty list is never satisfied, so the bonus line
would fail a literal check. An absent key sets no condition. Only the
examples change; the any_of[] row and the rules stay as filed in IABTechLab#23.

Refs IABTechLab#23
The floor row now says it "neither constrains nor describes the
downstream auction floor", as IABTechLab#16 asked, and names that floor: the
per-impression floor the exchange applies at auction time (OpenRTB 2.6
Imp.bidfloor).

Refs IABTechLab#16
- Rename apps[].domain to developer_domain, as IABTechLab#15 filed it. It is the
  developer domain from the store listing that app-ads.txt uses, not
  OpenRTB 2.6 app.domain, which is the domain of the app.
- Define platform as the store that issued bundle, since a bundle is
  unique only within its store.
- List apps[].platform and apps[].bundle in the Summary Representation
  (section 2.1), as IABTechLab#15 asked.

Refs IABTechLab#15
From the Postindustria review on IABTechLab#73:
- a replay matches on the same body, every value the buyer sent except
  idempotency_key, and returns the stored result whether an acceptance
  or a rejection; a retry against a new version uses a new key;
- version increments on each revision of the proposal, not only while
  published, so a counter under review also moves it;
- "deterministic" now says what the checks depend on: the stored
  proposal and the time the seller receives the attempt;
- the price check names the pricing[] entry the commitment is priced
  against.

Refs IABTechLab#24
Give each repeated concept one type in section 2.2, and state the table,
presence, type, key, and value rules in section 2.6. Add Type and
Required columns to every field and key table. Add the lifecycle,
recorded, asserted, and mixed markers, and a line_items[] field. Define
the Summary as a strict path subset, with manifest key tables.

Delete catalog_ref. Rename the time, reference, delta, cap, and path
fields to use the shared types. Number every heading, and keep issue
citations and edit history out of normative text. Update the examples,
the manifest, the appendices, and the docs.

Teach check_appendix.py the new columns and a closed layout list, and add
check_examples.py, which checks the examples against the spec's tables.
Add section 2.4: a rejection returns errors[], one or more ErrorObjects
with an open code list, retry values that read for any request, and
informative HTTP fits. Name the code each rejection in sections 5.5,
5.6.1, and 5.6.3 returns, and drop the requires cycle ban.

Add the Ext type and section 2.5: ext on the proposal and each line
item, keyed by owner domain, ignored and kept when not understood, and
frozen at agreed. Make spec_version a required proposal field, and ask
in section 8 how a receiver reads a later release.

Add informative security considerations in section 2.7. Word the open
questions without a count. Update the examples and appendices, and
teach check_examples.py the Ext type and the open ErrorObject.
Make seller a Party in section 4.1, with a required legal_name, and add
buyer and commitment.advertisers[]. Move the registry_id rules to Party
in section 2.2, and scope proposal_id to seller.domain.

Add section 1.2 with the three identity layers. In section 5.8, require
visibility, define each value, and separate who may read from who may
commit. Eligibility is a resolve step that returns not_eligible, and an
unreadable line item returns not_found. A required credential is
{ credential_type, issuer }, and eligible_bidders[] splits into
eligible_buyers[] and eligible_seats[].

Give buyer_requirements, billing, and agreement key tables, and convert
the rows the terms and agreement change added. In section 2.3, drop the
manifest seller_id and filter on status, and ask in section 8 whether a
manifest needs both validators. Update the examples, appendices, and
checkers.
# Conflicts:
#	examples/proposal.yaml
#	spec/openproposal-3.0.md
Separate shared and issued proposals, and add issued_from. Define the
binding record, record_digest, and assent[] entries, freeze a version's
offered terms, and state one staleness rule for asks and holds.

Give each act one history action, name the status types, make the
line-item transitions exhaustive, define a firm entry per pricing entry,
and list the allowed decline grounds once. State agreed once.

Remove buyer state from the shared examples, add an issued, partly
agreed example, and recompute its record_digest in the checker.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Change] § 5.2 — State the seller's relationship to each property, checkable against ads.txt

5 participants