OPES Callout Protocol Core

The Open Pluggable Edge Services (OPES) architecture , enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can delegate the responsibility of service execution by communicating with callout servers. As described in , an OPES processor invokes and communicates with services on a callout server by using an OPES callout protocol (OCP). This document specifies the core of that protocol. OCP Core specification documents general, application-independent protocol mechanisms. A separate series of documents describe application-specific aspects of OCP. For example, "HTTP adaptation with OPES" describes, in part, how HTTP messages and HTTP meta-information can be communicated over OCP. provides a brief overview of the entire OPES document collection, including documents describing OPES use cases and security threats.

OCP Core specification documents behavior of OCP agents and requirements for OCP extensions. OCP Core does not contain requirements or mechanisms specific for application protocols being adapted. As an application proxy, OPES processor proxies a single application protocol or converts from one application protocol to another. At the same time, OPES processor may be an OCP client, using OCP to facilitate adaptation of proxied messages at callout servers. It is therefore natural to assume that an OPES processor takes application messages being proxied, marshals them over OCP to callout servers, and then puts the adaptation results back on the wire. However, such an assumption implies that OCP is applied directly to application messages that OPES processor is proxing, which may not be the case.

An OPES processor may preprocess (or postprocess) proxied application messages before (or after) they are adapted at callout servers. For example, a processor may take an HTTP response being proxied and pass it as is, along with metadata about the corresponding HTTP connection. Another processor may take an HTTP response, extract its body, and pass that body, along with the content-encoding metadata. Moreover, to perform adaptation, OPES processor may execute several callout services, iterating over several callout servers. Such preprocessing, postprocessing, and iterations make it impossible to rely on any specific relationship between application messages being proxied and application messages being sent to a callout service. Similarly, specific adaptation actions at the callout server are outside of OCP Core scope. This specification does not define or require any specific relationship among application messages being proxied by an OPES processor and application messages being exchanged between an OPES processor and a callout server via OCP. OPES processor usually provides some mapping among these application messages, but processor's specific actions are beyond OCP scope. In other words, this specification is not concerned with the OPES processor role as an application proxy, or as an iterator of callout services. The scope of OCP Core is communication between a single OPES processor and a single callout server. Furthermore, an OPES processor is at liberty to choose which proxied application messages or information about them to send over OCP. All proxied messages on all proxied connections (if connections are defined for a given application protocol), everything on some connections, selected proxied messages, or nothing might be sent over OCP to callout servers. OPES processor and callout server state related to proxied protocols can be relayed over OCP as application message metadata.

This document belongs to a large set of OPES specifications produced by the IETF OPES Working Group. Familiarity with the overall OPES approach and typical scenarios is often essential when trying to comprehend isolated OPES documents. This section provides an index of OPES documents to assist the reader with finding "missing" information. The document on "OPES Use Cases and Deployment Scenarios" describes a set of services and applications that are considered in scope for OPES and have been used as a motivation and guidance in designing the OPES architecture. The OPES architecture and common terminology are described in "An Architecture for Open Pluggable Edge Services (OPES)". "Policy, Authorization and Enforcement Requirements of OPES" outlines requirements and assumptions on the policy framework, without specifying concrete authorization and enforcement methods. "Security Threats and Risks for OPES" provides OPES risk analysis, without recommending specific solutions. "OPES Treatment of IAB Considerations" addresses all architecture-level considerations expressed by the IETF Internet Architecture Board (IAB) when the OPES WG was chartered. At the core of the OPES architecture are the OPES processor and the callout server, two network elements that communicate with each other via an OPES Callout Protocol (OCP). The requirements for such protocol are discussed in "Requirements for OPES Callout Protocols". This document, OPES Callout Protocol Core, specifies an application agnostic protocol core to be used for the communication between OPES processor and callout server. "OPES entities and end points communications" specifies generic tracing and bypass mechanisms for OPES. The OCP Core and Communications documents are independent from the application protocol being adapted by OPES entities. Their generic mechanisms have to be complemented by application-specific profiles. "HTTP adaptation with OPES" is such an application profile for HTTP. It specifies how application-agnostic OPES mechanisms are to be used and augmented in order to support adaptation of HTTP messages. Finally, "P: Message Processing Language" defines a language for specifying what OPES adaptations (e.g, translation) must be applied to what application messages (e.g., e-mail from bob@example.com). P language is meant for configuring application proxies (OPES processors).

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications. OPES processor works with messages from application protocols and may relay information about those application messages to a callout server. OCP is also an application protocol. Thus, protocol elements like "message", "connection", or "transaction" exist in OCP and other application protocols. In this specification, all references to elements from application protocols other than OCP are used with an explicit "application" qualifier. References without the "application" qualifier refer to OCP elements. OCP message is a basic unit of communication between an OPES processor and a callout server. Message is a sequence of octets formatted according to syntax rules. Message semantics is defined in . An entity defined by OPES processor and callout server negotiation. Usually, the negotiated definition would match the definition from an application protocol (e.g., definition of an HTTP message). An opaque sequence of octets representing complete or partial application message. OCP Core does not distinguish application message structure (if any). Application message data may be empty. Same as application message data. Referring to application message flowing from the OPES processor to a callout server. Referring to application message flowing from an OPES callout server to the OPES processor. Any kind of access by a callout server, including modification, generation, and copying. For example, translating or logging an SMTP message is adaptation of that application message. Actor for a given communication protocol. OPES processor and callout server are OCP agents. An agent can be referred to as a sender or receiver, depending on its actions in a particular context. Performing the specified action before reacting to new incoming messages or sending any new messages unrelated to the specified action. A specification extending or adjusting this document for adaptation of an application protocol (a.k.a., application profile, e.g., ), new OCP functionality (e.g., transport encryption and authentication), and/or new OCP Core version.

OPES processor may use OPES callout protocol (OCP) to communicate with callout servers. Adaptation using callout services is sometimes called a "bump in the wire" architecture.

OPES processor establishes transport connections with callout servers for the purpose of exchanging application messages with the callout server(s) using OCP. After a transport-layer connection (usually TCP/IP) is established, communicating OCP agents exchange &CS_tref; messages. Next, OCP features can be negotiated between the processor and the callout server (see ). For example, OCP agents may negotiate transport encryption and application message definition. When enough settings are negotiated, OCP agents may start exchanging application messages. OCP Core provides negotiation and other mechanisms for agents to encrypt OCP connections and authenticate each other. OCP Core does not require OCP connection encryption or agent authentication. Application profiles and other OCP extensions may document and/or require these and other security mechanisms. OCP is expected to be used, in part, in closed environments where trust and privacy are established by means external to OCP. Implementations are expected to demand necessary security features via the OCP Core negotiation mechanism, depending on agent configuration and environment.

When OPES processor wants to adapt an application message, the OPES processor sends a &TS_tref; message to initiate an OCP transaction dedicated to that application message. The processor then sends an &AMS_tref; message to prepare the callout server for application data that will follow. Once application message scope is established, application data can be sent to the callout server, using &DUM_tref; and related OCP message(s). All these messages correspond to the original dataflow.

The callout server receives data and metadata sent by the OPES processor (original dataflow). The callout server analyses metadata and adapts data as it comes in. The server usually builds its version of metadata and responds to OPES processor with an &AMS_tref; message. Adapted application message data can be sent next, using &DUM_tref; OCP message(s). The application message is then announced to be "completed" or "closed" using an &AME_tref; message. The transaction may be closed using a &TE_tref; message as well. All these messages correspond to adapted data flow.

The OPES processor receives the adapted application message sent by the callout server. Other OPES processor actions specific to the application message received are out of this specification scope.

OCP Core specifies transactions interface dedicated to exchanging a single original application message and a single adapted application message. Some application protocols may require multiple adapted versions for a single original application message or even multiple original messages to be exchanged as a part of a single OCP transaction. For example, a single original e-mail message may need to be transformed into several e-mail messages, one custom message for each recipient. OCP extensions MAY document mechanisms for exchanging multiple original and/or multiple adapted application messages within a single OCP transaction.

Either OCP agent can terminate application message delivery, transaction, or connection by sending an appropriate OCP message. Usually, the callout server terminates adapted application message delivery and the transaction. Premature and abnormal terminations at arbitrary times are supported. The termination message includes a result description.

In addition to messages carrying application data, OCP agents may also exchange messages related to their configuration, state, transport connections, application connections, etc. A callout server may remove itself from the application message processing loop. A single OPES processor can communicate with many callout servers and vice versa. Though many OCP exchange patterns do not follow a classic client-server model, it is possible to think of an OPES processor as an "OCP client" and of a callout server as an "OCP server". The OPES architecture document describes configuration possibilities. The following informal rules illustrate relationships between connections, transactions, OCP messages, and application messages: An OCP agent may communicate with multiple OCP agents. Communication with multiple OCP agents is outside of this specification scope. An OPES processor may have multiple concurrent OCP connections to a callout server. Communication over multiple OCP connections is outside of this specification scope. A connection may carry multiple concurrent transactions. A transaction is always associated with a single connection (i.e., a transaction cannot span multiple concurrent connections). A connection may carry at most one message at a time, including control messages and transaction-related messages. A message is always associated with a single connection (i.e., a message cannot span multiple concurrent connections). A transaction is a sequence of messages related to application of a given set of callout services to a single application message. A sequence of transaction messages from an OPES processor to a callout server is called original flow. A sequence of transaction messages from a callout server to an OPES processor is called adapted flow. The two flows may overlap in time. In OCP Core, a transaction is associated with a single (original) and a single (adapted) application message. OCP Core extensions may extend transaction scope to more application messages. An application message (adapted or original) is transferred using a sequence of OCP messages.

OCP violations, resource limits, external dependencies, and other factors may lead to states when an OCP agent is not receiving required messages from the other OCP agent. OCP Core defines no messages to address such situations. In the absence of any extension mechanism, OCP agents must implement timeouts for OCP operations: an OCP agent MUST forcefully terminate any OCP connection, negotiation, transaction, etc. that is not making progress. This rule covers both dead- and livelock situations. In their implementation, OCP agents MAY rely on transport-level or other external timeouts if such external timeouts are guaranteed to happen for a given OCP operation. Depending on the OCP operation, an agent may benefit from "pinging" the other side using a &PQ_tref; message before terminating an OCP transaction or connection. The latter is especially useful for adaptations that may take a long time at the callout server before producing any adapted data.

OCP communication is assumed to usually take place over TCP/IP connections on the Internet (though no default TCP port is assigned to OCP in this specification). This does not preclude OCP from being implemented on top of other transport protocols, or on other networks. High-level transport protocols such as BEEP may be used. OCP Core requires a reliable and message-order-preserving transport; any protocol that provides such guarantees can be used; the mapping of OCP message structures onto the transport data units of the protocol in question is outside the scope of this specification. OCP Core is application-agnostic. OCP messages can carry application-specific information as payload or as application-specific message parameters. OCP Core overhead in terms of extra traffic on the wire is about 100-200 octets per small application message. Pipelining, preview, data preservation, and early termination optimizations as well as as-is encapsulation of application data make fast exchange of application messages possible.

As defined in , an OCP message is a basic unit of communication between an OPES processor and a callout server. A message is a sequence of octets formatted according to syntax rules. Message semantics is defined in . Messages are transmitted on top of OCP transport. OCP messages deal with transport and transaction management as well as application data exchange between a single OPES processor and a single callout server. Some messages can only be emitted by an OPES processor; some only by a callout server; some can be emitted by both OPES processor and callout server. Some messages require responses (one could call such messages "requests"); some can only be used in response to other messages ("responses"); some may be sent without solicitation and/or may not require a response.

An OCP message consists of a message name followed by optional parameters and payload. The exact message syntax is defined by the following Augmented Backus-Naur Form (ABNF) :

Several normative rules accompany the above ABNF: There is no "implied linear space" (LWS) rule. LWS rules are common to MIME-based grammars, but are not used here. The whitespace syntax is restricted to what is explicitly allowed by the above ABNF. All protocol elements are case sensitive unless specified otherwise. In particular, message names and parameter names are case sensitive. Sizes are interpreted as decimal values and cannot have leading zeros. Sizes do not exceed &SIZE_MAX;. The size attribute in a quoted-value encoding specifies the exact number of OCTETs following the column (':') separator. If size OCTETs are not followed by a quote ('"') character, the encoding is syntactically invalid. Empty quoted-values are encoded as a 4-OCTET sequence "0:". Any bare-value can be encoded as a quoted-value. A quoted-value is interpreted after the encoding is removed. For example, number 1234 can be encoded as four OCTETs 1234 or as eight OCTETs "4:1234", yielding exactly the same meaning. Unicode UTF-8 is the default encoding. Note that ASCII is a UTF-8 subset, and that the syntax prohibits non-ASCII characters outside of the "data" element. Messages violating formatting rules are, by definition, invalid. See for rules governing processing of invalid messages.

OCP message samples in this specification and its extensions may not be typeset to depict minor syntactical details of OCP message format. Specifically, SP and CRLF characters are not shown explicitly. No rendering of an OCP message can be used to infer message format. The message format definition above is the only normative source for all implementations. On occasion, an OCP message line exceeds text width allowed by this specification format. A backslash ("\"), a "soft linebreak" character, is used to emphasize a protocol-violating presentation-only linebreak. Bare backslashes are prohibited by OCP syntax. Similarly, a "\r\n" string is sometimes used to emphasize the presence of a CRLF sequence, usually before OCP message payload. Normally, visible end of line corresponds to the CRLF sequence on the wire. The next section contains specific OCP message examples, some of which illustrate the above rendering techniques.

OCP syntax provides for compact representation of short control messages and required parameters while allowing for parameter extensions. Below are examples of short control messages. The required CRLF sequence at the end of each line is not shown explicitly (see ).

&PQ;; &TS; 1 2; &DWM; 22; &DWP; 22 16; x-doit "5:xyzzy"; The above examples contain atomic anonymous parameter values such as number and string constants. OCP messages sometimes use more complicated parameters such as item lists or structures with named values. As both messages below illustrate, structures and lists can be nested:

&NO; ({"28:http://iana.org/assignments/opes/ocp/tls"}); &NO; ({\ "50:http://iana.org/assignments/opes/ocp/http/response" Optional-Parts: (request-header) },{\ "50:http://iana.org/assignments/opes/ocp/http/response" Optional-Parts: (request-header,request-body) Transfer-Encodings: (chunked) }); Optional parameters and extensions are possible using named parameters approach as illustrated by the following example. The &DWM_ref; message in the example has two anonymous parameters (the last one being an extension) and two named parameters (the last one being an extension).

&DWM; 1 3 Size-Request: 16384 X-Need-Info: "26:twenty six octet extension"; Finally, any message may have a payload part. For example, the &DUM_tref; message below carries 8865 octets of raw data.

&DUM; 1 13 Modp: 75 \r\n 8865:... 8865 octets of raw data ...;

Most OCP messages defined in this specification have short names, formed by abbreviating or compressing a longer but human-friendlier message title. Short names without a central registration system (like this specification or IANA registry) are likely to cause conflicts. Informal protocol extensions should avoid short names. To emphasize what is already defined by message syntax, implementations cannot assume that all message names are very short.

An OCP transaction is a logical sequence of OCP messages processing a single original application message. The result of the processing may be zero or more application messages, adapted from the original. A typical transaction consists of two message flows: a flow from the OPES processor to the callout server (sending original application message) and a flow from the callout server to the OPES processor (sending adapted application messages). The number of application messages produced by the callout server and whether the callout server actually modifies original application message may depend on the requested callout service and other factors. The OPES processor or the callout server can terminate the transaction by sending a corresponding message to the other side. An OCP transaction starts with a &TS_tref; message sent by the OPES processor. A transaction ends with the first &TE_tref; message sent or received, explicit or implied. a &TE; message can be sent by either side. Zero or more OCP messages associated with the transaction can be exchanged in between. The figure below illustrates possible message sequence (prefix "P" stands for the OPES processor; prefix "S" stands for the callout server). Some message details are omitted.

This specification contains many criteria for valid OCP messages and their parts, including syntax rules, semantics requirements, and relationship to agents state. "Invalid input" in this context means messages or message parts that violate at least one of the normative rules. A message with an invalid part is, by definition, invalid. If an OCP agent resources are exhausted while parsing or interpreting a message, the agent MUST treat the corresponding OCP message as invalid. Unless explicitly allowed otherwise, an OCP agent MUST terminate the transaction if it receives an invalid message with transaction scope and MUST terminate the connection if it receives an invalid message with a connection scope. A terminating agent MUST use the result status code of 400 and MAY specify termination cause information in the result status reason parameter (see ). If an OCP agent is unable to determine the scope of an invalid message it received, the agent MUST treat the message as having connection scope. OCP usually deals with optional but invasive application message manipulations where correctness ought to be valued above robustness. For example, a failure to insert or remove certain optional web page content is usually far less disturbing than corrupting (making unusable) the host page while performing that insertion or removal. Most OPES adaptations are high-level in nature, which makes it impossible to automatically assess correctness of adaptations, especially if "robustness guesses" are involved.

The negotiation mechanism allows OCP agents to agree on mutually acceptable set of features, including optional and application-specific behavior as well as OCP extensions. For example, transport encryption, data format, and support for a new message can be negotiated. Negotiation implies intent for a behavioral change. For a related mechanism allowing an agent to query capabilities of its counterpart without changing counterpart's behavior, see &AQ_tref; and &AA_tref; message definitions. Most negotiations require at least one round trip time delay. In rare cases when other side's response is not required immediately, negotiation delay can be eliminated, with an inherent risk of an overly optimistic assumption about the negotiation response. A detected violation of negotiation rules leads to OCP connection termination. This design reduces the number of negotiation scenarios resulting in a deadlock when one of the agents is not compliant. Two core negotiation primitives are supported: negotiation offer and negotiation response. A &NO_tref; message allows an agent to specify a set of features from which the responder has to select at most one feature it prefers. The selection is sent using a &NR_tref; message. If the response is positive, both sides assume that the selected feature is in effect immediately (see for details). If the response is negative, no behavioral changes are assumed. In either case, further offers may follow. Negotiating OCP agents have to take into account prior negotiated (i.e., already enabled) features. OCP agents MUST NOT make and MUST reject offers that would lead to a conflict with already negotiated features. For example, an agent cannot offer an HTTP application profile for a connection that already has SMTP application profile enabled because there would be no way to resolve the conflict for a given transaction. Similarly, once TLSv1 connection encryption is negotiated, an agent must not offer and must reject offers for SSLv2 connection encryption (unless a negotiated feature explicitly allows for changing encryption scheme on the fly). &NO_tref; messages may be sent by either agent. OCP extensions documenting negotiation MAY assign initiator role to one of the agents, depending on the feature being negotiated. For example, negotiation of transport security feature should be initiated by OPES processors to avoid situations where both agents wait for each other to make an offer. Since either agent may make an offer, two "concurrent" offers may be made at the same time, by the two communicating agents. Unmanaged concurrent offers may lead to a negotiation deadlock. By giving OPES processor a priority, offer handling rules ensure that only one offer per OCP connection is honored at a time, and the other concurrent offers are ignored by both agents.

A Negotiation Phase is a mechanism to ensure that both agents have a chance to negotiate all features they require before proceeding further. Negotiation Phases have OCP connection scope and do not overlap. For each OCP agent, Negotiation Phase starts with the first &NO_tref; message received or the first &NR_tref; message sent, provided the message is not a part of an already existing Phase. For each OCP agent, Negotiation Phase ends with the first &NR_tref; message (sent or received) after which the agent expects no more negotiations. Agent expectation rules are defined later in this section. During a Negotiation Phase, an OCP agent MUST NOT send messages other than the following "Negotiation Phase messages": &NO_t;, &NR_t;, &AQ_t;, &AA_t;, &PQ_t;, &PA_t;, &PR_t;, and &CE_t;. Multiple Negotiation Phases may happen during the lifespan of a single OCP connection. An agent may attempt to start a new Negotiation Phase immediately after the old Phase is over, but it is possible that the other agent will send messages other than "Negotiation Phase messages" before receiving the new &NO_t;. The agent that starts a Phase has to be prepared to handle those messages while its offer is reaching the recipient. An OPES processor MUST make a negotiation offer immediately after sending a &CS_tref; message. If the OPES processor has nothing to negotiate, the processor MUST send a &NO_t; message with an empty features list. These two rules bootstrap the first Negotiation Phase. Agents are expected to negotiate at least the application profile for OCP Core. Thus, these bootstrapping requirements are unlikely to result in any extra work. Once a Negotiation Phase starts, an agent MUST expect further negotiations if and only if the last &NO; sent or the last &NR; received contained a true "Offer-Pending" parameter value. Informally, an agent can keep the phase open by sending true "Offer-Pending" parameters with negotiation offers or responses. Moreover, if there exist a possibility that the agent may need to continue the Negotiation Phase, the agent must send a true "Offer-Pending" parameter.

Below is an example of the simplest negotiation possible. The OPES processor is offering nothing and is predictably receiving a rejection. Note that the &NR; message terminates the Negotiation Phase in this case because neither of the messages contains a true "Offer-Pending" value:

P: NO (); S: NR; The next example illustrates how a callout server can force negotiation of a feature that an OPES processor has not negotiated. Note that the server sets the "Offer-Pending" parameter to true when responding to the processor &NO_t; message. The processor chooses to accept the feature:

P: NO (); S: NR Offer-Pending: true ; S: NO ({"22:ocp://feature/example/"}) Offer-Pending: false ; P: NR {"22:ocp://feature/example/"}; If the server changes its mind to continue the above negotiations after sending a true "Offer-Pending" value, the server's only option would be send an empty negotiation offer (see the first example above). If the server does nothing instead, the OPES processor would wait for the server and would eventually timeout the connection. The following example shows a dialog with a callout server that insists on two imaginary features to be used: strong transport encryption and use of volatile storage for responses. The server is designed to exchange no sensitive messages until both features are enabled. Naturally, the volatile storage feature has to be negotiated securely. The OPES processor supports one of the strong encryption mechanisms but prefers not to offer (volunteer support for) strong encryption, perhaps for performance reasons. The server has to send a true "Offer-Pending" parameter to get a chance to offer strong encryption (which is successfully negotiated in this case). Any messages sent by either agent after the (only) successful &NR; response are encrypted with "strongB" encryption scheme. The OPES processor does not understand the volatile storage feature, and the last negotiation fails (over an strongly encrypted transport connection).

P: NO ({"29:ocp://example/encryption/weak"}) ; S: NR Offer-Pending: true ; S: NO ({"32:ocp://example/encryption/strongA"},\ {"32:ocp://example/encryption/strongB"}) Offer-Pending: true ; P: NR {"32:ocp://example/encryption/strongB"} ; ... all traffic below is encrypted using strongB ... S: NO ({"31:ocp://example/storage/volatile"}) Offer-Pending: false ; P: NR Unknowns: ({"31:ocp://example/storage/volatile"}) ; S: CSE { 400 "33:lack of VolStore protocol support" } ; The following example from illustrates successful HTTP application profile negotiation:

P: NO ({"50:http://iana.org/assignments/opes/ocp/http/response" Aux-Parts: (request-header,request-body) }) SG: 5; S: NR {"50:http://iana.org/assignments/opes/ocp/http/response" Aux-Parts: (request-header) Pause-At-Body: 30 Wont-Send-Body: 2147483647 Content-Encodings: (gzip) } SG: 5;

Many adaptations do not require any data modifications (e.g., message logging or blocking). Some adaptations modify only a small portion of application message content (e.g., HTTP cookies filtering or ad insertion). Yet, in many cases, the callout service needs to see complete data. By default, unmodified data would first travel from the OPES processor to the callout server and then back. The "data preservation" optimization in OCP helps to eliminate the return trip if both OCP agents cooperate. Such cooperation is optional: OCP agents MAY support data preservation optimization. To avoid sending unmodified data back, a callout service has to know that the OPES processor has a copy of the data. Since data sizes can be very large and the callout service may not know in advance whether it will be able to utilize the processor copy, it is not possible to require the processor to keep a copy of the entire original data. Instead, it is expected that a processor may keep some portion of the data, depending on processor settings and state. When an OPES processor commits to keeping a data chunk, it announces its decision and the chunk parameters via a Kept parameter of a &DUM_tref; message. The callout server MAY "use" the chunk by sending a &DUY_tref; message referring to the preserved chunk. That OCP message does not have payload and, hence, the return trip is eliminated. Since the mapping between original and adapted data is not known to the processor, the processor MUST keep the announced-as-preserved chunk until the end of the corresponding transaction, unless the callout server explicitly tells the processor that the chunk is not needed. As implied by the above requirement, the processor cannot assume that a data chunk is no longer needed just because the callout server sent a &DUY_tref; message or adapted data with, say, the same offset as the preserved chunk. For simplicity, preserved data is always a contiguous chunk of original data, described by an (offset, size) pair using a "Kept" parameter of a &DUM_tref; message. An OPES processor may volunteer to increase the size of the kept data. An OPES processor may increase the offset if the callout server indicated that the kept data is no longer needed. Both agents may benefit from data reuse. An OPES processor has to allocate storage to support this optimization while a callout server does not. On the other hand, it is the callout server that is responsible for relieving the processor from data preservation commitments. There is no simple way to resolve this conflict of interest on a protocol level. Some OPES processors may allocate a relatively small buffer for data preservation purposes and stop preserving data when the buffer gets full. Such technique would benefit callout services that can quickly reuse or discard kept data. Another processor strategy would be to size the buffer based on historical data reuse statistics. To improve chances of beneficial cooperation, callout servers are strongly encouraged to immediately notify OPES processors of unwanted data. The callout server that made a decision not to send &DUY_tref; messages (for a specific data ranges or at all), SHOULD immediately inform the OPES processor of that decision with the corresponding &DPI_tref; message(s) or other mechanisms.

Many callout services adapt small portions of large messages and would prefer not to be in the loop when that adaptation is over. Some callout services may not be interested in data modification and would prefer not to send data back to the OPES processor, even if the OPES processor is not supporting the data preservation optimization. By OCP design, unilateral premature dataflow termination by a callout server would lead to termination of an OCP transaction with an error. Thus, the two agents must cooperate to allow for error-free premature termination. This section documents two mechanisms for premature termination of original or adapted dataflow. In combination, the mechanisms allow the callout server to get completely out of the processing loop.

There are scenarios when a callout server is not interested in the remaining original dataflow. For example, a simple access blocking or "this site is temporary down" callout service needs to send an adapted (generated) application message, but would prefer not to receive original data from the OPES processor. OCP Core supports premature original dataflow termination via the &DWSR_tref; message. A callout server that does not want to receive additional original data (beyond a certain size) sends a &DWSR; message. The OPES processor receiving a &DWSR; message terminates original dataflow by sending an &AME_tref; message with a 206 (partial) status code. The following figure illustrates a typical sequence of events. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while waiting for the opposing agent reaction.

OPES Callout Processor Server &DUM;> <&DUM; &DUM;> <&DWSR; <-- server is ready to stop receiving ... _____/<&DUM; <-- server continues as usual &DUM;>______/ <&DUM; &AME;> ... <-- processor stops sending original data \_____ <&DUM; \______<&DUM; <&DUM; <-- server continues to send adapted data ... <&AME; The mechanism described in this section has no effect on the adapted dataflow. Receiving an &AME_tref; message with 206 (partial) result status code from the OPES processor does not introduce any special requirements for the adapted dataflow termination. However, it is not possible to terminate adapted dataflow prematurely after the original dataflow has been prematurely terminated (see ).

There are scenarios when a callout service may want to stop sending adapted data before a complete application message has been sent. For example, a logging-only callout service needs to receive all application messages, but would prefer not to send their copies back to the OPES processor. OCP Core supports premature adapted dataflow termination via a combination of &DWSS_tref; and &DSS_tref; messages. A callout service that wants to stop sending data sends a &DWSS; message, soliciting an OPES processor permission to stop. While waiting for the permission, the server continues with its usual routine. An OPES processor receiving a &DWSS_tref; message responds with a &DSS_tref; message. The processor may then pause to wait for the callout server to terminate the adapted dataflow or may continue to send original data while making a copy of it. Once the server terminates the adapted dataflow, the processor is responsible for using original data (sent or paused after sending &DSS;) instead of the adapted data. The callout server receiving a &DSS; message terminates the adapted dataflow (see &DSS_tref; message definition for the exact requirements and corner cases). The following figure illustrates a typical sequence of events, including a possible pause in original dataflow when the OPES processor is waiting for the adapted dataflow to end. The downward lines connecting the two dataflows illustrate the transmission delay that allows for more OCP messages to be sent while waiting for the opposing agent reaction.

OPES Callout Processor Server &DUM;> <&DUM; &DUM;> <&DWSS; <-- server is ready to stop sending ... _____/<&DUM; <-- server continues as usual, &DUM;>______/ <&DUM; waiting for DSS &DSS;> ... \_____ <&DUM; possible \______<&DUM; org-dataflow <&AME; 206 <-- server terminates adapted dataflow pause _____/ upon receiving the DSS message ______/ &DUM;> <-- processor resumes original dataflow &DUM;> to the server and starts using ... original data without adapting it &AME;> Premature adapted dataflow preservation is not trivial because the OPES processor is relying on the callout server to provide adapted data (modified or not) to construct the adapted application message. If the callout server wants to quit its job, special care must be taken to ensure that the OPES processor is capable of constructing the complete application message. On a logical level, this mechanism is equivalent to switching from one callout server to another (non-modifying) callout server in the middle of an OCP transaction. Other than a possible pause in the original dataflow, the mechanism described in this section has no effect on the original dataflow. Receiving an &AME_tref; message with 206 (partial) result status code from the callout server does not introduce any special requirements for the original dataflow termination.

Some adaptation services work on application message prefixes and are not interested in being in the adaptation loop once their work is done. For example, an ad insertion service that did its job by modifying the first fragment of a web "page" would not be interested in receiving more original data or performing further adaptations. The 'Getting Out Of The Loop' optimization allows a callout server to get completely out of application message processing loop. The "Getting Out Of The Loop" optimization is possible by terminating the adapted dataflow () and then terminating the original dataflow (). The order of termination is very important. If the original dataflow is terminated first, the OPES processor would not allow the adapted dataflow to be terminated prematurely because the processor would not be able to reconstruct the remaining portion of the adapted application message; the processor would not know which suffix of the remaining original data needs to follow the adapted parts. The mapping between original and adapted octets is known only to the callout service. An OPES processor that received a &DWSS; message followed by a &DWSR; message MUST NOT send an &AME; message with a 206 (partial) status code before sending a &DSS; message. Informally, this rule means that the callout server that wants to get out of the loop fast should send a &DWSS; message immediately followed by a &DWSR; message; the server does not need to wait for the OPES processor's permission to terminate adapted dataflow before requesting the OPES processor to terminate original dataflow.

A protocol element type is a named set of syntax and semantics rules. This section defines a simple, formal declaration mnemonic for protocol element types, labeled PETDM. PETDM simplicity is meant to ease type declarations in this specification. PETDM formality is meant to improve interoperability among implementations. Two protocol elements are supported by PETDM: message parameter values and messages. All OCP Core parameter and message types are declared using PETDM. OCP extensions SHOULD use PETDM when declaring new types. Atom, list, structure, and message constructs are four available base types. Their syntax and semantics rules are defined in . New types can be declared in PETDM to extend base types semantics, using the following declaration templates. The new semantics rules are meant to be attached to each declaration using prose text. Things in angle brackets are template placeholders, to be substituted with actual type names or parameter name tokens. Square brackets surround optional elements such as structure members or message payload. Declaring a new atomic type:

: extends atom;]]> Declaring a new list with old-type-name items:

: extends list of ;]]> Unless explicitly noted otherwise, empty lists are valid and have semantics of a absent parameter value. Declaring a new structure with members:

: extends structure with {

[] ...; : ; : ; [: ]; ... };]]>

The new structure may have anonymous members and named members. Neither group have to exist. Note that it is always possible for extensions to add more members to old structures without affecting type semantics because unrecognized members are ignored by compliant agents. Declaring a new message with parameters:

: extends message with {

[] ...; : ; : ; [: ]; ... };]]>

The new type name becomes the message name. Just like when extending a structure, the new message may have anonymous parameters and named parameters. Neither group have to exist. Note that it is always possible for extensions to add more parameters to old messages without affecting type semantics because unrecognized parameters are ignored by compliant agents. Extending a type with more semantics details:

: extends ;]]> Extending a structure- or message-base type:

: extends with {

[] ...; : ; : ; [: ]; ... };]]>

New anonymous members are appended to the anonymous members of the old type, and new named members are merged with named members of the old type. Extending a message-base type with payload semantics:

: extends with { ... } and payload;]]> Any any OCP message can have payload, but only some message types have known payload semantics. Like any parameter, payload may be required or optional. Extending type semantics without renaming the type:

: extends ::;]]> The above template can be used by OCP Core extensions that want to change the semantics of OCP Core types without renaming them. This technique is essential for extending OCP messages because message name is the same as the message type name. For example, an SMTP profile for OCP might use the following declaration to extend an &AMS_tref; message with Am-Id, a parameter defined in that profile:

&AMS;: extends Core::&AMS; with { Am-Id: am-id; }; All extended types may be used as a replacement of the types they extend. For example, a &NO_tref; message uses a parameter of type Features. Features is a list of feature items. A Feature is a structure-based type. An OCP extension (e.g., an HTTP application profile) may extend the feature type and use a value of that extended type in a negotiation offer. Recipients that are aware of the extension will recognize added members in feature items and negotiate accordingly. Other recipients will ignore them. OCP Core namespace tag is "Core". OCP extensions that declare types MUST define their namespace tags (so that other extensions and documentation can use them in their PETDM declarations).

Anonymous parameters are positional: parameter's position (i.e., the number of anonymous parameters to the left) is its "name". Thus, when a structure or message have multiple optional anonymous parameters, parameters to the right can be used only if all parameters to the left are present. The following notation:

[name1] [name2] [name3] ... [nameN] is interpreted as:

[name1 [ name2 [ name3 ... [nameN] ... ]]] When adding an anonymous parameter to a structure or message that have optional anonymous parameters, the new parameter has to be optional, and the new parameter can only be used if all old optional parameters are in use. Named parameters do not have such limitations because they are not positional but associative; they are identified by their explicit and unique names.

This section defines parameter value types that are used for message definitions. Before using a parameter value, an OCP agent MUST check whether the value has the expected type (i.e., whether it complies with all rules from the type definition). A single rule violation means that the parameter is invalid. See for rules on processing invalid input. OCP extensions MAY define their own types. If they do, OCP extensions MUST define types with exactly one base format and MUST specify type of every new protocol element they introduce.

uri: extends atom; Uri (universal resource identifier) is an atom formatted according to URI rules in . Often, a uri parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Many uri parameters are URLs. Unless noted otherwise, URL identifiers do not imply existence of a serviceable resource at the location they specify. For example, an HTTP request for an HTTP-based URI identifier may result in a 404 (Not Found) response.

uni: extends atom; Uni (unique numeric identifier) is an atom formatted as dec-number and with a value in the [0, &SIZE_MAX;] inclusive range. A uni parameter is used as a unique (within a given scope) identifier. Uni semantics is incomplete without the scope specification. Some OCP messages create identifiers (i.e., bring them into scope). Some OCP messages destroy them (i.e, remove them from scope). An OCP agent MUST NOT create the same uni value more than once within the same scope. When creating a new identifier of the same type and within the same scope as some old identifier, an OCP agent MUST use a higher numerical value for the new identifier. The first rule makes uni identifiers suitable for cross-referencing logs and other artifacts. The second rule makes efficient checks of the first rule possible. For example, a previously used transaction identifier "xid" must not be used for a new &TS_tref; message within the same OCP transaction, even if a prior &TE_tref; message was sent for the same transaction. An OCP agent MUST terminate the state associated with uni uniqueness scope if all unique values have been used up.

size: extends atom; Size is an atom formatted as dec-number and with a value in the [0, &SIZE_MAX;] inclusive range. Size value is the number of octets in the associated data chunk. OCP Core cannot handle application messages that exceed &SIZE_MAX; octets in size, require larger sizes as a part of OCP marshaling process, or use sizes with granularity other than 8 bits. This limitation can be addressed by OCP extensions as hinted in .

offset: extends atom; Offset is an atom formatted as dec-number and with a value in the [0, &SIZE_MAX;] inclusive range. Offset is an octet position expressed in the number of octets relative to the first octet of the associated dataflow. The offset of the first data octet has a value of zero.

percent: extends atom; Percent is an atom formatted as dec-number and with a value in the [0, 100] inclusive range. Percent semantics is incomplete without associating its value with a boolean statement or assertion. The value of 0 indicates absolute impossibility. The value of 100 indicates an absolute certainty. In either case, the associated statement can be relied upon as if it was expressed in boolean rather than probabilistic terms. Values in the [1,99] inclusive range indicate corresponding levels of certainty that the associated statement is true.

boolean: extends atom; Boolean type is an atom with two valid values: true and false. A boolean parameter expresses truthfulness of the associated statement.

xid: extends uni; "Xid", an OCP transaction identifier, uniquely identifies an OCP transaction within an OCP connection.

sg-id: extends uni; "Sg-id", a service group identifier, uniquely identifies a group of services on an OCP connection.

modp: extends percent; Modp extends the percent type to express senders confidence that application data will be modified. The boolean statement associated with the percentage value is "data will be modified". Modification is defined as adaptation that changes numerical value of at least one data octet.

result: extends structure with { atom [atom]; }; OCP processing result is expressed as a structure with two documented members: a required Uni status code and an optional reason. The reason member contains informative textual information not intended for automated processing. For example,

{ 200 OK } { 200 "6:got it" } { 200 "27:27 octets in UTF-8 encoding" } This specification defines the following status codes: Result Status Codes code text semantics 200 OK Overall success. This specification does not contain any general actions for 200 status code recipients. 206 partial Partial success. This status code is documented for &AME_tref; messages only. The code indicates that the agent terminated the corresponding dataflow prematurely (i.e., more data would be needed to reconstruct a complete application message). Premature termination of one dataflow does not introduce any special requirements for the other dataflow termination. See dataflow termination optimizations for use cases. 400 failure An error, exception, or trouble. A recipient of a 400 (failure) result of an &AME;, &TE;, or &CE; message MUST destroy any state or data associated with the corresponding dataflow, transaction, or connection. For example, adapted version of the application message data must be purged from the processor cache if the OPES processor receives an &AME_t; message with result code of 400. Specific OCP messages may require code-specific actions. Extending result semantics is possible by adding new "result" structure members or negotiating additional result codes (e.g., as a part of a negotiated profile). A recipient of an unknown (in then-current context) result code MUST act as if code 400 (failure) was received. The recipient of a message without the actual result parameter, but with an optional formal result parameter MUST act as if code 200 (OK) was received. Textual information (the second anonymous parameter of the result structure) is often referred to as "reason" or "reason phrase". To assist manual troubleshooting efforts, OCP agents are encouraged to include descriptive reasons with all results indicating a failure. An OCP message with result status code of 400 (failure) is called "a message indicating a failure" in this specification.

feature: extends structure with { uri; }; Feature extends structure to relay an OCP feature identifier and to reserve a "place" for optional feature-specific parameters (sometimes called feature attributes). Feature values are used to declare support for and negotiate use of OCP features. This specification does not define any features.

features: extends list of feature; "Features" is a list of "feature" values. Unless noted otherwise, the list can be empty and features are listed in decreasing preference order.

service: extends structure with { uri; }; "Service" structure has one anonymous member, an OPES service identifier of type "uri". Services may have service-dependent parameters. An OCP extension defining a service for use with OCP MUST define service identifier and service-dependent parameters as additional "service" structure members, if any. For example, a service value may look like this:

{"37:http://iana.org/assignments/opes/ocp/tls" "8:blowfish"}

services: extends list of service; "Services" is a list of "service" values. Unless noted otherwise, the list can be empty and the order of the values is the requested or actual service application order.

Several parameter types such as "offset" apply to both original and adapted dataflow. It is relatively easy to misidentify type's dataflow affiliation, especially when parameters with different affiliation are mixed together in one message declaration. The following statements declare new dataflow-specific types using their dataflow-agnostic versions (denoted by a <type> placeholder). The following new types refer to original data only:

org-<type>: extends <type>; The following new types refer to adapted data only:

adp-<type>: extends <type>; The following new types refer to sender's dataflow only:

my-<type>: extends <type>; The following new types refer to recipient's dataflow only:

your-<type>: extends <type>; OCP Core specification uses the above type naming scheme to implement dataflow specialization for the following types: offset, size, and sg-id. OCP extensions SHOULD use the same scheme.

This section describes specific OCP messages. Each message is given a unique name and usually has a set of anonymous and/or named parameters. The order of anonymous parameters is specified in the message definitions below. No particular order for named parameters is implied by this specification. OCP extensions MUST NOT introduce order-dependent named parameters. No more than one named-parameter with a given name can appear in the message; messages with multiple equally-named parameters are semantically invalid. A recipient MUST be able to parse any message in valid format (see ), subject to recipient resources limitations. Unknown or unexpected message names, parameters, and payloads may be valid extensions. For example, an "extra" named parameter may be used for a given message, in addition to what is documented in the message definition below. A recipient MUST ignore any valid but unknown or unexpected name, parameter, member, or payload. Some message parameter values use uni identifiers to refer to various OCP states (see and ). These identifiers are created, used, and destroyed by OCP agents via corresponding messages. Except when creating a new identifier, an OCP agent MUST NOT send a uni identifier that corresponds to an inactive state (i.e., that was either never created or was already destroyed). Such identifiers invalidate the host OCP message (see ). For example, the recipient must terminate the transaction when the xid parameter in a &DUM_tref; message refers to an unknown or already terminated OCP transaction.

&CS;: extends message; A &CS_t; message indicates the start of an OCP connection. An OCP agent MUST send this message before any other message on the connection. If the first message an OCP agent receives is not &CS_t;, the agent MUST terminate the connection with a &CE_tref; message having 400 (failure) result status code. An OCP agent MUST send &CS_t; message exactly once. An OCP agent MUST ignore repeated &CS_t; messages. At any time, a callout server MAY refuse further processing on an OCP connection by sending a &CE_tref; message with status code 400 (failure). Note that the above requirement to send a &CS; message first still applies. With TCP/IP as transport, raw TCP connections (local and remote peer IP addresses with port numbers) identify an OCP connection. Other transports may provide OCP connection identifiers to distinguish logical connections that share the same transport. For example, a single BEEP channel may be designated as a single OCP connection.

&CE;: extends message with { [result]; }; &CE_t; Indicates an end of an OCP connection. The agent initiating closing or termination of a connection MUST send this message immediately prior to closing or termination. The recipient MUST free associated state, including transport state. Connection termination without a &CE_t; message indicates that the connection was prematurely closed, possibly without the closing-side agent prior knowledge or intent. When an OCP agent detects a prematurely closed connection, the agent MUST act as if a &CE_t; message indicating a failure was received. A &CE_t; message implies the end of all transactions, negotiations, and service groups opened or active on the connection being ended.

&SGC;: extends message with { my-sg-id services; }; An &SGC_t; message informs the recipient that a list of adaptation services has been associated with the given service group identifier ("my-sg-id"). Following this message, the sender can refer to the group using the identifier. The recipient MUST maintain the association until a matching &SGD_tref; message is received or the corresponding OCP connection is closed. Service groups have a connection scope. Transaction management messages do not affect existing service groups. Maintaining service group associations requires resources (e.g., storage to keep the group identifier and a list of service IDs). Thus, there is a finite number of associations an implementation can maintain. Callout servers MUST be able to maintain at least one association for each OCP connection they accept. If a recipient of a &SGC_t; message does not create the requested association, it MUST immediately terminate the connection with a &CE_tref; message indicating a failure.

&SGD;: extends message with { my-sg-id; }; A &SGD_t; message instructs the recipient to forget about the service group associated with the specified identifier. The recipient MUST destroy the identified service group association.

&TS;: extends message with { xid my-sg-id; }; Sent by an OPES processor, a &TS; message indicates the start of an OCP transaction. Upon receiving of this message, the callout server MAY refuse further transaction processing by responding with a corresponding &TE_tref; message. A callout server MUST maintain the state until it receives a message indicating the end of the transaction or until it terminates the transaction itself. The required "my-sg-id" identifier refers to a service group created with a &SGC_tref; message. The callout server MUST apply the list of services associated with "my-sg-id", in the specified order. This message introduces transaction identifier (xid).

&TE;: extends message with { xid [result]; }; Indicates the end of the identified OCP transaction. An OCP agent MUST send a &TE_t; message immediately after it makes a decision to send no more messages related to the corresponding transaction. Violating this requirement may cause, for example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed. This message terminates the life of the transaction identifier (xid).

&AMS;: extends message with { xid; [Services: services]; }; An &AMS; message indicates the start of the original or adapted application message processing and dataflow. The recipient MAY refuse further processing by sending an &AME_tref; message indicating a failure. When an &AMS; message is sent by the OPES processor, the callout server usually sends an &AMS; message back, announcing the creation of an adapted version of the original application message. Such announcement may be delayed. For example, the callout server may wait for more information to come from the OPES processor. When an &AMS; message is sent by the callout server, an optional "Services" parameter describes OPES services that the server MAY apply to the original application message. Usually, the "services" value matches what was asked by the OPES processor. The callout server SHOULD send a "Services" parameter the parameter value would differ from the list of services requested by the OPES processor. Since the same service may be known under many names, the mismatch does not necessarily imply an error).

&AME;: extends message with { xid [result]; }; An &AME; message indicates the end of the original or adapted application message processing and dataflow. The recipient should expect no more data for the corresponding application message. An &AME_t; message ends any data preservation commitments and any other state associated with the corresponding application message. An OCP agent MUST send an &AME_t; message immediately after it makes a decision to stop processing of its application message. Violating this requirement may cause, for example, unnecessary delays, rejection of new transactions, and even timeouts for agents that rely on this end-of-file condition to proceed.

&DUM;: extends message with { xid my-offset; [As-is: org-offset]; [Kept: org-offset org-size ]; [Modp: modp]; } and payload; A &DUM; message carries application data. It is the only OCP Core message with documented payload. The sender MUST NOT make any gaps in data supplied by &DUM_t; and &DUY_t; messages (i.e., the my-offset of the next data message must be equal to my-offset plus the payload size of the previous data message). Messages with gaps are invalid. The sender MUST send payload and MAY use empty payload (i.e., payload with zero size). A &DUM; message without payload is invalid. Empty payloads are useful for communicating meta-information about the data (e.g., modification predictions or preservation commitments) without sending data. An OPES processor MAY send a "Kept" parameter to indicate its current data preservation commitment for original data. When an OPES processor sends a "Kept" parameter, the processor MUST keep a copy of the specified data (the preservation commitment starts or continues). The Kept offset parameter specifies the offset of the first octet of the preserved data. The Kept size parameter is the size of preserved data. Note that data preservation rules allow (i.e., do not prohibit) OPES processor to decrease offset and to specify a data range not yet fully delivered to the callout server. OCP Core does not require any relationship between &DUM; payload and the "Kept" parameter. If the "Kept" parameter value violates data preservation rules, but the recipient has not sent any &DUY_tref; messages for the given OCP transaction yet, then the recipient MUST NOT use any preserved data for the given transaction (i.e., must not sent any &DUY_tref; messages). If the "Kept" parameter value violates data preservation rules, and the recipient has already sent &DUY_tref; messages, the &DUM; message is invalid and the rules of apply. These requirements help preserve data integrity when "Kept" optimization is used by the OPES processor. A callout server MUST send a "Modp" parameter if the server can provide a reliable value and has not already sent the same parameter value for the corresponding application message. The definition of "reliable" is entirely up to the callout server. The data modification prediction includes &DUM; payload. That is, if attached payload has been modified, the modp value cannot be 0%. A callout server SHOULD send an "As-is" parameter if the attached data is identical to a fragment at the specified offset in the original dataflow. An "As-is" parameter specifying a data fragment that have not been sent to the callout server is invalid. The recipient MUST ignore invalid "As-is" parameters. Identical means that all adapted octets have the same numeric value as the corresponding original octets. This parameter is meant to allow for partial data preservation optimizations without a preservation commitment. The preserved data still crosses the connection with the callout server twice, but OPES processor may be able to optimize its handling of the data. The OPES processor MUST NOT terminate its data preservation commitment in reaction to receiving a &DUM_t; message.

&DUY;: extends message with { xid org-offset org-size; }; The callout server tells the OPES processor to use the "size" bytes of preserved original data starting at the specified offset, as if that data chunk came from the callout server in a &DUM_tref; message. The OPES processor MUST NOT terminate its data preservation commitment in reaction to receiving a &DUY_t; message.

&DPI;: extends message with { xid org-offset org-size; }; The &DPI_t; message describes an original data chunk using the first octet offset and size as parameters. The chunk is the only area of original data that callout server may be interested in referring to in future &DUY_tref; messages. This data chunk is referred to as "reusable data". The rest of the original data is referred to as "disposable data". Thus, disposable data consists of octets below the specified offset and at or above the (offset+size) offset. After sending this message, the callout server MUST NOT send &DUY_t; messages referring to disposable data chunk(s). If an OPES processor is not preserving some reusable data, it MAY start preserving that data. If the OPES processor preserves some disposable data, it MAY stop preserving that data. If an OPES processor does not preserve some disposable data, it MAY NOT start preserving that data. A callout server MUST NOT indicate reusable data areas that overlap with disposable data areas indicated in previous &DPI_t; messages. In other words, reusable data must not grow and disposable data must not shrink. If a callout server violates this rule, the &DPI_t; message is invalid (see ). The &DPI_t; message cannot force the OPES processor to preserve data. The term reusable in this context stands for callout server interest in reusing the data in the future, given the OPES processor cooperation. For example, an offset value of zero and the size value of &SIZE_MAX; indicates that the server may want to reuse all the original data. The size value of zero indicates that the server is not going to send any more &DUY_t; messages.

&DWSR;: extends message with { xid org-size; }; The &DWSR_t; message informs OPES processor that the callout server wants to stop receiving original data any time after receiving at least org-size worth of application message prefix. That is, the server is asking the processor to terminate original dataflow prematurely (see ) after sending at least org-size octets. An OPES processor receiving a &DWSR_tref; message SHOULD terminate original dataflow by sending an &AME_tref; message with a 206 (partial) status code. An OPES processor MUST NOT terminate its data preservation commitment in reaction to receiving a &DWSR_t; message. Just like with any other message, an OPES processor may use information supplied by &DWSR_t; to decide on future preservation commitments.

&DWSS;: extends message with { xid; }; The &DWSS_t; message informs OPES processor that the callout server wants to stop sending adapted data as soon as possible; the server is asking the processor for a permission to terminate adapted dataflow prematurely (see ). The OPES processor can grant such a permission using a &DSS_tref; message. Once the &DWSS; message is sent, the callout server MUST NOT prematurely terminate adapted dataflow until the server receives a &DSS; message from the OPES processor. If the server violates this rule, the OPES processor MUST act as if no &DWSS; message was received. The latter implies that the OCP transaction is terminated by the processor, with an error. An OPES processor receiving a &DWSS; message SHOULD respond with an &DSS_tref; message, provided the processor would not violate &DSS; message requirements by doing so. The processor SHOULD respond immediately once &DSS; message requirements can be satisfied.

&DSS;: extends message with { xid; }; The &DSS_t; message instructs the callout server to terminate adapted dataflow prematurely by sending an &AME_tref; message with a 206 (partial) status code. A callout server is expected to solicit the &DSS_t; message by sending a &DWSS_tref; message (see ). A callout server receiving a solicited &DSS_tref; message for a yet-unterminated adapted dataflow MUST immediately terminate dataflow by sending an &AME_tref; message with a 206 (partial) status code. If the callout server already terminated adapted dataflow, the callout server MUST ignore the &DSS_tref; message. A callout server receiving an unsolicited &DSS; message for a yet-unterminated adapted dataflow MUST either treat that message as invalid or as solicited (i.e., the server cannot simply ignore unsolicited &DSS; messages). The OPES processor sending a &DSS_tref; message MUST be able to correctly reconstruct adapted application message after the callout server terminates dataflow. This requirement implies that the processor must have access to any original data sent to the callout after the &DSS_tref; message, if any. Consequently, the OPES processor has to either send no data at all or keep a copy of it. If a callout server receives a &DSS; message and, in violation of the above rules, waits for more original data before sending an &AME_tref; response, a deadlock may occur: the OPES processor may wait for the &AME_tref; message to send more original data.

&DWP;: extends message with { xid your-offset; }; The &DWP_t; message indicates sender's temporary lack of interest in receiving data starting with the specified offset. This disinterest in receiving data is temporary in nature and implies nothing about sender's intent to send data. The "your-offset" parameter refers to dataflow originating at the OCP agent receiving the parameter. If, at the time the &DWP_t; message was received, the recipient has already sent data at the specified offset, the message recipient MUST stop sending data immediately. Otherwise, the recipient MUST stop sending data immediately after it sends the specified offset. Once the recipient stops sending more data, it MUST immediately send a &DPM_tref; message and MUST NOT send more data until it receives a &DWM_tref; message. As most OCP Core mechanisms, data pausing is asynchronous. The sender of the &DWP_t; message MUST NOT rely on the data being paused exactly at the specified offset or at all.

&DPM;: extends message with { xid; }; The &DPM_t; message indicates sender's commitment to send no more data until the sender receives a &DWM_tref; message. The recipient of the &DPM_t; message MAY expect the data delivery being paused. If the recipient receives data despite this expectation, it MAY abort the corresponding transaction with a &TE_tref; message indicating a failure.

&DWM;: extends message with { xid; [Size-request: your-size]; }; The &DWM_t; message indicates sender's need for more 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 &DPM_tref; 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 &DWM_t; 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.

&NO;: extends message with { features; [SG: my-sg-id]; [Offer-Pending: boolean]; }; A &NO_t; message solicits a selection of a single "best" feature out of a supplied list, using a &NR_tref; message. The sender is expected to list preferred features first when possible. The recipient MAY ignore sender preferences. If the list of features is empty, the negotiation is bound to fail but remains valid. Both OPES processor and callout server are allowed to send &NO_t; 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 &NO_t; message if it still expects a response to its previous offer on the same connection. If an OPES processor receives a &NO_t; 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 &NO_t; 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 &CE_tref; message indicating a failure. An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance. 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 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 SG parameter in negotiation offers, to avoid situations where encryption is enabled for only a portion of overlapping transactions on the same transport connection.

&NR;: extends message with { [feature]; [SG: my-sg-id]; [Rejects: features]; [Unknowns: features]; [Offer-Pending: boolean]; }; A &NR_t; message conveys recipient's reaction to a &NO_tref; 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 &CE_tref; message indicating a failure. A rejected offer (a.k.a., 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 &NR_t; message. The recipient of a &NR; message without the expected SG parameter MUST treat negotiation response as invalid. If negotiation offer lacks an SG parameter, the responder MUST NOT include that parameter in the &NR_t; message. The recipient of a &NR; message with an unexpected SG parameter MUST treat negotiation response as invalid. An optional "Offer-Pending" parameter is used for Negotiation Phase maintenance. The option's value defaults to "false". When accepting or rejecting an offer, the sender of the &NR_t; message MAY supply additional details via Rejects and Unknowns parameters. The Rejects parameter can be used to list features that were known to the &NO_tref; 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.

&AQ;: extends message with { feature; }; A &AQ_t; message solicits an immediate &AA_tref; response. The recipient MUST respond immediately with a &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 rather than automated fine-tuning of agent behavior and configuration. The latter may be better achieved by the OCP negotiation mechanism.

&AA;: extends message with { boolean; }; A &AA_t; message expresses senders support for a feature requested via a &AQ_tref; 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.

&PQ;: extends message with { [xid]; }; A &PQ_t; message solicits an immediate &PA_tref; response. The recipient MUST immediately respond to a &PQ; request, even if the transaction identifier is invalid from the recipient point of view.

&PA;: extends message with { [xid]; [Org-Data: org-size]; }; A &PA; message carries 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 been otherwise 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 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 &PQ_t; request, the agent MUST send the corresponding transaction ID (xid) when answering &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. Otherwise (i.e., the agent has already sent or received the &AME_tref; message for the original dataflow), the agent MUST NOT send the Org-data parameter. Informally, the &PA; message relays sender's progress with the transaction and original dataflow identified by the &PQ_tref; 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 point of view.

&PR;: extends message with { [xid]; [Org-Data: org-size]; }; A &PR; message carries senders state. The message semantics and associated requirements are identical to that of a &PA_tref; 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.

OPES treatment of IETF Internet Architecture Board (IAB) considerations are documented in .

This section examines security considerations for OCP. OPES threats are documented in . OCP relays application messages that may contain sensitive information. Appropriate transport encryption can be negotiated to prevent information leakage or modification (see ), but OCP agents may support unencrypted transport by default. Such default OCP agent 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 get 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 &SGC_tref; message instructs the recipient to maintain an association between a service group identifier and a list of services. Implementations that cannot handle resource exhaustion correctly increase security risks. The following are known OCP-related resources that may be exhausted during a compliant OCP message exchange: 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. OCP does not place an upper limit on the number of concurrent connections that a callout server may be instructed to create via &CS_tref; messages. OCP does not place an upper limit on the number of service group associations that a callout server may be instructed to create via &SGC_tref; messages. OCP does not place an upper limit on the number of concurrent transactions that a callout server may be instructed to maintain via &TS_tref; messages. 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 &AMS_tref; messages.

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 any). Registered feature syntax and semantics are documented using PETDM notation. The IESG is responsible for assigning a designated expert to review each standards-track registration prior to the IANA making the 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://iana.org/assignments/opes/ocp/" prefix for feature "uri" parameters. It is suggested that the IANA populates resources identified by such "uri" parameters with corresponding feature registrations. It is also suggested that the IANA maintains an index of all registered OCP features at http://iana.org/assignments/opes/ocp/ URL or on a page linked from that URL. This specification defines no OCP features for IANA registration.

This specification defines compliance for the following compliance subjects: OPES processors (OCP client implementations), callout servers (OCP server implementations), OCP extensions. An OCP agent (a processor or callout server) may also be referred to as "sender" or "recipient" of an OCP message. A compliance subject is compliant if it satisfies all applicable "MUST" and "SHOULD" level requirements. By definition, to satisfy a "MUST" level requirement means to act as prescribed by the requirement; to satisfy a "SHOULD" level requirement means to either act as prescribed by the requirement or 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 all "SHOULD" violations are conscious. In other words, a "SHOULD" means "MUST satisfy or MUST have a reason to violate". It is expected that compliance claims are accompanied by a list of unsupported SHOULDs (if any), in an appropriate format, explaining why preferred behavior was not chosen. Only normative parts of this specification affect compliance. Normative parts are: parts explicitly marked using the word "normative", definitions, and phrases containing unquoted capitalized keywords from . Consequently, examples and illustrations are not normative.

OCP extensions MAY change any normative requirement documented in this specification, including OCP message syntax, except for the following rule: OCP extensions MUST require that changes to normative parts of OCP Core are negotiated prior to taking effect. In other words, this specification defines compliant agent behavior until changes to this specifications (if any) are successfully negotiated. For example, if an RTSP profile for OCP requires support for sizes exceeding &SIZE_MAX; octets, the profile specification can document appropriate OCP message syntax and semantics changes while requiring that RTSP adaptation agents negotiate "large size" support before using large sizes. Such negotiation can be bundled with negotiating another feature (e.g., negotiating an RTSP profile may imply support for large sizes). As implied by the above rule, OCP extensions may dynamically alter the negotiation mechanism itself. 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.

This appendix is not normative. The table below summarizes key OCP message properties. For each message, the table provides the following information: message name as seen on the wire; human-friendly message title; whether this specification documents message semantics as sent by an OPES processor; whether this specification documents message semantics as sent by a callout server; related messages such as associated request or response message or associated state message. name title P S tie &CS; &CS_jt; X X &CE; &CE; &CE_jt; X X &CS; &SGC; &SGC_jt; X X &SGD; &TS; &SGD; &SGD_jt; X X &SGC; &TS; &TS_jt; X &TE; &SGC; &TE; &TE_jt; X X &TS; &AMS; &AMS_jt; X X &AME; &AME; &AME_jt; X X &AMS; &DSS; &DUM; &DUM_jt; X X &DUY; &DWP; &DUY; &DUY_jt; X &DUM; &DPI; &DPI; &DPI_jt; X &DUY; &DWSS; &DWSS_jt; X &DWSR; &DSS; &DWSR; &DWSR_jt; X &DWSS; &DSS; &DSS_jt; X &DWSS; &DWP; &DWP_jt; X X &DPM; &DPM; &DPM_jt; X X &DWP; &DWM; &DWM; &DWM_jt; X X &DPM; &NO; &NO_jt; X X &NR; &SGC; &NR; &NR_jt; X X &NO; &PQ; &PQ_jt; X X &PA; &PA; &PA_jt; X X &PQ; &PR; &PR; &PR_jt; X X &PA; &AQ; &AQ_jt; X X &AA; &AA; &AA_jt; X X &AQ; This appendix is not normative. The table below summarizes OCP states. Some states are maintained across multiple transactions and application messages. Some states correspond to a single request/response dialog; asynchronous nature of most OCP message exchanges requires OCP agents to process other messages while waiting for a response to a request and, hence, maintaining the state of the dialog. For each state, the table provides the following information: short state label messages creating this state messages destroying this state associated identifier, if any state birth death ID connection &CS; &CE; service group &SGC; &SGD; sg-id transaction &TS; &TE; xid application message and dataflow &AMS; &AME; premature org-dataflow termination &DWSR; &AME; premature adp-dataflow termination &DWSS; &DSS; &AME; paused dataflow &DPM; &DWM; preservation commitment &DUM; &DPI; &AME; negotiation &NO; &NR; progress inquiry &PQ; &PA; ability inquiry &PQ; &PA; The author gratefully acknowledges the contributions of: Abbie Barbir (Nortel Networks), Oskar Batuner (Independent Consultant), Larry Masinter (Adobe), Karel Mittig (France Telecom R&D), Markus Hofmann (Bell Labs), Hilarie Orman (The Purple Streak), Reinaldo Penno (Nortel Networks), Martin Stecher (Webwasher) as well as an anonymous OPES working group participant. Special thanks to Marshall Rose for his xml2rfc tool. RFC Editor Note: This section is to be removed during the final publication of the document. Internal WG revision control ID: $Id: ocp-core.xml,v 1.88 2004/05/04 05:54:09 rousskov Exp $ Explicitly and formally required that negotiated features are effective immediately and polished negotiation example to reflect that. Further clarified that extensions may change Core requirements, including negotiation mechanisms, as long as all changes are negotiated first. For example, the first dynamic change to the negotiation mechanism would have to be negotiated using the Core negotiation mechanism. Informally noted that extensions may add further restrictions on negotiation semantics. Filled IANA Considerations section and changed example URIs to reflect proposed IANA registration format. Added an OPES Document Map boilerplate. Be explicit about one premature dataflow termination not affecting the other dataflow termination. Editorial changes. Polished Abstract. Replaced overlapping DIY and DWOL mechanisms with atomic mechanisms to terminate original or adapted dataflow that can be combined to support "Getting Out Of The Data Loop" optimization. Streamlined related 206 (partial) status code definition. Added namespace tags to PETDM so that extensions can extend Core messages without renaming them (changing OCP message type changes its name which is not acceptable for most extensions). The same technique can be useful for extending Core types when the extended type is meant to be used everywhere the original core type was used. Renamed "application binding" to "application profile". Acknowledged Larry Masinter contribution. Larry reviewed HTTP Adaptations draft and gave a few very useful comments related to OCP Core. Editorial changes. Be more explicit about absence of OCP connection encryption and agent authentication requirements in OCP Core. Removed application message identifier (am-id). OCP Core now defaults to single original and adapted messages, leaving it up to OCP extensions to specify how to distinguish multiple original or adapted dataflows within the same transaction. HTTP binding does not need to do that. SMTP binding will need to do that. Editorial changes. Added request/response states to State Summary appendix. Simplified/streamlined ping-pong interface: Moved "unsolicited pong" semantics to a Progress Report (PR) message. Moved "solicited pong" semantics to a Progress Answer (PA) message. Renamed Progress Request (ping) to Progress Query (PQ). Renamed "Progress" parameter to "Org-Data". Added informative summaries of OCP messages and states as appendices. Added a requirement for uni values to increase so that agents can easily enforce uni uniqueness. Added Dataflow-specific types for size, offset, am-id, and sg-id. Resolved several ambiguities in message declarations: "which am-id should this message use, original or adapted?". Renamed Data Interested in Using Yours (DIUY) message to Data Preservation Interest (DPI). Renamed Data Won't Look At Yours (DWLY) message to Ignoring Your Data (DIY). Renamed Data Pause (data-pause) message to Want Data Paused (DWP). Renamed Data Paused (data-paused) message to Paused My Data (DPM). Renamed Data Need (data-need) message to Wont More Data (DWM). Renamed Data Want Out (DWO) message to Want Out Of The Data Loop (DWOL). Changed Kept parameter syntax and clarified/simplified/improved its semantics. Renamed DWSY message to DIUY and clarified/simplified/improved its semantics. All data preservation interface is now built around a single continues data chunk that Kept parameter and DIUY message refer to when they need to specify what is preserved or needs to be. Added Negotiation Phase and an optional "Offer-Pending" parameter to NO and NR messages to ensure that an OCP agent can negotiate vital features before application data is seen on the wire. Polished dataflow pausing interface and made its support mandatory. Gave an OPES processor the same abilities to pause/resume dataflow that a callout server has. Added a Timeouts section, requiring all OCP agents to support timeouts of some sort. Removed data loss to-do item. Extensions would have to take care of that complication. Merged Capability and State Inquiry mechanisms into a simpler Ability Query/Answer (AQ/AA) interface. Added a new MUST: OCP extensions must document what it means to "support" a given feature they document. The definition is needed for generation of AA messages. Removed DoS attacks against callout service as a security consideration because its place is in OPES architecture or OPES security drafts. Merged DACK mechanism into a polished ping-pong mechanism. Added a new requirement: An OCP application binding specification MUST document whether multiple adapted versions of an original message are allowed. Declared all OCP messages using PETDM. Deleted "Application Protocol Requirements" Section as essentially unused. Simplified and polished CS message rules. Callout servers MUST send CS now so that processors can be sure the other end is talking OCP. Made "Type Declaration Mnemonic (TDM)" a top-level section titled "Protocol Element Type Declaration Mnemonic (PETDM)" and documented OCP message declaration mnemonic. Merged parameter type declarations with parameter declarations. Polished parameter type declarations. Started using TDM for Core value types. Added Data Want Out (DWO) message. Added Data Wont Look at Yours (DWLY) message. Renamed Wont-Use to more specific Wont-Send. Made Wont-Send parameter into a Data Wont Send Yours (DWSY) message because it controls original dataflow and is not specific to a particular adapted AM (there can be many). This change means that Data Use Yours (DUY) messages are no longer terminating preservation commitment by default. Thus, we lost a little in terms of performance (unless processors look ahead for DWSYs) but gained a lot of simplicity in terms of support for multiple adapted application messages (SMTP case). Added 206 (partial data) status code definition. 206 status code should be used with AME, not TE. Replaced "global scope" with "connection scope" in negotiation rules. Clarified negotiation mechanism when it comes to negotiating multiple [possibly conflicting] features. Clarified service group-scoped negotiations. Agents must watch out for global conflicts when doing group-scoped negotiations and vice-versa. Added 'Out Of The Loop' Optimization section. Added 'Data Recycling' Optimization section. Added "Type Declaration Mnemonic" (TDM) to facilitate type declarations here and in OCP extensions. Removed optional "sizep" parameter. HTTP needs content-dependent parameter (AM-EL), and we do not know any generic application for sizep that would be worth supporting in Core. Documented backslash (\) and CRLF (\r\n) OCP message rendering tricks. Added named structure members to message BNF. Used MIME-like syntax already used for named parameters. Named members are needed to represent optional structure members. Removed leftovers of data-have message name. Use Data Use Mine instead (Karel Mittig). Anonymized named parameters and removed currently unused "rid" parameter in ping and pong messages (Karel Mittig). Renamed DUM.please-ack to "DUM.ack" (Karel Mittig). More work is needed to polish and simplify acknowledgment mechanism. Documented known resource-exhaustion security risks. Polished compliance definition. Avoid two levels of compliance. Added SG parameter to Negotiation Offer (NO) and Negotiation Response (NR) messages to limit the result of negotiations to the specified service group. Still need to document SG-related logic in the Negotiation section. Removed "services" parameter from Transaction Start (TS) message because we have to rely on service groups exclusively, because only service groups can have negotiated application profiles associated with them. Replaced data-id parameter with "Kept: kept-offset" and "Wont-Use: used-size" parameter. We probably need octet-based granularity, and old data-id only offered fragment-based granularity. Made AME and TE messages required. Documented result parameter syntax and two result codes: 200 (success) and 400 (failure). Added optional "result" parameter to CE. Fixed BNF to remove extra SP and "," in front of structure and list values. Fixed the type of "id" field in a "service" structure. Documented "sg-id" parameter. Renamed "copied" to "data-id" so that it can be used by both agents. An OPES processor uses named "Copied: data-id" parameter and a callout server uses anonymous "data-id" parameter (instead of previously documented "copy-am-offset"). Removed "rid" parameter from Negotiation Offer (NO) message as unused. Removed "size" parameter from messages with payload since payload syntax includes an explicit size value. Renamed Data Have (DH) message to Data Use Mine (DUM) message to preserve the symmetry with Data Use Yours (DUY) message and to prepare for possible addition of Data Check Mine (DCM) message. Finished phasing out the "modified" message parameter. Added an "As-is" named-parameter to mark adapted pieces of data identical to the original. Replaced a huge "message nesting" figure with a set of short specific rules illustrating the same concept. Added a new "Exchange Patterns" subsection to accommodate the rules and related matters. The figure was not clear enough. Hopefully, the rules are. Removed the concept of OCP connection as a group of messages sharing the same group of callout services. Now there is no difference between OCP connection and transport connection. Added a concept of a Service Group, which is a list of services with an identifier, for now. A given Service Group is referenced by the creating/destroying side only, to prevent destruction synchronization. Removed Connection Services (CSvc) message. Removed connection priority until proven generally useful. Can be implemented as an extension. Added Negotiation and Capability Inquiry sections. Deleted data-end message because AME (Application Message End) already does the same thing and because there is no data-start message. Deleted meta-* messages. Data-* messages are now used for both metadata and data since OCP does not know the difference, but must provide the same exchange mechanism for both. Use a single message name (short or long, depending on the message) instead of using full and abbreviated versions and trying to enforce abbreviations on the wire. Be more consistent in creating short message names. Resurrected OCP scope figure based on popular demand. Applied Martin Stecher comments dated 2003/05/30. Added structure and list values to ABNF syntax. Messages with multiple equally-named parameters are semantically invalid. Added types for message parameters. Started replacing complicated, error-prone, and probably mostly useless "modified" parameter with a clear and simple "as-is" parameter. Converted parameter descriptions from list items to subsections. OCP syntax requires one or two character lookups to determine the next message part. Fixed a comment for implementors saying that one lookup is always sufficient. Mentioned TCP/IP/Internet as assumed transport/network, with any other reliable connection-oriented transport/network usable as well. We do not document how OCP messages are mapped to TCP but it should be obvious. See Overall Operation section. Applied Martin Stecher's corrections to OCP message syntax and definitions of messages. Restricted full message name use to documentation, debuggers, and such. The differences in abbreviated and full name usage still need more consideration and polishing. IAB Considerations section now refers to the future opes-iab draft. Added OCP message syntax. Reformatted message descriptions to match new syntax concepts. Started adding meta-have message to exchange metadata details. Removed negotiation messages for now (posted new messages to the list for a discussion). Added Security Considerations section (based on Abbie Barbir's original text). Changed document labels to reflect future "WG draft" status. Added Acknowledgments section. Added "Core" to the title since we expect application specific drafts to follow and because this document, even when complete, cannot specify a "working" protocol without application-specific parts. This change is still debatable. Added reference to required future application-specific specs in the Introduction. Moved all rant about irrelevance of application protocols proxied by an OPES processor to the "Application proxies and OCP scope" section. Removed "processor input" and "processor output" terms. No reason to define a new term when its only purpose is to document irrelevance? Moved "OCP message" definition to the terminology section. Clarified "application message" definition based on recent WG discussions and suggestions. There seems to be consensus that "application message" is whatever OPES processor and callout server define or agree on, but OCP needs some minimal structure (content + metadata) Synced data and metadata definitions with the new "application message" definition. Simplified "Overall Operation" section since it no longer need to talk about irrelevance of application protocols proxied by an OPES processor. Illustrated nesting/relationship of key OCP concepts (application message, OCP message, transaction, connection, transport connection, etc.). The figure needs more work. Listed all from-processor and from-server OCP messages in one place, with references to message definitions. Added "services" message parameter, assuming that more than one service may be requested/executed with one transaction. Gave callout server ability to report what services were actually applied (see "services" parameter definition). clarified application message definition and OCP boundaries by introducing three kinds of "applications": processor input, processor output, and OCP application made "Overall Operation" a top-level section since it got long and has its own subsections now; lots of editorial changes in this sections, new figures added illustrations of OCP messages, transactions, and connections introduced a notion of meta-data to both simplify OCP and make OCP agnostic to application meta-data; previous approach essentially assumed existence of a few common properties like protocol name or application message source/destination while not allowing any other properties to be exchanged between OCP agents); specific meta-data format/contents is not important to OCP but OCP will help agents to negotiate that format/contents removed wording implying that OCP adapts application messages; OCP only used to exchange data and meta-data (which facilitates adaptation) changed most of the definitions; added definitions for meta-data, original/adapted flows, and others split 'data-pause' message into 'data-pause' request by the callout server and 'data-paused' notification by the OPES processor; fixed "paused" state management added motivation for data acking mechanism replaced "am-proto", "am-kind", "am-source", and "am-destination" parameters with "meta-data" replaced SERVER and CLIENT placeholders with "callout server" and "OPES processor" added editing marks