[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.