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-00 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 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 . . . . . . . . . . . . . . . . 4 2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Transactions . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Connections . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Parameter Definitions . . . . . . . . . . . . . . . 9 6. Message Definitions . . . . . . . . . . . . . . . . . . . . 11 6.1 connection-start . . . . . . . . . . . . . . . . . . . . . . 11 6.2 connection-end . . . . . . . . . . . . . . . . . . . . . . . 12 6.3 connection-priority . . . . . . . . . . . . . . . . . . . . 12 6.4 connection-service . . . . . . . . . . . . . . . . . . . . . 12 6.5 xaction-start . . . . . . . . . . . . . . . . . . . . . . . 12 6.6 xaction-end . . . . . . . . . . . . . . . . . . . . . . . . 12 6.7 app-message-start . . . . . . . . . . . . . . . . . . . . . 13 6.8 app-message-end . . . . . . . . . . . . . . . . . . . . . . 13 6.9 data-have . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.10 data-as-is . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.11 data-pause . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.12 data-end . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.13 data-need . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.14 data-ack . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.15 i-am-here . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.16 are-you-there . . . . . . . . . . . . . . . . . . . . . . . 16 6.17 do-you-support . . . . . . . . . . . . . . . . . . . . . . . 17 6.18 i-do-support . . . . . . . . . . . . . . . . . . . . . . . . 17 6.19 i-dont-support . . . . . . . . . . . . . . . . . . . . . . . 17 6.20 please-use . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.21 i-will-use . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.22 i-wont-use . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Application Protocol Requirements . . . . . . . . . . . . . 18 8. IAB Concerns . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . 20 10. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Normative References . . . . . . . . . . . . . . . . . . . . 24 Informative References . . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . 26 Rousskov Expires September 29, 2003 [Page 2] Internet-Draft OPES Callout Protocol (OCP) March 2003 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" quantifier. References without the "application" quantifier, 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?) application message: A sequence of octets that OPES processor designates for callout service processing. Usually, an application message is the basic unit of application protocol communication, as defined by that application protocol (e.g., HTTP/1.1 message). Before OCP is applied, OPES processor may pre-process raw application messages 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. For the purpose of OCP, the result of such preprocessing is an application message. Naturally, OPES processor and callout services it is configured to use must agree on what application messages are acceptable. Establishing such an agreement is beyond OCP scope. Rousskov Expires September 29, 2003 [Page 3] Internet-Draft OPES Callout Protocol (OCP) March 2003 application data: Opaque application message octets. data: Same as application data. CLIENT: OPES processor (XXX: or OPES dispatcher?). SERVER: OPES callout server. (XXX: we should replace CLIENT and SERVER placeholders in the text with their definitions once the CLIENT definition becomes stable) 1.2 Overall Operation OPES processor establishes OPES connections with callout servers for the purpose of forwarding application messages and meta-information to the callout server(s). A callout server may send this data back to the OPES processor, with or without modifications. 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. The OPES architecture document [I-D.ietf-opes-architecture] describes overall operation in detail. The primary purpose of OCP communications is modification of application message payloads. Modification of application message headers is also possible and often required to keep the headers in sync with modified application payload. Furthermore, OCP can be used to change the application information beyond what may not be explicitly encoded in an application message such as source or destination addresses. OCP is application agnostic and should apply well to different application protocols such as HTTP, SMTP, and RTSP. Naturally, 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 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 Rousskov Expires September 29, 2003 [Page 4] Internet-Draft OPES Callout Protocol (OCP) March 2003 To-do Section [XXX] contains a list of to-be-implemented items. Rousskov Expires September 29, 2003 [Page 5] Internet-Draft OPES Callout Protocol (OCP) March 2003 2. Messages OCP message is a basic unit of communication between a CLIENT and a 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 CLIENT and a single SERVER. Some messages can only be emitted by a CLIENT; some only by a SERVER; some can be emitted by both CLIENT and 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. Rousskov Expires September 29, 2003 [Page 6] Internet-Draft OPES Callout Protocol (OCP) March 2003 3. 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 CLIENT to the SERVER (sending original application message) and a flow from the SERVER to the CLIENT (sending adapted application messages). The number of application messages produced by the SERVER and whether the SERVER actually modifies original application message depends on the requested callout service. The CLIENT or the SERVER can terminate the transaction by sending a corresponding message to the other side. Rousskov Expires September 29, 2003 [Page 7] Internet-Draft OPES Callout Protocol (OCP) March 2003 4. 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. (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.) Rousskov Expires September 29, 2003 [Page 8] Internet-Draft OPES Callout Protocol (OCP) March 2003 5. Message Parameter Definitions client: A CLIENT description. The description MAY be used by SERVER for logging and similar informational purposes. 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, 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 CLIENT. Since each transaction deals with a single application message, "xid" also identifies that application message. 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. am-proto: Application message protocol. For example, HTTP or SMTP. am-kind: Application message kind. For example, request or response. am-source: Information about the source of an application message. For example, HTTP client or origin server IP address and TCP connection ID. am-destination: Information about the destination of an application message. For example, HTTP client or origin server address. am-destinations: A collection of am-destination parameters. size: Application data size in octets. The value either applies to the data attached to an OCP message or suggests data size to be sent in response to an OCP message. 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. Rousskov Expires September 29, 2003 [Page 9] Internet-Draft OPES Callout Protocol (OCP) March 2003 modified: A boolean parameter indicating that the attached application data has been modified by he SERVER. Only SERVER may send this flag. This parameter can be used with any OCP message that has am-id parameter. copied: A flag indicating that a copy of the attached application data is being kept at the CLIENT. Only the CLIENT 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 CLIENT 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. For example, if the message is 'app-message-end' and the application message contained user credentials, such credentials should be deleted. 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 CLIENT). Rousskov Expires September 29, 2003 [Page 10] Internet-Draft OPES Callout Protocol (OCP) March 2003 6. 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.) 6.1 connection-start connection-start [client] [priority] Indicates the start of an OCP connection from the CLIENT. A SERVER MUST NOT send this message. Upon receiving of this message, the SERVER MUST either start maintaining connection state or refuse further processing by responding with a 'connection-end' message. A 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 Rousskov Expires September 29, 2003 [Page 11] Internet-Draft OPES Callout Protocol (OCP) March 2003 single BEEP [RFC3080] channel may be designated to an OCP connection. 6.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. 6.3 connection-priority connection-priority priority Sets connection priority, overwriting the previous value. 6.4 connection-service connection-service service Sets default service for the connection, overwriting the previous value. 6.5 xaction-start xaction-start xid [service] Indicates the start of an OCP transaction. A SERVER MUST NOT send this message. Upon receiving of this message, the SERVER MUST either start maintaining transaction state or refuse further processing by responding with a 'xaction-end' message. A 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). 6.6 xaction-end xaction-end xid [error] result Rousskov Expires September 29, 2003 [Page 12] Internet-Draft OPES Callout Protocol (OCP) March 2003 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?). 6.7 app-message-start app-message-start xid am-id am-proto am-kind source destinations ... 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 SERVER, the 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 SERVER may wait for more information to come from the CLIENT. This message introduces application message identifier (am-id). 6.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. 6.9 data-have data-have xid am-id offset size modified [copied] [sizep] [modp] [ack] Rousskov Expires September 29, 2003 [Page 13] Internet-Draft OPES Callout Protocol (OCP) March 2003 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 a CLIENT sends a "copied" flag, the CLIENT 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. 6.10 data-as-is data-as-is xid am-id offset size copy-am-id copy-am-offset Tells the CLIENT to use "size" bytes of data at copy-am-offset of the copy-am-id application message, as if that data came from the SERVER in a 'data-have am-id offset size> message. The data chunk MUST be under the preservation commitment. If the CLIENT 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 CLIENT MUST abort am-id message processing (XXX: document how processing should be aborted). 6.11 data-pause data-pause xid am-id When send by a CLIENT, the data-pause message informs the SERVER that there will be no more data for the specified application message until the SERVER explicitly asks for data using a data-need message. The CLIENT MUST stop sending application message data to the SERVER after sending a data-pause message. When send by a SERVER, the data-pause message informs the CLIENT that it should stop sending data to the SERVER until the SERVER explicitly asks for data using a data-need message. The CLIENT MUST stop sending application message data to the SERVER upon receiving a data-pause message. In both cases, processing of the corresponding application message is Rousskov Expires September 29, 2003 [Page 14] Internet-Draft OPES Callout Protocol (OCP) March 2003 said to be "paused". If the SERVER receives unexpected data for a paused message (a violation of the above MUSTs), the SERVER MAY abort application message processing. 6.12 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. 6.13 data-need data-need xid am-id offset [size] Informs the CLIENT that the SERVER needs more application message data. The "offset" parameter indicates the amount of data already received. The CLIENT MUST ignore a data-need message if the CLIENT already sent data with higher offsets. If a "size" parameter is present, its value is the suggested data size, and it MAY be ignored by the CLIENT. An absent "size" parameter implies "any size". This message clears the "paused" state of the application message processing. A CLIENT MUST NOT send data-need messages (XXX: should we give a CLIENT the same abilities to pause/resume message processing that a SERVER has?) 6.14 data-ack data-ack xid am-id offset size [wont-forward] Informs the CLIENT that the corresponding data chunk has been received by the SERVER. An optional "wont-forward" flag terminates preservation commitment for the corresponding data, if any. The flag is defined for 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. Rousskov Expires September 29, 2003 [Page 15] Internet-Draft OPES Callout Protocol (OCP) March 2003 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 SERVER does not know immediately whether it will forward the data, it MUST respond without a "wont-forward" flag. If, at any time, the 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. 6.15 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. 6.16 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. Rousskov Expires September 29, 2003 [Page 16] Internet-Draft OPES Callout Protocol (OCP) March 2003 6.17 do-you-support do-you-support feature 6.18 i-do-support i-do-support feature 6.19 i-dont-support i-dont-support feature 6.20 please-use please-use feature 6.21 i-will-use i-will-use feature 6.22 i-wont-use i-wont-use feature Rousskov Expires September 29, 2003 [Page 17] Internet-Draft OPES Callout Protocol (OCP) March 2003 7. 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 Rousskov Expires September 29, 2003 [Page 18] Internet-Draft OPES Callout Protocol (OCP) March 2003 8. IAB Concerns Document how OCP addresses applicable IAB concerns. XXX. Rousskov Expires September 29, 2003 [Page 19] Internet-Draft OPES Callout Protocol (OCP) March 2003 9. Security Considerations Document. XXX. Rousskov Expires September 29, 2003 [Page 20] Internet-Draft OPES Callout Protocol (OCP) March 2003 10. 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]. 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 21] Internet-Draft OPES Callout Protocol (OCP) March 2003 11. 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 SERVER does not know whether the data got modified (consider service outsourcing scenario, for example). copied: when a CLIENT can destroy a copy? asis: Can a SERVER refer to parts of [copied] data messages from the CLIENT? 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 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? break: allow a 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? 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? Rousskov Expires September 29, 2003 [Page 22] Internet-Draft OPES Callout Protocol (OCP) March 2003 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. Rousskov Expires September 29, 2003 [Page 23] 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 24] 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. [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@measurement-factory.com URI: http://www.measurement-factory.com/ Rousskov Expires September 29, 2003 [Page 25] 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 26] 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 27]