Alex,
my feed back on the draft attached
Abbie
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>
<connection-start [client] [priority]>
<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>
<connection-end>
<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>
<connection-priority priority>
<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>
<connection-service service>
<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>
<xaction-start xid [service]>
<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>
<xaction-end xid [error] result>
<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>
<app-message-start xid am-id meta-data ...>
<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>
<app-message-end xid am-id [error] result ...>
<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>
<data-have xid am-id offset size data modified [copied] [sizep]
[modp] [ack]>
<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>
<data-as-is xid am-id offset size copy-am-id copy-am-offset>
<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>
<data-pause xid am-id>
<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>
<data-paused xid am-id>
<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>
<data-end xid am-id [error] result>
<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>
<data-need xid am-id offset [size-request]>
<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>
<data-ack xid am-id offset size [wont-forward]>
<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>
<i-am-here [rid] [xid [am-id]]>
<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>
<are-you-there rid [xid [am-id]]>
<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>
<do-you-support feature>
6.19 i-do-support
<120>
<i-do-support feature>
6.20 i-dont-support
<121>
<i-dont-support feature>
6.21 please-use
<122>
<please-use feature>
Rousskov Expires September 29, 2003 [Page 19]
Internet-Draft OPES Callout Protocol (OCP) March 2003
6.22 i-will-use
<123>
<i-will-use feature>
6.23 i-wont-use
<124>
<i-wont-use feature>
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@xxxxxxxxxxxxxxxxxxxxxxx
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]