[Kishore-2572]

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

What this changes

A new § 2.3 Publication lets a seller publish its public standard line items as a static file at https://<seller domain>/.well-known/openproposal.json, like ads.txt and sellers.json. The file carries seller_id, generated_at, spec_version and, per proposal, proposal_id, version, the Summary Representation (§ 2.1) of each line item, and a full_url. ETag / Last-Modified are required so buyers can poll cheaply; only line items with visibility: public appear; and entries must match the current version. Buyers discover from the manifest with no agent call or language model, then fetch the Full Representation of shortlisted line items and compose as today.

Related issue

Refs #29. The "current version" rule relies on #24 (draft PR #73).

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
• Appendix A (field index) matches the body — no new rows, as § 2.3 has no field table; scripts/check_appendix.py passes
• Appendix B (fields by marker, and the counts) matches the body — counts unchanged
• Any affected example in examples/ is updated and still parses — new manifest.json (§ 6.5); visibility: public added to the CTV and audio examples so they can appear in it
• RFC 2119 keywords used deliberately — MUST / SHOULD / MAY are not synonyms
• The no-inheritance rule (§ 2) still holds
• Anything selectable declares available[] and included[]; anything settable declares bounds (§ 3.1, § 3.2) — no new selectable or settable fields
• No confidential or commercially sensitive content

Knock-on effects

• Wording against the filed text: the visibility filter applies per line item, since visibility is a line-item field (§ 5.8). The display example is registry_gated, so the example manifest lists only the CTV and audio line items.
• Examples: the Examples parse check covers *.yaml only, so it does not validate manifest.json. The manifest carries only the summary keys the source examples declare; several § 2.1 summary keys are absent from the examples themselves ([Comment] § 6 — The examples omit listed keys, never exercise the pricing mechanism, and mix timestamp formats the spec does not define #37).
• For the working group (Postindustria on [Change] § 2.3 — Static manifest at a well-known URL for standard proposals #29):
  • binding the file to its domain with seller_domain ([Change] § 4.1 — Identify the seller by seller_domain; make seller_id OPTIONAL #61), so a copied file is rejected. The manifest takes whichever seller identifier the group adopts;
  • per-entry record_digest / offer_digest ([Change] § 4.1 — Define record_digest and assent[]; defer signer identity to the AAMP profile #63) in place of comparing version numbers;
  • signing the manifest, which is a WS1 / Agent Registry follow-on ([Comment] § 4.1, § 8 — "WS1" and "WS4" are referenced by abbreviation only; expand and link them #36).
• Also for the working group: whether both ETag and Last-Modified are required or either; spec_version has no home in the object ([Comment] § 2 — The draft does not say what a parser does with a key it does not define #33); what a public manifest may expose ([Comment] §§ 2.1, 2.2, 4, 5.7, 5.8, 5.10 — Privacy and disclosure guidance across summary, measurement, and agent identity #47).
• Related: [Change] § 2.1, § 5.10 — Cross-publisher composition: searchable summary metadata and source_ref #28 adds summary fields that would appear in the manifest; [Change] § 2, § 4.1, § 5.1 — Name the line-item container (line_items[]) and carry proposal_id and seller_id on every line item representation #31 (line_items[] naming).
• Path: /.well-known/openproposal.json follows RFC 8615. If adopted, the openproposal.json well-known name should be registered with IANA.
• Section numbering: § 2, § 4.1, § 5.6 — Line-item dependencies and bonus lines (#23) #70 also adds a § 6.5; whichever merges later renumbers.

---

By opening this pull request I agree my contribution may be published under this
repository's licence, as set out in CONTRIBUTING.md.

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Kishore-2572, examples/manifest.json carries the Summary Representation (§ 2.1), so it changes whenever another PR adds a summary key. Three open PRs do:

• PR #70 (@Sirajmx) adds linked_execution to the proposal's summary keys and has_requires to each line item's. The manifest needs "linked_execution": "none" on the proposal and "has_requires": false on both entries.
• Our PR for #90 adds environments.available[]: ["ctv"] on weather-app-ctv and ["web_mobile", "app_mobile"] on streaming-audio.
• Our PR for #89 adds the placement keys a line item declares. The CTV example declares plcmt, so weather-app-ctv needs "placement": { "plcmt": 1 }, Instream (1).

Whichever PR merges later can add its keys to the manifest.

As your Knock-on effects note, the Examples parse check reads only examples/*.yaml. Adding examples/*.json would catch a broken edit, but not a missing key. Would a check that compares each manifest entry with its source example help, as check_appendix.py does for Appendix A?

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

[KonstantinMirin]

Postindustria (IAB Tech Lab member). @Kishore-2572, two points on § 2.3 and the example manifest:

• Keep the body's shapes. formats keeps its { "included": [...] } object, but pricing becomes a single object, as § 2.1's pricing.cost_method path suggests, though § 5.6 defines pricing[] as an array. transaction_mechanism becomes a bare array, and § 3.1 treats a selectable field that carries a bare value as seller-set. Code screens this file, so one sentence in § 2.3 settles every key: "A summary uses the paths and shapes of the Full Representation, with fewer keys; property lists stay as names." Then § 2.1 reads pricing[].cost_method, pricing is [{ "cost_method": "CPM", "gross_rate": 45.0 }], and transaction_mechanism keeps available[] and included[].
• Filter on status. As written, a public line item that is sold_out or withdrawn (§ 5.1) still qualifies. Suggest: "Only line items whose status is published appear."

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