Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 29, 2003.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

¹Local revision control ID: $Id: ocp-spec.xml,v 1.11 2003/04/07 23:00:25 rousskov Exp $

²This document specifies Open Pluggable Edge Services (OPES) callout protocol (OCP). OCP supports the remote execution of OPES services. This OCP specification is incomplete and cannot be used for implementing the protocol yet. Major missing pieces are transport binding(s) and message encoding(s).

Table of Contents

1.  Introduction
1.1  Terminology
1.2  Protocol Development Status
2.  Overall Operation
2.1  OCP environment
2.2  Application messages
2.3  Processing steps
3.  Messages
4.  Transactions
5.  Connections
6.  Message Parameter Definitions
7.  Message Definitions
7.1  connection-start
7.2  connection-end
7.3  connection-priority
7.4  connection-service
7.5  xaction-start
7.6  xaction-end
7.7  app-message-start
7.8  app-message-end
7.9  data-have
7.10  data-as-is
7.11  data-pause
7.12  data-paused
7.13  data-end
7.14  data-need
7.15  data-ack
7.16  i-am-here
7.17  are-you-there
7.18  do-you-support
7.19  i-do-support
7.20  i-dont-support
7.21  please-use
7.22  i-will-use
7.23  i-wont-use
8.  Application Protocol Requirements
9.  IAB Concerns
10.  Security Considerations
11.  Compliance
12.  To-do
§  Normative References
§  Informative References
§  Author's Address
A.  Change Log
§  Intellectual Property and Copyright Statements

1. Introduction

³The Open Pluggable Edge Services (OPES) architecture [I-D.ietf-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 execution of such services is governed by a set of rules installed on the OPES processor. The rules enforcement can trigger the execution of service applications local to the OPES processor. Alternatively, the OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [I-D.ietf-opes-protocol-reqs], an OPES processor communicates with and invokes services on a callout server by using a callout protocol. This document specifies such a protocol.

1.1 Terminology

⁵The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

⁶OCP works on messages from application protocols. Protocol elements like "message", "connection", or "transaction" exist in OCP and application protocols. In this specification, all references to elements from application protocols are used with an explicit "application" qualifier. References without the "application" qualifier, refer to OCP elements. (XXX: Some OCP elements are called "callout" elements in the OCP requirements document. We assume that OCP is equivalent to "callout" in this context. For example, OCP connection is the same as callout connection. Should we be more consistent?)

⁷OPES processor may simultaneously work with several application protocol instances (input, output, and OCP), making the term "application" or "application protocol" imprecise in the OPES context. OCP deals with only one application instance at a time. We define that instance below as "OCP application". In this specification, all unqualified references to "application" are references to "OCP application".

⁸

input application

⁹An application interface or application protocol used by OPES processor to communicate with the previous application hop.

output application

¹⁰An application interface or application protocol used by OPES processor to communicate with the next application hop. Usually, output application is the same as input application.

OCP application

¹¹An application interface or application protocol that OPES processor and the callout server agree to use for the purpose of exchanging application messages and information about them. May be used without an "OCP" qualifier.

application message:

¹²A sequence of octets that OPES processor designates for callout service processing or a sequence of octets that callout server sends back to the OPES processor. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). (XXX: This definition is bad because OCP messages themselves are also sequence of octets that OCP agents send to each other. How to distinguish "OCP" from "application" if we do not have an application data definition? What we want to say is that application message is whatever an OCP agent has marked as such. How to say that?)

application message data:

¹³A subsequence of application message octets. Application message data may correspond to an application message fragment or may cover an entire application message. OCP makes no distinction between application message headers, payload, trailers, etc.; no particular application message structure is assumed. OCP treats application message data as opaque sequences of octets. Application message data may be empty.

data:

¹⁴Same as application message data.

meta-data:

¹⁵Any information. Often, meta-data is information about the input/output application protocol (e.g., protocol name and version), and/or the input/output application message (e.g., remote IP address of an HTTP/1.1 response connection). Meta-data may or may not be duplicated in the application message data. OCP treats application message meta-data as opaque sequences of octets. Application message meta-data may be empty.

original

¹⁶Referring to application data or meta-data flowing from the OPES processor to an OPES callout server.

adapted

¹⁷Referring to application data or meta-data flowing from an OPES callout server to the OPES processor.

adaptation:

¹⁸Any kind of access by a callout server, including modification and copying. For example, translating or logging an SMTP message is adaptation of that application message.

agent:

¹⁹Client or server for a given communication protocol. A proxy is both a client and a server and, hence, also an agent. For example, OPES processor and callout server are OCP agents.

1.2 Protocol Development Status

²⁰Several important OCP details are still unknown. OCP transport protocol(s) have not been selected. Encoding of OCP messages is not yet documented. This specification is not yet suitable for writing OCP implementations.

²¹The plan is to add necessary details and bindings to the future versions of this document until the specification is complete. The To-do Section [XXX] contains a list of to-be-implemented items.

2. Overall Operation

2.1 OCP environment

²²OPES processor is an application proxy that receives input application messages, adapts them, and outputs adapted messages to the next hop. OPES processor may offload some or all adaptation tasks to callout servers. Adaptation using callout services is sometimes called a "bump in the wire" architecture. OPES processor may use OPES callout protocol (OCP) to communicate with callout servers. When OCP is used, an OPES processor and a callout server negotiate and agree on an OCP application protocol to use in order to exchange application message data and meta-data. Such exchange allows the original data and meta-data to be adapted at the callout server, with the result of that adaptation sent back to the OPES processor.

²³The following diagram illustrates a typical OCP environment. Communications using input/output application protocols are outside of OCP scope. Any adaptation performed at OPES processor before or after OCP application is also out of OCP scope. Out of scope communications and stages are shown below for illustrative purposes only.

²⁴The next illustration zooms onto the OPES processor and callout server, revealing OCP communication details.

2.2 Application messages

²⁵OPES processor has to deal with three kinds of application messages: processor input, OCP application messages, and processor output. OCP is concerned with OCP application messages only. OCP places no restrictions on processor input or output and has no requirements concerning the relationship between OCP application messages and processor input or output. Such restrictions and requirements may exist for OPES processors, but are outside of OCP scope.

²⁶OCP application messages are augmented with meta-data, some required by OCP, and some encoded by private convention between the two OCP agents (XXX: no meta-data is currently required). When converting processor input to original OCP application messages, OPES processor is not required to use message framing boundaries dictated by the input application protocol. However, these boundaries can be relayed via meta-data. OCP has no requirements about re-framing, re-ordering, or reconstructing the output application messages from adapted OCP messages.

²⁷An OPES processor is at liberty to choose which input application messages or information about them to send over OCP. All input messages on all input connections, or everything on some connections, or selected parts, or nothing might be converted to OCP application messages and meta-data and sent over OCP to callout servers. Similarly, OPES output state information can be relayed over OCP to callout servers as meta-data.

²⁸OCP communications are primarily about exchanging application message data (including the application message headers, payloads, trailers, etc.). However, it is possible for OCP to carry only meta-data about an application message.

2.3 Processing steps

²⁹OPES processor establishes callout connections with callout servers for the purpose of exchanging application messages and meta-data with the callout server(s) using OCP. As a part of the callout connection establishment, information about OCP agents may be exchanged and connection properties may be negotiated (see XXX). When negotiation is complete, OCP agents may start exchanging application messages.

³⁰Upon receiving an application message (processor input), OPES processor initiates an OCP transaction dedicated to that application message. The OPES processor may pre-process its input to extract and manipulate well-known parts (e.g., HTTP message headers or SMTP message body) in order to subject just those parts to callout services. The OPES processor then builds meta-data and forwards meta-data and complete or partial application message data to the callout server (original data flow).

³¹For the purpose of OCP, the result of OPES processor's preprocessing is still an original application message. OPES processor and associated callout services must agree on what application messages are acceptable (see XXX for information on OCP negotiations).

³²The callout server receives data and meta-data sent by the OPES processor (original data flow). The callout server analyses meta-data and adapts data as it comes in. The server usually builds its version of meta-data and sends adapted data back to the OPES processor as soon as possible (adapted data flow).

³³Finally, the OPES processor receives and interprets callout server meta-data, optionally post-processes received data, and then forwards it either to the next application hop or to a callout server.

³⁴OCP agents may exchange messages related to their configuration, state, OCP connections, and application connections. 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. 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[I-D.ietf-opes-architecture] describes the configuration possibilities.

³⁵OCP is application agnostic but it is not suitable for all applications. This specification documents known application scope limitations in the "Application Protocol Requirements" Section [XXX]. The OPES meta-data can carry application specific information.

3. Messages

³⁶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 defined in Section XXX. Message semantics is defined in Section XXX. Messages are transmitted over OCP connections.

³⁷OCP messages deal with connection 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.

³⁸While message encoding is not yet known, all OCP messages have a unique name and a possibly empty set of parameters. A parameter may be required or optional, depending on the parameter name, message name, and context. Message parameters are documented in Section XXX. Message definitions are given in Section XXX.

³⁹The figure below contains a sample of unrelated OCP messages.

4. Transactions

⁴⁰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.

⁴¹A OCP transaction starts with a explicit 'xaction-start' message sent by the OPES processor. A transaction ends with the first 'xaction-end' message, explicit or implied, which 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.

5. Connections

⁴²OCP connection is a logical abstraction representing a stream of possibly interleaved OCP transactions and transaction-independent messages. Connections allow for efficient handling of state common to several OCP transactions, including processing prioritization. The figure below illustrates possible message sequence.

⁴³There is no relationship between OCP connections and application connections. Application connections are out of OCP scope. Their existence is not assumed by the callout protocol. Information about application connection may be a part of the meta-data.

⁴⁴(XXX: OCP transport binding(s) will determine how callout connections are mapped to transport connections. For example, if raw TCP is the transport, than a TCP connection will correspond to a callout connection. If BEEP over TCP is used, than a BEEP channel will correspond to a callout connection, allowing callout connection multiplexing over a single TCP connection.)

6. Message Parameter Definitions

⁴⁵

client:

⁴⁶An OPES processor description. The description MAY be used by the callout server for logging and similar informational purposes. (XXX: this parameter may be just a processor ID; we need to decide whether more details are needed)

server:

⁴⁷A callout server description. The description MAY be used by the OPES processor for tracing and similar informational purposes. (XXX: this parameter may be just a callout server ID; we need to decide whether more details are needed)

priority:

⁴⁸OCP connection priority, as a signed integer value. Default priority is zero. Higher values correspond to more "important" connections that MAY be checked and processed more often. Support for connection priorities is OPTIONAL. However, callout server implementations SHOULD NOT knowingly violate priority settings, including the default value of zero (where violation is defined as treating lower priority connection as more important than a higher priority connection).

xid:

⁴⁹OCP transaction identifier. Uniquely identifies an OCP transaction originated by a given OPES processor.

rid:

⁵⁰OCP request identifier. Uniquely identifies an OCP request message within an OCP connection. Request identifiers are used to match certain requests and responses.

service:

⁵¹OPES service identifier and optional service parameters.

am-id:

⁵²Application message identifier. Uniquely identifies an application message within an OCP transaction.

data:

⁵³Application message data. OCP agents may interpret data, but OCP itself treats data as an opaque sequence of bytes. Usually, data contains fragments of application message headers and/or payload.

meta-data:

⁵⁴Application message meta-data. OCP agents may interpret meta-data, but OCP itself treats meta-data as an opaque sequence of bytes. Usually, meta-data will contain information about application protocol (name, version), application message kind (request or response), as well as message source and/or destination addresses.

size:

⁵⁵Attached data size in octets. The value is the size of the "data" parameter value. The "data" parameter MUST be present when "size" parameter is used and vice-versa. The value of "size" would be equal to the transfer-length of the entire application message only if the entire application message is transmitted in one "data" parameter.

size-request

⁵⁶Requested data size in octets. The value is the size of application data requested by the sender.

offset:

⁵⁷Application data offset. The offset of the first application byte has a value of zero. The offset is never negative. The value applies to the data attached to an OCP message.

modified:

⁵⁸A boolean parameter. When used together with the "data" parameter, the value indicates that the attached data fragment has been modified by the callout server, compared to its original value received from the OPES processor; says nothing about other fragments. When used with the 'app-message-start' message, indicates that the corresponding application message has been modified or will be modified (i.e., one or more of the corresponding messages with "data" parameter will probably have a "modified" parameter set). Only the callout server may send this flag. This parameter can be used with any OCP message that has an "am-id" parameter.

copied:

⁵⁹A flag indicating that a copy of the attached application data is being kept at the OPES processor. Only the OPES processor may send this flag. This parameter can be used with any OCP message that may carry application message data. (XXX: it is yet unclear when OPES processor commitment to preserve the data may end.)

sizep:

⁶⁰Remaining application data size prediction in octets. The value excludes data in the current OCP message, if any. The prediction applies to a single application message. This parameter can be used with any OCP message that has am-id parameter.

modp:

⁶¹Future data modification prediction in percents. A modp value of 0 (zero) means the sender predicts that there will be no data modifications. A value of 100 means the sender is predicts that there will be data modifications. The value excludes data in the current OCP message, if any. The prediction applies to a single application message. This parameter can be used with any OCP message that has am-id parameter.

result:

⁶²OCP processing result. May include integer status code and textual information.

error:

⁶³A flag indicating abnormal conditions at the sender that cannot be expressed via result parameter. It is RECOMMENDED that the recipient deletes all state associated with the corresponding OCP message.

feature:

⁶⁴A OCP feature identifier with optional feature parameters. Used to declare support and negotiate use of OCP optional features (e.g., copying of data chunks at the OPES processor).

7. Message Definitions

⁶⁵Senders MUST use message format specified in this section. (XXX note that at this time, the only "format" specified is the set of message parameters, but this will change as we add transport bindings and encodings).

⁶⁶Recipients MUST be able to parse messages in the specified format. If a malformed message is received, the recipient MUST terminate processing of the corresponding OCP connection using 'connection-end' message with an error flag. If an unknown message or message parameter is received, the recipient MUST ignore it, but MAY report (e.g., log) it.

⁶⁷Except for messages that introduce new identifiers, all sent identifiers MUST be known (i.e., introduced and not ended by previous messages). Except for messages that introduce new identifiers, the recipient MUST ignore any message with an unknown identifier. For example, recipient must ignore a data-have message if the xid parameter refers to an unknown transaction. Message definitions below clearly state rare exceptions to the above rules.

⁶⁸(XXX can we define "ignore"?) (XXX move these rules elsewhere?)

⁶⁹(XXX Message parameters in [square brackets] are OPTIONAL. Other parameters are REQUIRED.)

7.1 connection-start

⁷⁰<connection-start [client] [priority]>

⁷¹Indicates the start of an OCP connection from the OPES processor. A callout server MUST NOT send this message. Upon receiving of this message, the callout server MUST either start maintaining connection state or refuse further processing by responding with a 'connection-end' message. A callout server MUST maintain the state until it receives a message indicating the end of the connection or until it terminates the connection itself.

⁷²The 'connection-start' message MUST be the first message on an OCP connection. If OCP transport connection delivers a message outside of the ('connection-start', 'connection-end') boundaries, such a message MUST be ignored, and the recipient MUST close the corresponding transport connection.

⁷³There are no OCP connection identifiers because connections are not multiplexed on a logical level. OCP transport protocol binding MUST distinguish OCP connections on a transport level. For example, a single BEEP[RFC3080] channel may be designated to an OCP connection.

7.2 connection-end

⁷⁴<connection-end>

⁷⁵Indicates an end of an OCP connection. The recipient MUST free associated state. The destruction of the state ensures that messages outside of OCP connection are ignored.

⁷⁶A 'connection-end' message implies 'xaction-end' messages for all transactions opened on this connection.

7.3 connection-priority

⁷⁷<connection-priority priority>

⁷⁸Sets connection priority, overwriting the previous value. A callout server MUST NOT send this message. This message MUST be ignored if received by an OPES processor.

7.4 connection-service

⁷⁹<connection-service service>

⁸⁰Sets default service for the connection, overwriting the previous value. A callout server MUST NOT send this message. This message MUST be ignored if received by an OPES processor.

7.5 xaction-start

⁸¹<xaction-start xid [service]>

⁸²Indicates the start of an OCP transaction. A callout server MUST NOT send this message. Upon receiving of this message, the callout server MUST either start maintaining transaction state or refuse further processing by responding with a 'xaction-end' 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 OPTIONAL "service" parameter applies to the original application message processed within this OCP transaction boundaries. If "service" is not specified, the "service" parameter from the connection state MUST be used. If the latter is not specified either, the transaction is invalid and MUST be aborted by the recipient.

⁸⁴This message introduces transaction identifier (xid).

7.6 xaction-end

⁸⁵<xaction-end xid [error] result>

⁸⁶Indicates the end of the OCP transaction. The recipient MUST free associated state. The destruction of the state ensures that future messages referring to the same transaction, if any, will be ignored.

⁸⁷This message terminates the life of the transaction identifier (xid).

⁸⁸A 'xaction-end' message implies 'app-message-end' messages for all associated application messages (XXX: rephrase this and similar into a MUST?).

7.7 app-message-start

⁸⁹<app-message-start xid am-id meta-data ...>

⁹⁰Indicates the start of processing of an application message. The recipient MUST either start processing the application message (and maintain its state) or refuse further processing with an 'app-message-end' message. The recipient MUST maintain the state until it receives a message indicating the end of application message processing or until it terminates the processing itself.

⁹¹When 'app-message-start' message is sent to the callout server, the callout server usually sends an app-message-start message back, announcing the creation of an adapted version of the original application message. Such response may be delayed. For example, the callout server may wait for more information to come from the OPES processor.

⁹²This message introduces application message identifier (am-id).

7.8 app-message-end

⁹³<app-message-end xid am-id [error] result ...>

⁹⁴Indicates the end of application message processing. The recipient MUST free associated state. The destruction of the state ensures that future messages referring to the same application message, if any, will be ignored.

⁹⁵This message terminates the life of the application message identifier (am-id).

⁹⁶A 'app-message-end' message implies 'data-end' message for the associated application message.

7.9 data-have

⁹⁷<data-have xid am-id offset size data modified [copied] [sizep] [modp] [ack]>

⁹⁸This is the only OCP message that may carry application data. There MUST NOT be any gaps in data supplied by data-have and data-as-is messages (i.e., the offset of the next data message must be equal to the offset+size of the previous data message) (XXX: we do not need offset then; should we keep it as a validation mechanism?) (XXX: document what to do when this MUST is violated). Zero size is permitted and is useful for communicating predictions without sending data.

⁹⁹When an OPES processor sends a "copied" flag, the OPES processor MUST keep a copy of the corresponding data (the preservation commitment starts).

¹⁰⁰When an "ack" flag is present, the recipient MUST respond with a 'data-ack' message.

7.10 data-as-is

¹⁰¹<data-as-is xid am-id offset size copy-am-id copy-am-offset>

¹⁰²Tells the OPES processor to use "size" bytes of data at copy-am-offset of the copy-am-id application message, as if that data came from the callout server in a 'data-have am-id offset size> message. The data chunk MUST be under the preservation commitment. If the OPES processor receives a 'data-as-is> message for data not under preservation commitment, the message is invalid. Both "am-id" and "copy-am-id" application message identifiers MUST belong to the same OCP transaction. If they do not, the message is invalid.

¹⁰³If the data-as-is message is invalid, the OPES processor MUST abort am-id message processing (XXX: document how processing should be aborted).

7.11 data-pause

¹⁰⁴<data-pause xid am-id>

¹⁰⁵Sent by a callout server, the data-pause message informs the OPES processor that it must stop sending data to the callout server until the callout server explicitly asks for more data using a 'data-need' message. Upon receiving a 'data-pause' message, the OPES processor SHOULD stop sending application message data to the callout server. If the OPES processor stops sending, it SHOULD send a corresponding 'data-paused' message to the callout server. Until the OPES processor receives the message, it may continue sending data to the callout server, of course. Thus, when the callout server sends this message, it MUST NOT mark the application message as "paused". (XXX: should we use MUST or MAY instead of SHOULDs above?)

¹⁰⁶An OPES processor MUST NOT send this message. A callout server MUST ignore this message if it receives it.

7.12 data-paused

¹⁰⁷<data-paused xid am-id>

¹⁰⁸Sent by an OPES processor, the 'data-paused' message informs the callout server that there will be no more data for the specified application message until the callout server explicitly asks for data using a 'data-need' message. After sending a 'data-paused' message, the OPES processor MUST stop sending application message data to the callout server. At that time, there may be still unprocessed data in the callout server queue, of course. When the callout server receives the message, it MAY mark the application message as "paused". If the callout server receives data for a paused message (a violation of the above MUST), the callout server MAY abort application message processing.

¹⁰⁹A callout server MUST NOT send this message. An OPES processor MUST ignore this message if it receives it.

7.13 data-end

¹¹⁰<data-end xid am-id [error] result>

¹¹¹Informs the recipient that there will be no more data for the corresponding application message. If the recipient receives more data after the data-end message, it MUST abort application message processing.

¹¹²A data-end message ends any data preservation commitments associated with the corresponding application message.

7.14 data-need

¹¹³<data-need xid am-id offset [size-request]>

¹¹⁴Informs the OPES processor that the callout server needs more application message data. The "offset" parameter indicates the amount of data already received.

¹¹⁵If a "size" parameter is present, its value is the suggested data size, and it MAY be ignored by the OPES processor. An absent "size" parameter implies "any size". The callout server MUST clear the "paused" state of the application message processing just before sending this message.

¹¹⁶The OPES processor MUST ignore a data-need message if the OPES processor already sent request data.

¹¹⁷An OPES processor MUST NOT send data-need messages (XXX: should we give an OPES processor the same abilities to pause/resume message processing that a callout server has?)

7.15 data-ack

¹¹⁸<data-ack xid am-id offset size [wont-forward]>

¹¹⁹Informs the OPES processor that the corresponding data chunk has been received by the callout server.

¹²⁰An optional "wont-forward" flag terminates preservation commitment for the corresponding data, if any. The flag is defined for callout server 'data-ack' messages only.

¹²¹Responding with 'data-ack' messages to 'data-have' messages with a "please-ack" flag is REQUIRED. Responding with 'data-ack' messages to 'data-have' messages without an "ack" flag is OPTIONAL. Implementations SHOULD be able to support debugging mode where every 'data-have' message is acked. (XXX: should we require responses for 'data-as-is> messages as well?)

¹²²A 'data-ack' response SHOULD be sent as soon as possible. If the callout server does not know immediately whether it will forward the data, it MUST respond without a "wont-forward" flag. If, at any time, the callout server decides that it will not forward the data, it SHOULD send a 'data-ack' message with a "wont-forward" flag. Thus, multiple 'data-ack' messages and unsolicited 'data-ack' messages are allowed.

¹²³Sending of a 'data-ack' message means that a complete 'data-have' message has been received, but does not imply that the data has been processed in any other way.

¹²⁴The 'data-ack' mechanism has several purposes: to allow OPES processor to gauge the speed at which the callout server is receiving data (for optimization purposes); to send back "wont-forward" notifications; and to assist in debugging OCP communications.

7.16 i-am-here

¹²⁵<i-am-here [rid] [xid [am-id]]>

¹²⁶Parameterless form informs the recipient that the sender is still maintaining the OCP connection. If "xid" or "am-id" identifier(s) are used, the message informs the recipient that the sender is still processing the corresponding transaction or an application message.

¹²⁷An 'i-am-here' message MAY be sent without solicitation. In such case, it MUST NOT have a "rid" parameter.

¹²⁸An 'i-am-here' message MUST be sent in response to an 'are-you-there' request. The "rid" value in the response MUST be set to "rid" value of the request. The response MUST have the same set of "xid" and "am-id" parameters if those identifiers are still valid. The response MUST NOT use invalid identifiers.

7.17 are-you-there

¹²⁹<are-you-there rid [xid [am-id]]>

¹³⁰Solicits an immediate 'i-am-here' response. If the response does not use the same set of "xid" and "am-id" parameters, the recipient MAY assume that missing identifier(s) correspond to OCP transaction or application message that was not maintained at the time the response was generated.

¹³¹The recipient MUST handle an 'are-you-there' request even if transaction or application message identifiers are invalid from the recipient point of view. Normally, messages with invalid identifiers are ignored.

7.18 do-you-support

¹³²<do-you-support feature>

7.19 i-do-support

¹³³<i-do-support feature>

7.20 i-dont-support

¹³⁴<i-dont-support feature>

7.21 please-use

¹³⁵<please-use feature>

7.22 i-will-use

¹³⁶<i-will-use feature>

7.23 i-wont-use

¹³⁷<i-wont-use feature>

8. Application Protocol Requirements

¹³⁸Not all application protocols can be adapted with OCP. Compiling a complete list of known limitations is impossible since "application protocol" is not a well defined term. However, listing known limitations can help it determining OCP applicability. This section is not a normative part of the OCP specification.

¹³⁹

¹⁴⁰Application protocol messages must have byte boundaries. OCP can only handle application messages with the number of bits divisible by 8.

¹⁴¹XXX

9. IAB Concerns

¹⁴²Document how OCP addresses applicable IAB concerns. XXX.

10. Security Considerations

¹⁴³Document. XXX.

11. Compliance

¹⁴⁴Only normative parts of this specification affect implementation compliance. Normative parts are either explicitly marked as such using the word "normative" or are phrases containing capitalized keywords from [RFC2119]. Definitions of terms used by normative parts are, of course, normative as well.

¹⁴⁵An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant".

12. To-do

¹⁴⁶

compliance:

¹⁴⁷Do we really need two levels of compliance (conditional and unconditional)?

timeouts:

¹⁴⁸document what messages cause what timers to be [re]set.

modified:

¹⁴⁹should this parameter be required? Is it possible that the callout server does not know whether the data got modified (consider service outsourcing scenario or some complex permutation of a large image that may or may not result in a different image while it would be prohibitively expensive to keep a copy of the original data and to compare adapted data with the original). When the server does not know, should it say "yes" to be safe (if the parameter is required), or should it confess with "I do not know" (by omitting the parameter or using 3-way logic)?

meta-data format:

¹⁵⁰How/when do OPES processor and callout server agree on meta-data format and contents? Note that meta-data should usually describe actual data encoding. Data-encoding may, however, be also negotiated. How? When?

meta-trailer:

¹⁵¹We assume that meta-data is known in advance and cannot be updated after some data has been sent. That is, we assume that meta-data is known when the application message starts. That is not true in general because some protocols (including HTTP) have support for trailers (meta-information after the payload). Should we add support for passing meta-data with 'app-message-end' or a similar "end" message?

copied:

¹⁵²When can an OPES processor destroy a copy?

asis:

¹⁵³Can a callout server refer to parts of [copied] data messages from the OPES processor? If yes, do we need to worry about fragmentation if yes? If no, will this restriction kill the optimization for mid-size application messages (the common case?) that are likely to be passed to the callout server in just one or two chunks?

partial:

¹⁵⁴Should we support partial application message exchange (exchange only a part of the application message)? Who decides what parts to exchange? Should the callout server be able to ask which part it wants? How will it describe the part if it has not seen the entire message?

loss:

¹⁵⁵Should OPES processor be able to signal loss of data to the callout server. The current wording assumes that offset is incremented using sizes of actually received data fragments; if the processor detects loss it cannot pass that information and can only hope that the callout server will notice (by interpreting the data) or will not care (the server may be application- and/or loss-agnostic; e.g., a logging or billing server)

break:

¹⁵⁶allow a callout server to get out of the processing loop without losing the data.

fast track:

¹⁵⁷Document messages that may be sent on alternative connections. Require other-connections messages to be duplicated on the primary connection.

modp:

¹⁵⁸Min and max values (0 and 100) should be "commitments" rather than "probabilities".

transactions-end:

¹⁵⁹Decide whether we need a 'transactions-end' message to terminate multiple transactions efficiently. Is terminating a connection good enough?

error:

¹⁶⁰Do we need this flag or should we use result codes to relay the same meaning?

abort negotiation:

¹⁶¹Should we let the other side affect the abort decision on OPES level? Perhaps the callout server is doing some logging or accounting and MUST see every byte received by the OPES processor, even if the application message is aborted by the processor. Should we add some kind of 'xaction-need-all' message? Or should we assume that the dispatcher always knows callout server needs and vice versa?

proxying

¹⁶²Can OCP be proxied above transport layer? Perhaps to implement parts of a given service, transparently to the OPES processor?

normative IDs:

¹⁶³To be normative, OPES Internet-Drafts must be replaced with corresponding RFCs when the latter are published.

Normative References

Informative References

Author's Address

Appendix A. Change Log

¹⁶⁸

• ¹⁶⁹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

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.

Full Copyright Statement

Copyright (C) The Internet Society (2003). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.