ietf-openproxy
[Top] [All Lists]

Re: [Fwd: Re: ID Tracker State Update Notice: draft-ietf-opes-ocp-core]

2004-05-05 01:00:14


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.