Repository navigation
§ 4.1, § 4.1.3, § 4.3 — Lifecycle: who moves each status, and when an offer goes stale (#60, #64, #65, #67) - #140
Open
KonstantinMirin wants to merge 32 commits into
Open
KonstantinMirin wants to merge 32 commits into
KonstantinMirin wants to merge 32 commits into
Conversation
A proposal can say its line items must be bought together (linked_execution, § 4.1), and a line item can name the line items or spend that must be in the same commitment (requires, § 5.6.3). A bonus line is a line item with requires and its own price. The § 2 "binding terms" hook now points at a field, and the Summary Representation carries has_requires and linked_execution. Adds a CTV bonus line example (§ 6.5) and linked_execution: none to the proposal example. Refs IABTechLab#23
The seller declares which exclusion types it accepts and how it
enforces each (exclusions_accepted); the buyer supplies its lists
(exclusions). Blocked apps carry their store, { platform, bundle },
so one store id is never applied across stores. Exclusions are
recompute inputs (§ 3.3) and are never disclosed to other parties
(§ 5.8). The display example declares and supplies lists.
Refs IABTechLab#25
A commitment names the proposal and version it was priced against (§ 5.6.1). The seller rejects a new attempt on a stale version, or past valid_until or price_valid_until, and returns the current version. An authenticated replay with the same idempotency_key and terms returns the stored result without re-running those checks; the same key with different terms is a conflict. Keys are opaque and scoped to one buyer and seller pair. § 4.1 states that each revision while published increments version. The display, CTV and audio examples carry proposal_id and version. Refs IABTechLab#24
§ 4.1 adds an optional, immutable proposal_template_id linking an issued proposal to the seller's template. Each issued proposal has its own status, version and negotiation_history[], and buyers never need the template id to transact. § 7 adds a non-normative note separating seller-side templates from the issued proposals buyers commit against. Appendix A gains one row; Appendix B counts immutable 6 → 7 and 72 fields. The proposal example carries a proposal_template_id. Refs IABTechLab#26
§ 5.8 adds terms_ref ({ url, sha256, version }), REQUIRED when
terms_acceptance_required is true, hash-pinned and frozen at agreed, so
assent binds to an exact document. § 5.10 adds agreement_ref, an
informative pointer to the master or annual agreement a line item is
priced under, and documents the io and agreement roles on
external_references[]. IO generation is stated to be a connector
concern, and § 7 adds a non-normative note on relationships.
agreement_ref is seller-set; a buyer-held agreement id travels as an
external_references[] entry with role: agreement, so the field keeps
one marker (§ 3).
Appendix A gains two rows; Appendix B counts seller-set 29 → 31 and
73 fields. The display example carries terms_ref.
Refs IABTechLab#27
A new § 2.3 lets a seller publish its public standard line items at /.well-known/openproposal.json: seller_id, generated_at, spec_version and, per proposal, proposal_id, version, the Summary Representation of each line item and a full_url. ETag / Last-Modified are required, only line items with visibility public appear, and entries must match the current version. Buyers discover from the manifest, then fetch the Full Representation of shortlisted line items. Adds examples/manifest.json (§ 6.5) and visibility: public to the CTV and audio examples; the registry_gated display line item is not listed. Refs IABTechLab#29
The specification does not define authentication yet (WS1; see IABTechLab#62), so the replay rule now applies to a replay from the same buyer rather than an authenticated replay. Refs IABTechLab#24
agreement_ref.parties used buyer_id, which the specification does not define. parties[] now names the seller by its seller_id and the buyer by the id it holds in eligible_bidders[] (section 5.8). Refs IABTechLab#27
The rule that a hold on a linked_execution: all proposal uses hold_scope: proposal came from a comment on IABTechLab#23, not the change request as filed. It moves to the PR description as a point for the working group, so this PR carries only the filed change. Refs IABTechLab#23
IABTechLab#25 names the content-category list iab_content_category[], a list of IAB Content Taxonomy ids. The earlier commit renamed it content_category with a version-pinned taxonomy_ref, which nobody proposed. This restores the filed name and shape; which taxonomy version to reference is left to the working group. Refs IABTechLab#25
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
"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
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.
This was referenced Nov 4, 2026
Open
Open
Open
Open
Open
[Change] § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (linked_execution, requires)
#23
Open
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this changes
Draft 1 lists statuses, but not who moves each one, when a version changes, or when an ask goes stale. This PR states all three.
statusof the object that carries aseller-setfield gates its revision. A resolvedcommitmentis an offer until the seller accepts it (§ 5.6.1).buyeris issued, and one without is shared. Asks, holds, and assent live only on an issued proposal. § 4.1 addsissued_from.assent[]entries. § 4.1.2 statesagreedonce.HistoryEntry,HistoryPath, andRequestedValuetables. § 2.2 names the status types.status, and expiry.pricing[]entry with aprice_valid_until. § 4.3.2 lists the grounds for declining a commit under it.Related issue
Closes #60. Closes #64. Closes #65. Closes #67. All are Postindustria (IAB Tech Lab member) change requests.
Refs #63. This PR carries its § 4.1.1 and § 4.1.2 as filed.
Refs #68. This PR ends the lifecycle at
agreed.Refs #26, #24, #74, #70.
Builds on
This PR builds on our parties PR, which builds on our errors and extensions PR and our shared types PR. Through them, it carries #118 by @aleksUIX, #70 and #71 by @Sirajmx, and #73, #75, and #76 by @Kishore-2572. It also carries #74 by @Kishore-2572, at its head. Its merge applies the
eligible_buyers[]rename to #74's § 7. Review the last two commits; the earlier ones belong to the PRs it builds on.Type
Checklist
issued_from,record_digest, andassent[]in place ofassent;scripts/check_appendix.pypassesimmutable8 → 9,recorded2 → 3; 83 → 85 fieldsexamples/is updated and still parses — newproposal-issued.yaml(§ 6.12, its final number; later PRs fill § 6.7 to § 6.11); four examples andmanifest.jsonupdated;scripts/check_examples.pyrecomputes eachassent[]digest and passesissued_fromis a pointer, and nothing is inherited through itselectabledeclaresavailable[]andincluded[]; anythingsettabledeclares bounds (§ 3.1, § 3.2) — none addedKnock-on effects
assentbecomesassent[]entries. History actionsproposedandaccepted, andlinked_execution: none, are gone.negotiation_history[]is REQUIRED once a version is frozen.issued_fromand the split are our asks on #26, which @Kishore-2572 left to the working group.proposed,revised, andacceptedbecomepublishedandgranted. In [Change] § 4, § 5.1 — Add § 4.3 Lifecycle: who moves each status #65,grantreplacesacceptof arequest. [Change] § 3, § 5.6.1, Appendix B — A resolved commitment is an offer until the seller accepts #67's decline limit moves to § 4.3.2, adding an exclusivity conflict. Our [Change] § 4.1, § 5.6.1 — Commitments must carry proposal_id and version; stale versions are rejected #24 reply'soffer_digestis dropped.list_raterow and how a granted rate meets a firm entry. Our PR on what is signed closes [Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63 with theAssentEntrytable andterms_refs[]. Our holds PR adds thedeclinedhold state. Our post-agreement PR closes [Comment] § 1.1, § 4.1, § 5.1 — Lifecycle ends at agreed: say so, name the baseline #68 and putsApprovalStatusonchange_requests[]. Our pricing PR adds theunit_boundsrow.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.