data.
Message parameters always refer to dataflow originating at the other
OCP agent. When sent by an OPES processor, your-size is adp-size;
when sent by a callout server, your-size is org-size.
The "Size-request" parameter refers to dataflow originating at the
OCP agent receiving the parameter. If a "Size-request" parameter is
present, its value is the suggested minimum data size. It is meant
to allow the recipient to deliver data in fewer chunks. The
recipient MAY ignore the "Size-request" parameter. An absent
"Size-request" parameter implies "any size".
The message also cancels the Paused My Data (DPM) message effect. If
the recipient was not sending any data because of its DPM message,
the recipient MAY resume sending data. Note, however, that the Want
More Data (DWM) message can be sent regardless of whether the
dataflow in question has been paused. The "Size-request" parameter
makes this message a useful stand-alone optimization.
11.18. Negotiation Offer (NO)
NO: extends message with {
features;
[SG: my-sg-id];
[Offer-Pending: boolean];
};
A Negotiation Offer (NO) message solicits a selection of a single
"best" feature out of a supplied list, using a Negotiation Response
(NR) message. The sender is expected to list preferred features
first when it is possible. The recipient MAY ignore sender
preferences. If the list of features is empty, the negotiation is
bound to fail but remains valid.
Both the OPES processor and the callout server are allowed to send
Negotiation Offer (NO) messages. The rules in this section ensure
that only one offer is honored if two offers are submitted
concurrently. An agent MUST NOT send a Negotiation Offer (NO)
message if it still expects a response to its previous offer on the
same connection.
If an OPES processor receives a Negotiation Offer (NO) message while
its own offer is pending, the processor MUST disregard the server
offer. Otherwise, it MUST respond immediately.
If a callout server receives a Negotiation Offer (NO) message when
its own offer is pending, the server MUST disregard its own offer.
In either case, the server MUST respond immediately.
If an agent receives a message sequence that violates any of the
above rules in this section, the agent MUST terminate the connection
with a Connection End (CE) message indicating a failure.
An optional "Offer-Pending" parameter is used for Negotiation Phase
maintenance (section 6.1). The option’s value defaults to "false".
An optional "SG" parameter is used to narrow the scope of
negotiations to the specified service group. If SG is present, the
negotiated features are negotiated and enabled only for transactions
that use the specified service group ID. Connection-scoped features
are negotiated and enabled for all service groups. The presence of
scope does not imply automatic conflict resolution common to
programming languages; no conflicts are allowed. When negotiating
connection-scoped features, an agent MUST check for conflicts within
each existing service group. When negotiating group-scoped features,
an agent MUST check for conflicts with connection-scoped features
already negotiated. For example, it must not be possible to
negotiate a connection-scoped HTTP application profile if one service
group already has an SMTP application profile, and vice versa.
OCP agents SHOULD NOT send offers with service groups used by pending
transactions. Unless it is explicitly noted otherwise in a feature
documentation, OCP agents MUST NOT apply any negotiations to pending
transactions. In other words, negotiated features take effect with
the new OCP transaction.
As with other protocol elements, OCP Core extensions may document
additional negotiation restrictions. For example, specification of a
transport security feature may prohibit the use of the SG parameter
in negotiation offers, to avoid situations where encryption is
enabled for only a portion of overlapping transactions on the same
transport connection.
11.19. Negotiation Response (NR)
NR: extends message with {
[feature];
[SG: my-sg-id];
[Rejects: features];
[Unknowns: features];
[Offer-Pending: boolean];
};
A Negotiation Response (NR) message conveys recipient’s reaction to a
Negotiation Offer (NO) request. An accepted offer (a.k.a., positive
response) is indicated by the presence of an anonymous "feature"
parameter, containing the selected feature. If the selected feature
does not match any of the offered features, the offering agent MUST
consider negotiation failed and MAY terminate the connection with a
Connection End (CE) message indicating a failure.
A rejected offer (negative response) is indicated by omitting the
anonymous "feature" parameter.
The successfully negotiated feature becomes effective immediately.
The sender of a positive response MUST consider the corresponding
feature enabled immediately after the response is sent; the recipient
of a positive response MUST consider the corresponding feature
enabled immediately after the response is received. Note that the
scope of the negotiated feature application may be limited to a
specified service group. The negotiation phase state does not affect
enabling of the feature.
If negotiation offer contains an SG parameter, the responder MUST
include that parameter in the Negotiation Response (NR) message. The
recipient of an NR message without the expected SG parameter MUST
treat negotiation response as invalid.
If the negotiation offer lacks an SG parameter, the responder MUST
NOT include that parameter in the Negotiation Response (NR) message.
The recipient of an NR message with an unexpected SG parameter MUST
treat the negotiation response as invalid.
An optional "Offer-Pending" parameter is used for Negotiation Phase
maintenance (section 6.1). The option’s value defaults to "false".
When accepting or rejecting an offer, the sender of the Negotiation
Response (NR) message MAY supply additional details via Rejects and
Unknowns parameters. The Rejects parameter can be used to list
features that were known to the Negotiation Offer (NO) recipient but
could not be supported given negotiated state that existed when NO
message was received. The Unknowns parameter can be used to list
features that were unknown to the NO recipient.
11.20. Ability Query (AQ)
AQ: extends message with {
feature;
};
An Ability Query (AQ) message solicits an immediate Ability Answer
(AA) response. The recipient MUST respond immediately with an AA
message. This is a read-only, non-modifying interface. The
recipient MUST NOT enable or disable any features due to an AQ
request.
OCP extensions documenting a feature MAY extend AQ messages to supply
additional information about the feature or the query itself.
The primary intended purpose of the ability inquiry interface is
debugging and troubleshooting and not automated fine-tuning of agent
behavior and configuration. The latter may be better achieved by the
OCP negotiation mechanism (section 6).
11.21. Ability Answer (AA)
AA: extends message with {
boolean;
};
An Ability Answer (AA) message expresses the sender’s support for a
feature requested via an Ability Query (AQ) message. The sender MUST
set the value of the anonymous boolean parameter to the truthfulness
of the following statement: "At the time of this answer generation,
the sender supports the feature in question". The meaning of
"support" and additional details are feature specific. OCP
extensions documenting a feature MUST document the definition of
"support" in the scope of the above statement and MAY extend AA
messages to supply additional information about the feature or the
answer itself.
11.22. Progress Query (PQ)
PQ: extends message with {
[xid];
};
A Progress Query (PQ) message solicits an immediate Progress Answer
(PA) response. The recipient MUST immediately respond to a PQ
request, even if the transaction identifier is invalid from the
recipient’s point of view.
11.23. Progress Answer (PA)
PA: extends message with {
[xid];
[Org-Data: org-size];
};
A PA message carries the sender’s state. The "Org-Data" size is the
total original data size received or sent by the agent so far for the
identified application message (an agent can be either sending or
receiving original data, so there is no ambiguity). When referring
to received data, progress information does not imply that the data
has otherwise been processed in some way.
The progress inquiry interface is useful for several purposes,
including keeping idle OCP connections "alive", gauging the agent
processing speed, verifying the agent’s progress, and debugging OCP
communications. Verifying progress, for example, may be essential to
implement timeouts for callout servers that do not send any adapted
data until the entire original application message is received and
processed.
A recipient of a PA message MUST NOT assume that the sender is not
working on any transaction or application message not identified in
the PA message. A PA message does not carry information about
multiple transactions or application messages.
If an agent is working on the transaction identified in the Progress
Query (PQ) request, the agent MUST send the corresponding transaction
ID (xid) when answering the PQ with a PA message. Otherwise, the
agent MUST NOT send the transaction ID. If an agent is working on
the original application message for the specified transaction, the
agent MUST send the Org-Data parameter. If the agent has already
sent or received the Application Message End (AME) message for the
original dataflow, the agent MUST NOT send the Org-data parameter.
Informally, the PA message relays the sender’s progress with the
transaction and original dataflow identified by the Progress Query
(PQ) message, provided the transaction identifier is still valid at
the time of the answer. Absent information in the answer indicates
invalid, unknown, or closed transaction and/or original dataflow from
the query recipient’s point of view.
11.24. Progress Report (PR)
PR: extends message with {
[xid];
[Org-Data: org-size];
};
A Progress Report (PR) message carries the sender’s state. The
message semantics and associated requirements are identical to those
of a Progress Answer (PA) message except that the PR message, is sent
unsolicited. The sender MAY report progress at any time. The sender
MAY report progress unrelated to any transaction or original
application message or related to any valid (current) transaction or
original dataflow.
Unsolicited progress reports are especially useful for OCP extensions
dealing with "slow" callout services that introduce significant
delays for the final application message recipient. The report may
contain progress information that will make that final recipient more
delay tolerant.
12. IAB Considerations
OPES treatment of IETF Internet Architecture Board (IAB)
considerations [RFC3238] are documented in [RFC3914].
13. Security Considerations
This section examines security considerations for OCP. OPES threats
are documented in [RFC3837]
OCP relays application messages that may contain sensitive
information. Appropriate transport encryption can be negotiated to
prevent information leakage or modification (see section 6), but OCP
agents may support unencrypted transport by default. These
configurations will expose application messages to third-party
recording and modification, even if OPES proxies themselves are
secure.
OCP implementation bugs may lead to security vulnerabilities in OCP
agents, even if OCP traffic itself remains secure. For example, a
buffer overflow in a callout server caused by a malicious OPES
processor may grant that processor access to information from other
(100% secure) OCP connections, including connections with other OPES
processors.
Careless OCP implementations may rely on various OCP identifiers to
be unique across all OCP agents. A malicious agent can inject an OCP
message that matches identifiers used by other agents, in an attempt
to gain access to sensitive data. OCP implementations must always
check an identifier for being "local" to the corresponding connection
before using that identifier.
OCP is a stateful protocol. Several OCP commands increase the amount
of state that the recipient has to maintain. For example, a Service
Group Created (SGC) message instructs the recipient to maintain an
association between a service group identifier and a list of
services.
Implementations that cannot correctly handle resource exhaustion
increase security risks. The following are known OCP-related
resources that may be exhausted during a compliant OCP message
exchange:
OCP message structures: OCP message syntax does not limit the nesting
depth of OCP message structures and does not place an upper limit
on the length (number of OCTETs) of most syntax elements.
concurrent connections: OCP does not place an upper limit on the
number of concurrent connections that a callout server may be
instructed to create via Connection Start (CS) messages.
service groups: OCP does not place an upper limit on the number of
service group associations that a callout server may be instructed
to create via Service Group Created (SGC) messages.
concurrent transactions: OCP does not place an upper limit on the
number of concurrent transactions that a callout server may be
instructed to maintain via Transaction Start (TS) messages.
concurrent flows: OCP Core does not place an upper limit on the
number of concurrent adapted flows that an OPES processor may be
instructed to maintain via Application Message Start (AMS)
messages.
14. IANA Considerations
The IANA maintains a list of OCP features, including application
profiles (section 10.11). For each feature, its uri parameter value
is registered along with the extension parameters (if there are any).
Registered feature syntax and semantics are documented with PETDM
notation (section 9).
The IESG is responsible for assigning a designated expert to review
each standards-track registration prior to IANA assignment. The OPES
working group mailing list may be used to solicit commentary for both
standards-track and non-standards-track features.
Standards-track OCP Core extensions SHOULD use
http://www.iana.org/assignments/opes/ocp/ prefix for feature uri
parameters. It is suggested that the IANA populate resources
identified by such "uri" parameters with corresponding feature
registrations. It is also suggested that the IANA maintain an index
of all registered OCP features at the
http://www.iana.org/assignments/opes/ocp/ URL or on a page linked
from that URL.
This specification defines no OCP features for IANA registration.
15. Compliance
This specification defines compliance for the following compliance
subjects: OPES processors (OCP client implementations), callout
servers (OCP server implementations), and OCP extensions. An OCP
agent (a processor or callout server) may also be referred to as the
"sender" or "recipient" of an OCP message.
A compliance subject is compliant if it satisfies all applicable
"MUST" and "SHOULD" requirements. By definition, to satisfy a "MUST"
requirement means to act as prescribed by the requirement; to satisfy
a "SHOULD" requirement means either to act as prescribed by the
requirement or to have a reason to act differently. A requirement is
applicable to the subject if it instructs (addresses) the subject.
Informally, OCP compliance means that there are no known "MUST"
violations, and that all "SHOULD" violations are deliberate. In
other words, "SHOULD" means "MUST satisfy or MUST have a reason to
violate". It is expected that compliance claims be accompanied by a
list of unsupported SHOULDs (if any), in an appropriate format,
explaining why the preferred behavior was not chosen.
Only normative parts of this specification affect compliance.
Normative parts are those parts explicitly marked with the word
"normative", definitions, and phrases containing unquoted capitalized
keywords from [RFC2119]. Consequently, examples and illustrations
are not normative.
15.1. Extending OCP Core
OCP extensions MUST NOT change the OCP Core message format, as
defined by ABNF and accompanying normative rules in Section 3.1.
This requirement is intended to allow OCP message viewers,
validators, and "intermediary" software to at least isolate and
decompose any OCP message, even a message with semantics unknown to
them (i.e., extended).
OCP extensions are allowed to change normative OCP Core requirements
for OPES processors and callout servers. However, OCP extensions
SHOULD NOT make these changes and MUST require on a "MUST"-level that
these changes are negotiated prior to taking effect. Informally,
this specification defines compliant OCP agent behavior until changes
to this specification (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. This
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.
Appendix A. Message Summary
This appendix is not normative. The table below summarizes key OCP
message properties. For each message, the table provides the
following information:
name: Message name as seen on the wire.
title: Human-friendly message title.
P: Whether this specification documents message semantics as sent by
an OPES processor.
S: Whether this specification documents message semantics as sent by
a callout server.
tie: Related messages such as associated request, response message,
or associated state message.
+-------+----------------------------+-------+-------+--------------+
| name | title | P | S | tie |
+-------+----------------------------+-------+-------+--------------+
| CS | Connection Start | X | X | CE |
| CE | Connection End | X | X | CS |
| SGC | Service Group Created | X | X | SGD TS |
| SGD | Service Group Destroyed | X | X | SGC |
| TS | Transaction Start | X | | TE SGC |
| TE | Transaction End | X | X | TS |
| AMS | Application Message Start | X | X | AME |
| AME | Application Message End | X | X | AMS DSS |
| DUM | Data Use Mine | X | X | DUY DWP |
| DUY | Data Use Yours | | X | DUM DPI |
| DPI | Data Preservation Interest | | X | DUY |
| DWSS | Want Stop Sending Data | | X | DWSR DSS |
| DWSR | Want Stop Receiving Data | | X | DWSS |
| DSS | Stop Sending Data | X | | DWSS |
| DWP | Want Data Paused | X | X | DPM |
| DPM | Paused My Data | X | X | DWP DWM |
| DWM | Want More Data | X | X | DPM |
| NO | Negotiation Offer | X | X | NR SGC |
| NR | Negotiation Response | X | X | NO |
| PQ | Progress Query | X | X | PA |
| PA | Progress Answer | X | X | PQ PR |
| PR | Progress Report | X | X | PA |
| AQ | Ability Query | X | X | AA |
| AA | Ability Answer | X | X | AQ |
+-------+----------------------------+-------+-------+--------------+
Appendix B. State Summary
This appendix is not normative. The table below summarizes OCP
states. Some states are maintained across multiple transactions and
application messages. Some correspond to a single request/response
dialog; the asynchronous nature of most OCP message exchanges
requires OCP agents to process other messages while waiting for a
response to a request and, hence, while maintaining the state of the
dialog.
For each state, the table provides the following information:
state: Short state label.
birth: Messages creating this state.
death: Messages destroying this state.
ID: Associated identifier, if any.
+-------------------------------+-------------+-------------+-------+
| state | birth | death | ID |
+-------------------------------+-------------+-------------+-------+
| connection | CS | CE | |
| service group | SGC | SGD | sg-id |
| transaction | TS | TE | xid |
| application message and | AMS | AME | |
| dataflow | | | |
| premature org-dataflow | DWSR | AME | |
| termination | | | |
| premature adp-dataflow | DWSS | DSS AME | |
| termination | | | |
| paused dataflow | DPM | DWM | |