Open Pluggable Edge Services A. Rousskov Internet-Draft The Measurement Factory Expires: September 29, 2003 March 31, 2003 OPES Callout Protocol (OCP) draft-rousskov-opes-ocp-cur 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 <1> Local revision control ID: $Id: ocp-spec.xml,v 1.10 2003/04/05 06:24:09 rousskov Exp $ <2> 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). Rousskov Expires September 29, 2003 [Page 1] Internet-Draft OPES Callout Protocol (OCP) March 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Overall Operation . . . . . . . . . . . . . . . . . . . . . 4 1.3 Protocol Development Status . . . . . . . . . . . . . . . . 6 2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Transactions . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Connections . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Message Parameter Definitions . . . . . . . . . . . . . . . 10 6. Message Definitions . . . . . . . . . . . . . . . . . . . . 13 6.1 connection-start . . . . . . . . . . . . . . . . . . . . . . 13 6.2 connection-end . . . . . . . . . . . . . . . . . . . . . . . 14 6.3 connection-priority . . . . . . . . . . . . . . . . . . . . 14 6.4 connection-service . . . . . . . . . . . . . . . . . . . . . 14 6.5 xaction-start . . . . . . . . . . . . . . . . . . . . . . . 14 6.6 xaction-end . . . . . . . . . . . . . . . . . . . . . . . . 15 6.7 app-message-start . . . . . . . . . . . . . . . . . . . . . 15 6.8 app-message-end . . . . . . . . . . . . . . . . . . . . . . 15 6.9 data-have . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.10 data-as-is . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.11 data-pause . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.12 data-paused . . . . . . . . . . . . . . . . . . . . . . . . 17 6.13 data-end . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.14 data-need . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.15 data-ack . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.16 i-am-here . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.17 are-you-there . . . . . . . . . . . . . . . . . . . . . . . 19 6.18 do-you-support . . . . . . . . . . . . . . . . . . . . . . . 19 6.19 i-do-support . . . . . . . . . . . . . . . . . . . . . . . . 19 6.20 i-dont-support . . . . . . . . . . . . . . . . . . . . . . . 19 6.21 please-use . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.22 i-will-use . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.23 i-wont-use . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Application Protocol Requirements . . . . . . . . . . . . . 21 8. IAB Concerns . . . . . . . . . . . . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . 23 10. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Normative References . . . . . . . . . . . . . . . . . . . . 27 Informative References . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . 28 A. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 29 Intellectual Property and Copyright Statements . . . . . . . 30 Rousskov Expires September 29, 2003 [Page 2] Internet-Draft OPES Callout Protocol (OCP) March 2003 1. Introduction <3> 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. <4> 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 <5> 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]. <6> 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?) <7> <8> [Abbie: See e-mails for feedback] 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?) Rousskov Expires September 29, 2003 [Page 3] Internet-Draft OPES Callout Protocol (OCP) March 2003 <9> 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 treats application message data as opaque sequences of octets. Application message data may be empty. <10> data: Same as application message data. <11> application message meta-data: Any information related to an application message. Usually, meta-data is information about the application protocol (e.g., protocol name and version) and/or the application message (e.g., remote IP address of an HTTP/1.1 response connection). Application message 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. <12> meta-data: Same as application message meta-data. <13> processor input Communication between the previous hop in the application protocol flow and an OPES processor. <14> processor output Communication between an OPES processor and the next hop in the application protocol flow. <15> original Referring to application data or meta-data flowing from the OPES processor to an OPES callout server. <16> adapted Referring to application data or meta-data flowing from an OPES callout server to the OPES processor. <17> 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. <18> 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 Overall Operation <19> [Abbie: Need to add an extra section here, basically this stage happen after the setup stage, where capability negotiation occur including the decision on the type of the application protocol that is supported for that OCP session(s)] The primary purpose of OCP communications is an exchange of application message data and meta-data between an OPES processor and a callout server. 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. OCP facilitates but Rousskov Expires September 29, 2003 [Page 4] Internet-Draft OPES Callout Protocol (OCP) March 2003 does not participate in adaptation. [Abbie: OCP is a protocol, it is just a transport, I suggest to delete the sentence] OCP [Abbie: transport] transfers (delete) but does not interpret data or meta-data. previous application hop ------------------------ | (processor input) | V +---------+ [Abbie:or partially adapted] +-------+ | OPES | == (original data flow) ==> |callout| |processor| <== (adapted data flow) === |server | +---------+ +-------+ | (processor output) | V -------------------- next application hop data flows for a single OPES processor and callout server --- communications using application protocol === communications using OCP Figure 1 <20> OPES processor establishes OPES connections with callout servers for the purpose of exchanging [Abbie: OCP messages] application messages and meta-data with the callout server(s). Upon receiving an application message (processor input), the OPES processor may pre-process it 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 [Abbie: can also be partially adapted, example translate English to German and then use callout server to do text to audio] data flow). For the purpose of OCP, the result of OPES processor's preprocessing is still an application message [[Abbie: not needed here if we just clarify what OCP messages are from the start]. Naturally, OPES processor and associated callout services must agree on what application messages are acceptable (see section XXX for information on OCP negotiations) [Abbie:Need to specify negotiation here]. <21> The callout server receives data and meta-data sent by the OPES processor ([Abbie: Not really in the genral case]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). [Abbie: Are we ruling out the possibility that the OPEs processor will send HTTP redirect to the client and asks the callout server to adapt the connection, for example an adapted stream for low bandwidth] <22> Finally, the OPES processor receives and interprets callout server Rousskov Expires September 29, 2003 [Page 5] Internet-Draft OPES Callout Protocol (OCP) March 2003 meta-data, optionally post-processes received data, and then forwards it either to the next application hop or to a callout server. <23> Under certain conditions, a callout server may remove itself from the application message processing loop. OPES processor and callout server may exchange OCP messages related to their configuration and state but unrelated to specific application messages. 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 overall operation in detail. <24> OCP is application agnostic and should apply well to different application protocols such as HTTP, SMTP, and RTSP. Naturally, [Abbie: Delete] not every application protocol can be used with OCP. This specification documents known application scope limitations in the "Application Protocol Requirements" Section [XXX]. 1.3 Protocol Development Status <25> 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. <26> 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. Rousskov Expires September 29, 2003 [Page 6] Internet-Draft OPES Callout Protocol (OCP) March 2003 2. Messages <27> 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. <28> 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. [Abbie: How about if we classify messages as control and data related] Rousskov Expires September 29, 2003 [Page 7] Internet-Draft OPES Callout Protocol (OCP) March 2003 3. Transactions <29> 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. <30> 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. [Abbie: We need a flow diagram here with may be a table that shows the interaction, I also suggest the use of a message structure (a figure) that shows the overall general format of a message] Rousskov Expires September 29, 2003 [Page 8] Internet-Draft OPES Callout Protocol (OCP) March 2003 4. Connections <31> 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. <32> (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.) [Abbie: How does this relate to a session? I think we should use a session as opposed to a connection, since a session can have multiple connections???] Rousskov Expires September 29, 2003 [Page 9] Internet-Draft OPES Callout Protocol (OCP) March 2003 5. Message Parameter Definitions <33> <34> [Abbie: do u mean an OPES processor ID] [Abbie: General remark on the whole section: It is still look weak and not easy to read at all, we really need to have a figure or a atble that shows how a message look like and the various parameters, we need better description of why things are needed and how it is used, I could see that the reader that was not involved in OPES list will find this section very confusing] client: An OPES processor description. The description MAY be used by callout server for logging and similar informational purposes. <35> 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). <36> xid: OCP transaction identifier. Uniquely identifies an OCP transaction originated by a given OPES processor. <37> rid: OCP request identifier. Uniquely identifies an OCP request message within an OCP connection. Request identifiers are used to match certain requests and responses. <38> service: OPES service identifier and optional service parameters. <39> am-id: Application message identifier. Uniquely identifies an application message within an OCP transaction. <40> 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. <41> 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. <42> 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. Rousskov Expires September 29, 2003 [Page 10] Internet-Draft OPES Callout Protocol (OCP) March 2003 <43> size-request Requested data size in octets. The value is the size of application data requested by the sender. <44> 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. <45> 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. <46> 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.) <47> 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. <48> 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. <49> result: OCP processing result. May include integer status code and textual information. <50> 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. Rousskov Expires September 29, 2003 [Page 11] Internet-Draft OPES Callout Protocol (OCP) March 2003 <51> 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). Rousskov Expires September 29, 2003 [Page 12] Internet-Draft OPES Callout Protocol (OCP) March 2003 6. Message Definitions <52> [Abbie: General remarks as in section 5] 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). <53> 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. <54> 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. <55> (XXX can we define "ignore"?) (XXX move these rules elsewhere?) <56> (XXX Message parameters in [square brackets] are OPTIONAL. Other parameters are REQUIRED.) 6.1 connection-start <57> <58> 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. <59> 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. <60> 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 Rousskov Expires September 29, 2003 [Page 13] Internet-Draft OPES Callout Protocol (OCP) March 2003 single BEEP [RFC3080] channel may be designated to an OCP connection. 6.2 connection-end <61> <62> 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. <63> A 'connection-end' message implies 'xaction-end' messages for all transactions opened on this connection. 6.3 connection-priority <64> <65> 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. 6.4 connection-service <66> <67> 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. 6.5 xaction-start <68> <69> 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. <70> 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. <71> This message introduces transaction identifier (xid). Rousskov Expires September 29, 2003 [Page 14] Internet-Draft OPES Callout Protocol (OCP) March 2003 6.6 xaction-end <72> <73> 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. <74> This message terminates the life of the transaction identifier (xid). <75> A 'xaction-end' message implies 'app-message-end' messages for all associated application messages (XXX: rephrase this and similar into a MUST?). 6.7 app-message-start <76> <77> 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. <78> 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. <79> This message introduces application message identifier (am-id). 6.8 app-message-end <80> <81> 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. <82> This message terminates the life of the application message identifier (am-id). <83> A 'app-message-end' message implies 'data-end' message for the associated application message. Rousskov Expires September 29, 2003 [Page 15] Internet-Draft OPES Callout Protocol (OCP) March 2003 6.9 data-have <84> <85> 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. <86> When an OPES processor sends a "copied" flag, the OPES processor MUST keep a copy of the corresponding data (the preservation commitment starts). <87> When an "ack" flag is present, the recipient MUST respond with a 'data-ack' message. 6.10 data-as-is <88> <89> 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. <90> If the data-as-is message is invalid, the OPES processor MUST abort am-id message processing (XXX: document how processing should be aborted). 6.11 data-pause <91> <92> 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 Rousskov Expires September 29, 2003 [Page 16] Internet-Draft OPES Callout Protocol (OCP) March 2003 '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?) <93> An OPES processor MUST NOT send this message. A callout server MUST ignore this message if it receives it. 6.12 data-paused <94> <95> 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. <96> A callout server MUST NOT send this message. An OPES processor MUST ignore this message if it receives it. 6.13 data-end <97> <98> 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. <99> A data-end message ends any data preservation commitments associated with the corresponding application message. 6.14 data-need <100> <101> Informs the OPES processor that the callout server needs more application message data. The "offset" parameter indicates the amount of data already received. <102> Rousskov Expires September 29, 2003 [Page 17] Internet-Draft OPES Callout Protocol (OCP) March 2003 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. <103> The OPES processor MUST ignore a data-need message if the OPES processor already sent request data. <104> 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?) 6.15 data-ack <105> <106> Informs the OPES processor that the corresponding data chunk has been received by the callout server. <107> 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. <108> 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?) <109> 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. <110> 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. <111> 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. Rousskov Expires September 29, 2003 [Page 18] Internet-Draft OPES Callout Protocol (OCP) March 2003 6.16 i-am-here <112> <113> 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. <114> An 'i-am-here' message MAY be sent without solicitation. In such case, it MUST NOT have a "rid" parameter. <115> 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. 6.17 are-you-there <116> <117> 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. <118> 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. 6.18 do-you-support <119> 6.19 i-do-support <120> 6.20 i-dont-support <121> 6.21 please-use <122> Rousskov Expires September 29, 2003 [Page 19] Internet-Draft OPES Callout Protocol (OCP) March 2003 6.22 i-will-use <123> 6.23 i-wont-use <124> Rousskov Expires September 29, 2003 [Page 20] Internet-Draft OPES Callout Protocol (OCP) March 2003 7. Application Protocol Requirements <125> 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. <126> <127> Application protocol messages must have byte boundaries. OCP can only handle application messages with the number of bits divisible by 8. <128> XXX Rousskov Expires September 29, 2003 [Page 21] Internet-Draft OPES Callout Protocol (OCP) March 2003 8. IAB Concerns <129> Document how OCP addresses applicable IAB concerns. XXX. Rousskov Expires September 29, 2003 [Page 22] Internet-Draft OPES Callout Protocol (OCP) March 2003 9. Security Considerations <130> Document. XXX. Rousskov Expires September 29, 2003 [Page 23] Internet-Draft OPES Callout Protocol (OCP) March 2003 10. Compliance <131> 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. <132> 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". Rousskov Expires September 29, 2003 [Page 24] Internet-Draft OPES Callout Protocol (OCP) March 2003 11. To-do <133> <134> compliance: Do we really need two levels of compliance (conditional and unconditional)? <135> timeouts: document what messages cause what timers to be [re]set. <136> 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)? <137> 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? <138> 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? <139> copied: When can an OPES processor destroy a copy? <140> 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? <141> 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? Rousskov Expires September 29, 2003 [Page 25] Internet-Draft OPES Callout Protocol (OCP) March 2003 <142> 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) <143> break: allow a callout server to get out of the processing loop without losing the data. <144> fast track: Document messages that may be sent on alternative connections. Require other-connections messages to be duplicated on the primary connection. <145> modp: Min and max values (0 and 100) should be "commitments" rather than "probabilities". <146> transactions-end: Decide whether we need a 'transactions-end' message to terminate multiple transactions efficiently. Is terminating a connection good enough? <147> error: Do we need this flag or should we use result codes to relay the same meaning? <148> 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? <149> proxying Can OCP be proxied above transport layer? Perhaps to implement parts of a given service, transparently to the OPES processor? <150> normative IDs: To be normative, OPES Internet-Drafts must be replaced with corresponding RFCs when the latter are published. Rousskov Expires September 29, 2003 [Page 26] Internet-Draft OPES Callout Protocol (OCP) March 2003 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [I-D.ietf-opes-architecture] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-04 (work in progress), December 2002. Rousskov Expires September 29, 2003 [Page 27] Internet-Draft OPES Callout Protocol (OCP) March 2003 Informative References [I-D.ietf-opes-protocol-reqs] Beck, A., "Requirements for OPES Callout Protocols", draft-ietf-opes-protocol-reqs-03 (work in progress), December 2002. [I-D.ietf-opes-scenarios] Barbir, A., "OPES Use Cases and Deployment Scenarios", draft-ietf-opes-scenarios-01 (work in progress), August 2002. [I-D.ietf-fax-esmtp-conneg] Toyoda, K. and D. Crocker, "SMTP Service Extension for Fax Content Negotiation", draft-ietf-fax-esmtp-conneg-06 (work in progress), February 2003. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. Author's Address Alex Rousskov The Measurement Factory 1200 Pearl Street, Suite 70 Boulder, CO US EMail: rousskov(_at_)measurement-factory(_dot_)com URI: http://www.measurement-factory.com/ Rousskov Expires September 29, 2003 [Page 28] Internet-Draft OPES Callout Protocol (OCP) March 2003 Appendix A. Change Log <155> <156> o 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 <157> o removed wording implying that OCP adapts application messages; OCP only used to exchange data and meta-data (which facilitates adaptation) <158> o changed most of the definitions; added definitions for meta-data, original/adapted flows, and others <159> o split 'data-pause' message into 'data-pause' request by the callout server and 'data-paused' notification by the OPES processor; fixed "paused" state management <160> o added motivation for data acking mechanism <161> o replaced "am-proto", "am-kind", "am-source", and "am-destination" parameters with "meta-data" <162> o replaced SERVER and CLIENT placeholders with "callout server" and "OPES processor" <163> o added editing marks Rousskov Expires September 29, 2003 [Page 29] Internet-Draft OPES Callout Protocol (OCP) March 2003 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 Rousskov Expires September 29, 2003 [Page 30] Internet-Draft OPES Callout Protocol (OCP) March 2003 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. Rousskov Expires September 29, 2003 [Page 31]