Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core
Extracted elements (31)
For the 'getting out of the loop' optimization, adapted dataflow must be terminated before original dataflow because the mapping between original and adapted octets is known only to the callout service. Terminating original flow first would leave the OPES processor unable to reconstruct the remaining adapted application message.
Invalid input handling deliberately favors correctness over robustness: connection or transaction termination on invalid messages prevents silently corrupted application messages from reaching end users. OPES adaptations are high-level and cannot be automatically validated, so 'robustness guessing' is more dangerous than termination.
When two agents send concurrent negotiation offers, the OPES processor's offer takes priority and the callout server's concurrent offer is ignored by both sides. This resolves potential negotiation deadlock without a complex conflict-resolution protocol.
OCP Core requires a reliable and message-order-preserving transport. TCP/IP is the assumed default, but other transports (e.g., BEEP [RFC3080]) are permitted. No default TCP port is assigned to OCP. The mapping of OCP message structures onto transport data units is outside OCP Core scope.
A DUM sender MUST NOT create gaps in the data stream: the my-offset of each data message must equal the my-offset plus the payload size of the previous data message. A DUM without a payload field is invalid; zero-size (empty) payloads are permitted.
A recipient of result 400 (failure) in an AME, TE, or CE message MUST destroy all state and data associated with the corresponding dataflow, transaction, or connection. For example, cached adapted application message data must be purged on receipt of AME with result 400.
An OCP agent MUST forcefully terminate any OCP connection, negotiation, transaction, or other operation that is not making progress, covering both deadlock and livelock situations. Agents MAY rely on transport-level or external timeouts if guaranteed to trigger for a given OCP operation.
An OCP agent MUST NOT send a uni identifier that corresponds to an inactive state (never created or already destroyed) except when creating a new identifier. Such identifiers invalidate the host OCP message and require transaction or connection termination.
An OCP agent MUST send a Connection Start (CS) message before any other message. If the first received message is not CS, the agent MUST terminate the connection with CE indicating failure (result 400). CS MUST be sent exactly once; repeated CS messages MUST be ignored.
An OCP agent MUST send Transaction End (TE) immediately after deciding to send no more messages for that transaction, and MUST send Application Message End (AME) immediately after deciding to stop processing its application message. Delays cause unnecessary latency and timeouts at the peer.
An OPES processor MUST send a Negotiation Offer (NO) immediately after sending CS. If there is nothing to negotiate, it MUST send NO with an empty features list. This bootstraps the mandatory first Negotiation Phase.
OCP agents MUST NOT make, and MUST reject, negotiation offers that would conflict with already-negotiated features (e.g., offering a second application profile or a different encryption scheme after one is already active).
Unless explicitly permitted otherwise, an OCP agent MUST terminate the transaction upon receiving an invalid transaction-scoped message, and MUST terminate the connection upon receiving an invalid connection-scoped message, sending result code 400. If scope is indeterminate, the message MUST be treated as connection-scoped.
When a callout server sends DWSS followed by DWSR to get out of the loop, the OPES processor MUST NOT send AME 206 before sending DSS. Adapted dataflow termination must be authorized by the processor before original dataflow termination is permitted.
An OCP transaction is a logical sequence of messages processing a single original application message, producing zero or more adapted messages. It starts with Transaction Start (TS) sent by the OPES processor and ends with the first Transaction End (TE) message from either side.
Data Use Mine (DUM) is the only OCP Core message with a payload; it carries application data with a mandatory offset and optional 'Kept' (preservation commitment), 'As-is' (pass-through hint), and 'Modp' (modification probability) parameters. Data Use Yours (DUY) references a previously preserved chunk without retransmitting it.
Negotiation uses Negotiation Offer (NO) and Negotiation Response (NR) messages. A NO presents a preference-ordered list of feature URIs; the responder selects at most one via NR. If the NR is positive, the feature takes effect immediately on both sides. Offers containing a true 'Offer-Pending' parameter keep the Negotiation Phase open.
OCP result is a structure with a required numeric status code and an optional informational reason string. Defined codes: 200 (OK), 206 (partial — premature dataflow termination), and 400 (failure — recipient must destroy all associated state). Unknown codes MUST be treated as 400.
PETDM (Protocol Element Type Declaration Mnemonic) is a formal type-extension system for OCP. It supports atoms, lists, structures, and messages as base types extended via 'extends'. OCP extensions SHOULD use PETDM; all extensions MUST define a namespace tag (core namespace: 'Core'). Unrecognized members in valid-format messages MUST be ignored.
Premature adapted dataflow termination: the callout server sends Want Stop Sending Data (DWSS); the OPES processor replies with Stop Sending Data (DSS), after which the server terminates adapted dataflow with AME 206. The processor then reconstructs the full application message from original data.
Premature original dataflow termination: the callout server sends Want Stop Receiving Data (DWSR); the OPES processor responds by sending Application Message End (AME) with result 206 (partial), halting original data delivery. The adapted dataflow continues unaffected.
Service groups map a connection-scoped sg-id to an ordered list of adaptation service URIs via Service Group Created (SGC). The callout server must apply the services in order for each transaction that references the group. Service Group Destroyed (SGD) releases the association.
The Data Preservation optimization lets an OPES processor announce a kept data chunk via the 'Kept' parameter of DUM (offset, size pair). The callout server may reference the chunk via DUY, eliminating the return trip for unmodified data. The processor must keep the chunk until end-of-transaction or explicit callout-server release.
The modp type extends percent to express the sender's confidence (0–100) that application data will be modified. A value of 0 guarantees no modification; 100 guarantees modification; intermediate values are probabilistic. Carried in the 'Modp' parameter of DUM messages.
The uni type is a unique numeric identifier in [0,2147483647] scoped to its OCP context (xid for transactions, sg-id for service groups). New identifiers MUST use monotonically increasing values within the same type and scope, enabling efficient log cross-referencing and duplicate detection.
OCP feature and service identifiers are URIs, with IANA managing assignments under http://www.iana.org/assignments/opes/ocp/. Examples from the document include paths for TLS, HTTP response profiles, and encryption schemes. Section 14 (IANA Considerations) governs registration procedures for new OCP features and services.
OCP carries application messages that may contain sensitive information. The IAB considerations (section 12) and OPES threat analysis (RFC3837) inform the security requirements. The callout server's ability to modify arbitrary application message content creates significant trust requirements between the OPES processor and callout server.
OCP Core provides negotiation hooks for transport encryption and mutual authentication but does not mandate them. OCP is expected to be deployed in closed environments where trust is established externally. Application profiles and OCP extensions may require specific security mechanisms; implementations must demand needed features via the negotiation mechanism based on configuration and environment.
Negotiation Phase lifecycle: starts for an agent upon receiving the first NO or sending the first NR not part of an existing Phase; ends on the first NR sent or received after which no further negotiations are expected. Phases do not overlap; multiple Phases may occur per connection. An agent keeps the Phase open by including a true 'Offer-Pending' parameter.
Data and quoted values use a length-prefixed binary encoding: 'size:octets', where size is a decimal integer in [0,2147483647] specifying the exact number of octets following the colon. Any bare value may also be expressed as a quoted value; both yield identical semantics. Unicode UTF-8 is the default encoding.
OCP message format is defined by ABNF: message name, optional space-separated anonymous parameters, optional CRLF-separated named parameters, optional payload, and a terminating semicolon+CRLF. Names use ALPHA followed by safe-OCTETs (alphanumeric, hyphen, underscore); all elements are case-sensitive with no implied linear whitespace.