One document matched: draft-rousskov-opes-ocp-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 06:45:29 |