Repository navigation
[Change] § 5.6.2 — Let a seller cap concurrent holds per buyer, and admit hold requests like commitments #156
Description
What kind of change?
Add a new field
Which section?
5.6 — Commercial terms
Current text
§ 5.6.2 hold_status: hold_available, hold_duration, hold_scope, state, hold_expires_at.
PR #143 restructures this into hold_terms { available, duration } and hold, where hold.held_availability is "what the seller reserves".
Neither ties a hold request to a buyer the seller could accept a commitment from, or lets a seller state how many holds one buyer may have at once.Proposed text
Add to hold_terms (PR #143), or to hold_status if #143 does not land:
max_concurrent (Integer, OPTIONAL): the most holds this seller grants one buyer at once, counted across the seller's line items in hold status held.
1. A seller MUST NOT grant a hold to a requester it would not admit to a commitment on that line item (§ 5.8, PR #139).
2. A request that would exceed max_concurrent is declined (PR #143) with a reason (§ 2.4, PR #138).
3. A seller that offers holds on a visibility: public line item SHOULD set max_concurrent.Why
Interest declaration: filing in an individual capacity; views are my own. I'm an enterprise architect with 27 years in software, the last four in advertising technology, working on the governance and security of AI agent systems.
Under #143, a held line item reserves inventory (held_availability) with no money changing hands. A human buyer asks for a few holds. A buying agent can ask for one on every line item it screens, at machine speed, and convert one of them. An agent stuck in a retry loop does the same thing by accident. Either way, other buyers lose access to the inventory.
Today a seller can only defend with transport rate limits that buying agents can't see. They'd learn the limit by failing, and nothing makes a hold requester as accountable as a committing buyer.
At least one sell-side agent in the IAB Tech Lab Agent Registry already places a 72-hour inventory hold when a proposal is finalised (registry snapshot, 5 Nov 2026).
Knock-on effects
- Buying agents read
max_concurrentbefore asking; sellers get a declared basis fordeclined. - No change to the hold state machine in § 5.6.2 — Holds: offered hold terms and the live hold (#66) #143. The key sits on each line item, so the no-inheritance rule holds, and § 3's round-trip guarantee is unaffected.
- No effect on downstream standards (OpenDirect, Deals API, OpenRTB).
- Related: [Change] New § 9 — Security considerations: typed fields govern free text, and free text never directs an agent #155 proposes a security considerations section; this is the resource-reservation side of the same concern.
Would this break an implementation already built to this draft?
No — additive or editorial
Alternatives you considered and rejected
- Transport rate limits only. They're invisible to buying agents and can't express a per-buyer inventory policy.
- Deposits for holds. That belongs in binding terms, not the object.
- Rely on buyer-side discipline. A seller can't verify it.
Glad to supply the PR diff on top of #143 once the direction is agreed.
You are commenting as
Individual, no organisational position
Before you submit
- I have read CONTRIBUTING.md and agree my contribution may be published under this repository's licence.
- This contains no confidential or commercially sensitive information.
Activity
KonstantinMirin commentedon Nov 6, 2026
Postindustria (IAB Tech Lab member). Thanks, @pkanna000. A declared cap fixes a real problem: an agent shouldn't learn a limit by failing.
ground.visibility: publicopens a line item to reading, not to holding. To hold it, a buyer needs its own issued proposal.We'd keep
max_concurrentout ofhold_terms, though. It counts holds across all of a seller's line items, so it's seller policy, not a term of one line item. The manifest (§ 2.3) is the draft's one seller-level document, and the natural home.Analyzed and generated with the help of Claude, fully reviewed by me.
premesh commentedon Nov 7, 2026
+1 to a declared cap in the manifest. One OOH note: holds are usually placed by an agency for several advertisers, so a cap counted per requesting buyer would throttle an agency holding for ten clients. Suggest the manifest cap can be counted per advertiser as well as per buyer seat.
pkanna000 commentedon Nov 7, 2026
Thanks, @KonstantinMirin and @premesh.
Agreed on the three rules: #140's issued-proposal gate covers rule 1, and rule 3 follows from it. For rule 2, a plain decline is enough once the cap is published, because a buyer can count its own holds. I'll take
max_concurrentout ofhold_terms.Proposed text for the manifest (§ 2.3), with @premesh's per-advertiser count:
One gap:
requested_termsis OPTIONAL in #143, so a hold need not name an advertiser, andper_advertisercan't count it. I'd let a seller that setsper_advertiserdecline a hold request whoserequested_termsnames no advertiser. The alternative, counting such a hold only againstper_buyer, lets an agency get round the per-advertiser limit by leaving the advertiser out.Would you carry this in #143?
KonstantinMirin commentedon Nov 7, 2026
Thanks, @pkanna000. Yes: our holds PR (#143) now carries
hold_limitsin § 2.3 as you proposed, with @premesh's per-advertiser count. It takes your fix for the gap too: a seller that declaresper_advertiserMAY decline a hold request whoserequested_termsnames no advertiser.Two notes from the rest of our stack:
linked_execution, so there the holds on a package's line items count as one.advertisers[]REQUIRED. With it, a hold names no advertiser only when it carries norequested_terms.Analyzed and generated with the help of Claude, fully reviewed by me.
pkanna000 commentedon Nov 8, 2026
Thanks, @KonstantinMirin. I've read § 2.3 in #143 and it says what I intended, including the fix for holds that name no advertiser. Counting a package's holds as one under #154 makes sense. Nothing further from me on this issue.