Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core]
Alex Rousskov <[email protected]>
| Newsgroups | gmane.ietf.opes |
|---|---|
| Message-ID | <[email protected]> |
On Tue, 4 May 2004, The Purple Streak, Hilarie Orman wrote: > Putting the syntax out of scope would be a very good idea. OK. Here is the revised section: 15.1 Extending OCP Core OCP extensions MUST NOT change OCP Core message format, as defined by ABNF and accompanying normative rules in Section 3.1. The intent of this requirement is to allow OCP message viewers, validators, and "intermediary" software to at least isolate and decompose any OCP message, even a message with unknown to them (i.e., extended) semantics. OCP extensions are allowed to change normative OCP Core requirements for OPES processors and callout servers. However, OCP extensions SHOULD NOT make such changes and MUST require on a "MUST"-level that such changes are negotiated prior to taking effect. Informally, this specification defines compliant OCP agent behavior until changes to this specifications (if any) are successfully negotiated. For example, if an RTSP profile for OCP requires support for offsets exceeding 2147483647 octets, the profile specification can document appropriate OCP changes while requiring that RTSP adaptation agents negotiate "large offsets" support before using large offsets. Such negotiation can be bundled with negotiating another feature (e.g., negotiating an RTSP profile may imply support for "large offsets"). As implied by the above rules, OCP extensions may dynamically alter the negotiation mechanism itself, but such an alternation would have to be negotiated first, using the negotiation mechanism defined by this specification. For example, successfully negotiating a feature might change the default "Offer-Pending" value from false to true. Alex.