D-001 Which sentences of the Deals API state a requirement, when the text adopts no RFC 2119 convention and writes its keywords in lowercase?
What the schemas do
A sentence with a requirement keyword in any case, such as "must", "should", "may", "required", or "recommended", is a statement with that keyword's level, and "strongly encouraged" reads as recommended. A sentence that uses the word in its ordinary sense, as "Some level of trust is required" does, states no requirement on a deal or a party.
Options
Why
The text writes every requirement in lowercase, "should be provided", "must bid on the deal", and adopts no convention that reserves capitals, so an uppercase-only reading would find no requirement at all. Reading every keyword keeps each requirement as an element a decision can cite, and its level sets a rule's severity: a should is a warning, a must an error. Some sentences use the keyword in its ordinary sense: what a field may hold ("This may be the same as the origin or curator"), what future versions may add, what a scenario may do, or what the text allows a party to choose ("Implementers may choose to accept incoming webhooks"). Each of those is informative, and it is listed here.
What we ask the specification to state
State which words carry requirements: adopt RFC 2119 and BCP 14, and write the keywords in capitals where a sentence states a requirement. Today "must", "should", and "may" appear in lowercase both as requirements and in their ordinary sense, as in "Some level of trust is required when buying any Deal ID", so an implementer can't tell which sentences bind them.
The specification lines it rests on
Each line is quoted as the record pins it. Expand an item to read the quote.
main
What it isn't, a requirement L64 at 3028ddc
Future versions may include that functionality.
Object: Deal, a requirement L86 at 3028ddc
Note: This name may be displayed to the buyer.
Object: Deal, a requirement L90 at 3028ddc
This may be the same as the origin or curator, but it also could be any intermediate seller.
Object: Deal, a requirement L97 at 3028ddc
Indicates if the inventory for the deal is dynamic, meaning sites or applications included in the deal may update after the deal is live where:
0= undisclosed1= inventory will NOT update once the deal goes live2= inventory where this deal may run is updated dynamically.Matching Bid Requests to Deals, a requirement L185 at 3028ddc
Some level of trust is required when buying any Deal ID.
Matching Bid Requests to Deals, a requirement L187 at 3028ddc
However, some attributes may be subject to change over the flight of the deal.
Auxiliary Data, a requirement L215 at 3028ddc
This attribute also communicates information about whether or not additional data layers may be applied after the deal has gone live.
Publisher Count, a requirement L220 at 3028ddc
Inventory aggregation services representing multiple publishing sites may also be considered a single publisher deal.
Terms Object, a requirement L236 at 3028ddc
Examples of Deal name and description so there's a reference point for a standard way of what the fields should contain
Sending and Receiving Information, a requirement L203 at 3028ddc
Once a deal has been sent by the origin system to the receiving system, it may query the endpoint setup by the receiving system for information about the status of the Deal.
Sending and Receiving Information, a requirement L205 at 3028ddc
Implementers may choose to accept incoming webhooks to their API endpoints for events.
Example Scenarios, a requirement L297 at 3028ddc
Data providers will not be changed, but inventory may be updated after the start of the deal.
Example Scenarios, a requirement L299 at 3028ddc
They do not currently work with other data providers, but may layer them in based on deal performance.
Tag 1.0-202602
What it isn't, a requirement L64 at 938a5d1
Future versions may include that functionality.
Object: Deal, a requirement L86 at 938a5d1
Note: This name may be displayed to the buyer.
Object: Deal, a requirement L90 at 938a5d1
This may be the same as the origin or curator, but it also could be any intermediate seller.
Object: Deal, a requirement L97 at 938a5d1
Indicates if the inventory for the deal is dynamic, meaning sites or applications included in the deal may update after the deal is live where:
0= undisclosed1= inventory will NOT update once the deal goes live2= inventory where this deal may run is updated dynamically.Matching Bid Requests to Deals, a requirement L185 at 938a5d1
Some level of trust is required when buying any Deal ID.
Matching Bid Requests to Deals, a requirement L187 at 938a5d1
However, some attributes may be subject to change over the flight of the deal.
Auxiliary Data, a requirement L215 at 938a5d1
This attribute also communicates information about whether or not additional data layers may be applied after the deal has gone live.
Publisher Count, a requirement L220 at 938a5d1
Inventory aggregation services representing multiple publishing sites may also be considered a single publisher deal.
Terms Object, a requirement L236 at 938a5d1
Examples of Deal name and description so there's a reference point for a standard way of what the fields should contain
Sending and Receiving Information, a requirement L203 at 938a5d1
Once a deal has been sent by the origin system to the receiving system, it may query the endpoint setup by the receiving system for information about the status of the Deal.
Sending and Receiving Information, a requirement L205 at 938a5d1
Implementers may choose to accept incoming webhooks to their API endpoints for events.
Example Scenarios, a requirement L297 at 938a5d1
Data providers will not be changed, but inventory may be updated after the start of the deal.
Example Scenarios, a requirement L299 at 938a5d1
They do not currently work with other data providers, but may layer them in based on deal performance.