Open Pluggable Edge Services A. Rousskov
Internet-Draft The Measurement Factory
Expires: April 26, 2004 M. Stecher
webwasher AG
October 27, 2003
HTTP adaptation with OPES
draft-ietf-opes-http-01
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 April 26, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
Open Pluggable Edge Services (OPES) framework documents several
application-agnostic mechanisms such as OPES tracing, OPES bypass,
and OPES callout protocol. This document binds these mechanisms to
the Hypertext Transfer Protocol (HTTP). Together,
application-agnostic OPES documents and this HTTP binding constitute
a complete specification for HTTP adaptation with OPES.
Rousskov & Stecher Expires April 26, 2004 [Page 1]
Internet-Draft HTTP adaptation with OPES October 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Callout Protocol . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Application Message Parts . . . . . . . . . . . . . . . . . 4
2.2 Application Profile Features . . . . . . . . . . . . . . . . 5
2.2.1 Profile Parts . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Profile Structure . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Aux-Parts . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2.4 Pause-At-Body . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.5 Wont-Look-Body . . . . . . . . . . . . . . . . . . . . . . . 8
2.2.6 Wont-Send-Body . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.7 Content-Encodings . . . . . . . . . . . . . . . . . . . . . 9
2.2.8 Profile Negotiation Example . . . . . . . . . . . . . . . . 10
2.3 Application Message Start Message . . . . . . . . . . . . . 11
2.4 Data Use Mine Message . . . . . . . . . . . . . . . . . . . 11
2.5 Transfer Encodings . . . . . . . . . . . . . . . . . . . . . 12
2.6 HTTP Header Correctness . . . . . . . . . . . . . . . . . . 13
2.6.1 Message Size Recalculation . . . . . . . . . . . . . . . . . 13
2.6.2 Content-MD5 Header . . . . . . . . . . . . . . . . . . . . . 14
3. Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . 19
7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 20
8. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 23
Normative References . . . . . . . . . . . . . . . . . . . . 27
Informative References . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 29
Rousskov & Stecher Expires April 26, 2004 [Page 2]
Internet-Draft HTTP adaptation with OPES October 2003
1. Introduction
The Open Pluggable Edge Services (OPES) framework documents several
application-agnostic mechanisms such as OPES processor and endpoints
communications [I-D.ietf-opes-end-comm] or OPES callout protocol
[I-D.ietf-opes-ocp-core]. This document binds these mechanisms to a
specific application protocol, HTTP [RFC2616]. Together,
application-agnostic OPES documents and this HTTP binding constitute
a complete specification for HTTP adaptation with OPES.
The primary sections of this document specify HTTP bindings for the
corresponding application-agnostic mechanisms documented elsewhere.
Rousskov & Stecher Expires April 26, 2004 [Page 3]
Internet-Draft HTTP adaptation with OPES October 2003
2. Callout Protocol
This section documents HTTP bindings for the OPES callout protocol
(OCP) [I-D.ietf-opes-ocp-core].
2.1 Application Message Parts
Six parts of HTTP messages are defined as application message parts
for OCP:
This specification documents the following six application message
parts (am-part) values:
request-header: The start-line of an HTTP request message, all
request message headers, and the CRLF separator at the end of HTTP
headers (compare with section 4.1 of [RFC2616])
request-body: The message body of an HTTP request message as defined
in section 4.3 of [RFC2616] but not including the trailer
request-trailer: The entity headers of the trailer of an HTTP request
message in chunked transfer encoding. This part follows the same
syntax as the trailer defined in section 3.6.1 of [RFC2616]
response-header: The start-line of an HTTP response message, all
response message headers, and the CRLF separator at the end of
HTTP headers (compare with section 4.1 of [RFC2616])
response-body: The message body of an HTTP response message as
defined in section 4.3 of [RFC2616] but not including the trailer
response-trailer: The entity headers of the trailer of an HTTP
response message in chunked transfer encoding. This part follows
the same syntax as the trailer defined in section 3.6.1 of
[RFC2616]
This is the definition of am-part using TDM:
am-part: extends atom;
am-parts: extends list of am-part;
Figure 1
Rousskov & Stecher Expires April 26, 2004 [Page 4]
Internet-Draft HTTP adaptation with OPES October 2003
2.2 Application Profile Features
This document defines two HTTP profiles for OCP, depending on the
original and adapted parts exchanged between OCP agents. These
profiles are described below. For each of the profiles, the feature
identifier as well as original and adapted message parts is
documented. Some original parts are auxiliary parts and will only be
used if explicitly negotiated for a profile; these parts are marked
with "(aux)".
http://iana.org/opes/ocp/HTTP/request
original parts: request-header, request-body, request-trailer
adapted parts variant 1: request-header, request-body,
request-trailer
adapted parts variant 2: response-header, response-body,
response-trailer
http://iana.org/opes/ocp/HTTP/response
original parts: request-header (aux), request-body (aux),
request-trailer (aux), response-header,
response-body, response-trailer
adapted parts: response-header, response-body, response-trailer
The scope of a negotiated profile is the OCP connection.
An OCP agent MUST send application message parts in the order
specified above. An OCP agent receiving an out-of-order part MAY
terminate the transaction with an error.
An OPES processor MUST NOT send parts that are not listed as
"original" in the negotiated profile. An callout server MUST NOT send
parts that are not listed as "adapted" in the negotiated profile. An
OCP agent receiving an not-listed part MUST terminate the transaction
with an error. The informal rationale for the last requirement is to
reduce the number of subtle interoperability problems where an agent
thinks that the parts it is sending are understood/used by the other
agent when, in fact, they are being ignored or skipped because they
are not expected.
In the request profile the callout server can choose from two
variants. Either it can adapt the original parts or send "response-"
message parts. Informally, it will choose the second variant if it
wants to "short-circuit" and return an HTTP message instead of
Rousskov & Stecher Expires April 26, 2004 [Page 5]
Internet-Draft HTTP adaptation with OPES October 2003
modifying the HTTP request, for example in order to send an HTTP
error message in response to an HTTP request that the callout service
defines as forbidden.
The callout server MUST NOT send message parts from one variant's
list if it has already sent message parts of the other variant for
the same transaction (informally, it MUST decide on which variant to
use before it sends the first application message part). An OPES
processor receiving message parts from both variants MUST terminate
the transaction with an error.
(XXX: Is it ok to call the second variant still adapted parts?
Actually there is no adaptation of anything that has existed before.)
2.2.1 Profile Parts
Some HTTP messages lack certain parts. For example, many HTTP
requests do not have bodies, and most HTTP messages do not have
trailers. An OCP agent MUST NOT send (i.e., must skip) absent message
parts.
An OCP agent MUST send present non-auxiliary message parts and it
MUST send those auxiliary message parts that were negotiated via the
Aux-Parts (Section 2.2.3) parameter. OCP agents MUST NOT send
auxiliary parts that were not negotiated via the Aux-Parts (Section
2.2.3) parameter.
An OCP agent receiving a message part in violation of the above
requirements MAY terminate the corresponding transaction with an
error.
By design, original parts not included in the adapted parts list
cannot be adapted. In other words, a callout service can only adapt
parts in the adapted parts list even though it may have access to
other parts. (XXX: There is no way for a processor to tell the
service "look at this part, but do not adapt it"; We do not need such
a feature, do we?)
2.2.2 Profile Structure
An HTTP application profile feature extends the Feature type of OCP
core and adds additional named parameters. HTTP-Profiles can be used
in feature lists of Negotiation Offer (NO) messages and an
HTTP-Pofile can be used in the Negotiation Response (NR) message.
o Aux-Parts (Section 2.2.3)
o Pause-At-Body (Section 2.2.4)
Rousskov & Stecher Expires April 26, 2004 [Page 6]
Internet-Draft HTTP adaptation with OPES October 2003
o Wont-Look-Body (Section 2.2.5)
o Wont-Send-Body (Section 2.2.6)
o Content-Encodings (Section 2.2.7)
This is the definition of the HTTP profile feature structure using
TDM:
HTTP-Profile: extends Feature with {
[Aux-Parts: am-parts];
[Pause-At-Body: size];
[Wont-Look-Body: size];
[Wont-Send-Body: size];
[Content-Encodings: codings];
};
Figure 2
2.2.3 Aux-Parts
The Aux-Parts parameter of an HTTP response profile can be used to
negotiate the inclusion of auxiliary application message parts into
the original data flow. The parameter is a possibly empty list of
am-part tokens. An OPES processor MAY send an Aux-Parts parameter to
advertise availability of auxiliary application message parts. A
callout server MAY respond with a possibly empty subset of the parts
it needs. The callout server response defines the subset of
successfully negotiated auxiliary message parts.
An OPES processor MUST NOT include any message part which is not
marked as auxiliary part in the list of original parts for the given
profile. The callout server MUST ignore non-auxiliary parts listed in
the Aux-Parts parameter. The callout server MUST NOT include any
message part that was not explicitly listed in the negotiation offer.
In case of a violation of this rule the OPES processor MUST terminate
the transaction.
An OPES processor MUST send each negotiated auxiliary part to the
callout server, unless the part is absent.
Example:
Aux-Parts: (request-header,request-body)
Figure 3
Rousskov & Stecher Expires April 26, 2004 [Page 7]
Internet-Draft HTTP adaptation with OPES October 2003
2.2.4 Pause-At-Body
The parameter Pause-At-Body can be used to pre-request a pause in
application message body part transmission. The parameter's value is
of type "size" and denominates an offset into the original,
non-auxiliary message body part (request-body in HTTP request profile
and response-body in response profile).
A callout service MAY send a Pause-At-Body parameter to request the
pause. An OPES processor SHOULD behave as if it receives a data-pause
message at the time that it will have sent the given number of OCTETs
of the application message body part.
For example, if the Pause-At-Body value is zero, the OPES processor
SHOULD send a data-paused message just before it sends the first DUM
message with the response-body part in the HTTP response profile, and
if the parameter's value is 300, the OPES processor SHOULD send a
data-paused message after transmitting 300 OCTETs for that
application message part.
Example:
Pause-At-Body: 0
Figure 4
2.2.5 Wont-Look-Body
The parameter Wont-Look-Body can be used to generalize Wont-Look
message behavior for all transactions of a profile. The parameter's
value is of type "size" and denominates an offset into the original,
non-auxiliary message body part (request-body in HTTP request profile
and response-body in response profile).
A callout service MAY send a Wont-Look-Body parameter with its
negotiation response if there is a fixed offset into the message body
for all transactions of a profile at which a Data Won't Look At Yours
(DWLY) message would be sent. An OPES processor SHOULD behave as if
it receives a DWLY message at the time that it will have sent the
given number of OCTETs of the application message body part.
For example, if the Wont-Look-Body value is zero in an HTTP response
profile, the OPES processor SHOULD send an AME message with result
code 206 after sending the response-header message part and before
starting with the response-body message part.
Example:
Wont-Look-Body: 0
Rousskov & Stecher Expires April 26, 2004 [Page 8]
Internet-Draft HTTP adaptation with OPES October 2003
Figure 5
2.2.6 Wont-Send-Body
The parameter Wont-Send-Body can be used to optimize the data
preservation commitment of the OPES processor. The parameter's value
is of type "size" and denominates an offset into the original,
non-auxiliary message body part (request-body in HTTP request profile
and response-body in response profile).
A callout service MAY send a Wont-Send-Body parameter with its
negotiation response if there is a fixed offset into the message body
for all transactions of a profile at which a Data Won't Send Yours
(DWSY) message would be sent. An OPES processor SHOULD behave as if
it receives a DWSY message at the time that it will have sent the
given number of OCTETs of the application message body part.
For example, if the Wont-Send-Body value is 2147483647 in an HTTP
response profile, the callout server MUST NOT send any DUY message
for the response-body part; the OPES processor MAY use this to
optimize its data preservation behavior.
Example:
Wont-Send-Body: 2147483647
Figure 6
2.2.7 Content-Encodings
A callout server MAY send a Content-Encodings list to indicate its
preferences in content encodings. Encodings listed first are
preferred to other encodings. An OPES processor MAY use any content
encoding when sending application messages to a callout server.
The list of preferred content encodings does not imply lack of
support for other encodings. The OPES processor MUST NOT bypass a
service just because the actual content encoding does not match the
service's preferences.
If an OCP agent receives an application message that it cannot handle
due to specific content encoding, the usual transaction termination
rules apply.
content-coding: extends atom;
content-codings: extends list of content-coding;
Rousskov & Stecher Expires April 26, 2004 [Page 9]
Internet-Draft HTTP adaptation with OPES October 2003
Example:
Content-Encodings: (gzip)
Figure 7
The semantics of content-coding is defined in section 3.5 of
[RFC2616].
2.2.8 Profile Negotiation Example
Example:
NO ({"38:http://iana.org/opes/ocp/HTTP/response"
Aux-Parts: (request-header,request-body)
})
SG: 5;
NR {"38:http://iana.org/opes/ocp/HTTP/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Wont-Send-Body: 2147483647
Content-Encodings: (gzip)
}
SG: 5;
Figure 8
This example shows a negotiation offer made by an OPES processor for
a service group (id 5) that has already been created; the callout
server sends an adequate negotiation response.
The OPES processor offers one profile feature for HTTP response
messages. Besides the standard message parts, the OPES processor is
able to add the header and body of the original HTTP request as
auxiliary message parts.
The callout server requests the auxiliary request-header message
part; it is not interested in either the auxiliary request-body or in
the response-body part that it requests to skip.
The OPES processor sends the following message parts, in the
specified order, for all transactions in service group 5:
request-header, response-header, response-body, response-trailer.
Note that the request-body part is not included (because it is an
auxiliary parts and not explicitly requested).
The callout server indicates through the Wont-Send-Body parameter
with the maximum size value that it will not send any DUY messages.
The OPES processor may therefore resign from data preservation for
all transaction of this profile; none of its DUM messages will have a
Rousskov & Stecher Expires April 26, 2004 [Page 10]
Internet-Draft HTTP adaptation with OPES October 2003
Kept parameter.
By sending a Pause-At-Body value of 30, the callout service requests
a data-paused message that the OPES processor will send after sending
30 OCTETs of the response-body part of any transaction for this
profile. Thereafter, the OPES processor will wait for data-need
message of the callout service.
2.3 Application Message Start Message
A new named parameter for Application Message Start (AMS) messages is
introduced.
AM-EL: size
Figure 9
An OCP Agent that knows the exact length of the HTTP message entity
(Section 7.2.2 Entity Length in [RFC2616]) at the time it sends the
AMS message, SHOULD announce this length using the AM-EL named
parameter of an AMS message. If the entity length is not known, the
AM-EL parameter MUST be omitted. Reporting correct entity length can
have significant performance advantages for the recipients, and
implementations are strongly encouraged to support this rule.
Similarly, reporting incorrect entity length can have drastic
correctness consequences for the recipients, and implementations are
urged to exercise great care when reporting entity length.
As defined by HTTP, AM-EL is the length of the request-body part in
the HTTP request profile, and is the length of the response-body part
in the HTTP response profile, before any transfer codings have been
applied.
An OPES processor receiving an AM-EL parameter SHOULD use the
parameter's value in a Content-Length HTTP entity header when
constructing an HTTP message, provided a Content-Length HTTP entity
header is allowed for the given application message by HTTP (see
"Message Size Recalculation" (Section 2.6.1)).
2.4 Data Use Mine Message
A new named parameter for Data Use Mine (DUM) messages is introduced.
AM-Part: am-part
Rousskov & Stecher Expires April 26, 2004 [Page 11]
Internet-Draft HTTP adaptation with OPES October 2003
Figure 10
An OCP agent MUST use an AM-Part parameter with every DUM message
that is a part of an OCP transaction with an HTTP profile. The
AM-Part parameter value is a single am-part token. As implied by the
syntax, a DUM message can only contain data of a single application
message part. One message part can be fragmented into any number of
DUM messages with the same AM-Part parameter.
The following example shows three DUM messages containing a very
simple and reduced HTTP response message. The response-body part is
fragmented and sent within two DUM messages.
DUM 88 1 0
Kept: 0
AM-Part: response-header
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51
;
DUM 88 1 64
Kept: 64
AM-Part: response-body
19:<html><body>This is;
DUM 88 1 83
Kept: 83
AM-Part: response-body
32: a simple message.</body></html>;
Figure 11
2.5 Transfer Encodings
Adaptations that use HTTP transfer encodings MUST be explicitly
negotiated. This specification does not document such negotiations.
In the absence of explicit transfer-encoding negotiations, an OCP
agent MUST NOT send transfer-encoded application messages.
Informally, this means that the agent or its environment have to make
sure that all transfer encodings are stripped before an application
message enters OCP scope. An agent MUST terminate an OCP transaction
Rousskov & Stecher Expires April 26, 2004 [Page 12]
Internet-Draft HTTP adaptation with OPES October 2003
if it cannot remove all transfer encodings. Violations of these rules
would lead to interoperability problems.
If an OCP agent receives transfer-encoded application data in
violation of the above requirement, the agent MAY terminate the
corresponding OCP transaction.
An OPES processor removing transfer encodings SHOULD NOT remove the
Transfer-Encoding header before sending the header part to the
callout service. The OPES processor MUST send a correct
Transfer-Encoding header to the next HTTP recipient independent of
what header the callout server returned.
2.6 HTTP Header Correctness
When communicating with HTTP applications, OPES processors MUST
ensure correctness of all computable HTTP headers documented in
specifications that the processors intend to be compliant with. A
computable header is defined as a header which value can be computed
based on the message body alone. For example, the correctness of
Content-Length and Content-MD5 headers has to be ensured by
processors claiming compliance with HTTP/1.1 ([RFC2616]).
Informally, the OPES processor by default has to validate and
eventually recalculate, add, or remove computable HTTP headers in
order to recreate a compliant HTTP message. If a particular OPES
processor trusts certain HTTP headers that a callout service sends,
it can use those headers "as is".
An OPES processor MAY forward the response of a callout service to
other callout services without verifying HTTP header correctness.
Consequently, a callout service cannot assume that the HTTP headers
it receives are correct or final from an HTTP point of view.
The following subsections present guidelines for the recalculation of
some HTTP headers.
2.6.1 Message Size Recalculation
By default an OCP agent MUST NOT trust the Content-Length header that
is sent within an HTTP header message part. The message length could
be modified by a callout service without adaptation of the HTTP
message headers.
Before sending the HTTP message to the HTTP peer, the OPES processor
MUST ensure correctness of the message length indication according to
section 4.4 of [RFC2616].
Rousskov & Stecher Expires April 26, 2004 [Page 13]
Internet-Draft HTTP adaptation with OPES October 2003
Besides message correctness, the OPES processor SHOULD set up the
message in a way that guarantees good performance and low latency.
End of message indication, by simply closing the connection, SHOULD
be the last choice only.
(XXX: all these requirements seem to be out of our scope. Should we
make them informal?)
o If the callout server sends an AM-EL parameter with its AMS
message, the OPES processor SHOULD use this value to create a
Content-Length header to be able to keep a persistent HTTP
connection. Note that a Content-Length header MUST NOT be used if
a transfer coding is to be applied.
o If there is no AM-EL parameter, the OPES processor SHOULD consider
using chunked transfer encoding for the HTTP message if both the
OPES processor and the next HTTP recipient are HTTP/1.1
([RFC2616]) applications. Note that any Content-Length header MUST
be removed in this case.
o If the message size is not known a priori and chunked transfer
coding cannot be used, the OPES processor has to decide whether it
is suitable to wait for the OCP transaction to finish and collect
all HTTP message data, thus being able to calculate and add a
Content-Length header to the message but increasing the latency
time, or delete any Content-Length header, forwarding the data
immediately and indicating the message end by closing the
connection, thus destroying connection persistency. The latter
SHOULD be the choice if the connection cannot be persistent in the
first place due to other reasons, for example because a
"Connection: close" header has been sent with the HTTP request.
2.6.2 Content-MD5 Header
By default the OPES processor MUST assume that the callout service
will modify the content in a way that the MD5 checksum of the message
body will become invalid.
According to section 14.15 of [RFC2616], the Content-MD5 header MUST
NOT be generated by proxies. A recalculation is therefore possible
only if the OPES processor is considered authoritative for the entity
being adapted. An un-authoritative OPES processor MUST remove the
Content-MD5 header unless it can detect that the message was not
modified; in this case it MAY leave the Content-MD5 header in the
message. If such detection significantly increases message latency,
deleting the Content-MD5 header could be a better option.
Rousskov & Stecher Expires April 26, 2004 [Page 14]
Internet-Draft HTTP adaptation with OPES October 2003
3. Tracing
[I-D.ietf-opes-end-comm] defines application-agnostic tracing
facilities in OPES. When adapting HTTP, trace entries are supplied
using HTTP message headers. The following HTTP extension headers are
defined to carry trace entries. Their definitions are given using BNF
notation and elements defined in [RFC2616].
OPES-System = "OPES-System" ":" #trace-entry
OPES-Processor = "OPES-Processor" ":" #trace-entry
OPES-Service = "OPES-Service" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
Figure 12
OPES agents MUST use corresponding headers to represent their trace
entries. Note that all of these headers are defined using #list
constructs and, hence, a valid HTTP message may contain multiple
entries of each header.
For example, here is an HTTP response message header after OPES
adaptations have been applied by a single OPES processor executing 10
OPES services:
HTTP/1.1 200 OK
Date: Thu, 18 Sep 2003 06:25:24 GMT
Last-Modified: Wed, 17 Sep 2003 18:24:25 GMT
Content-type: application/octet-stream
OPES-Service: http://www.opes-services-4u.com/cat/?sid=123
OPES-System: http://www.example-cdn.com/opes?session=ac79a7901549f56
OPES-Service: http://www.opes-services-4u.com/cat/?sid=124,
http://www.opes-services-4u.com/cat/?sid=125 ; mode=A
Figure 13
In the above example, the OPES processor has not included its trace
entry or its trace entry was replaced by an OPES system trace entry.
Only 3 out of 10 services are traced. The remaining services did not
include their entries or their entries were removed by OPES system or
processor. The last traced service included a "mode" parameter.
Various identifiers in trace entries will probably have no meaning to
the recipient of the message, but may be decoded by OPES service
software.
See [I-D.ietf-opes-end-comm] for all valid mappings of OPES agents to
trace entries and for discussion on valid OPES agent identifiers.
Rousskov & Stecher Expires April 26, 2004 [Page 15]
Internet-Draft HTTP adaptation with OPES October 2003
Implementations MAY place optional tracing entries in a message
trailer (i.e., entity-headers at the end of a Chunked-Body of a
chunked-encoded message), provided trailer presence does not violate
HTTP protocol. See [I-D.ietf-opes-end-comm] for a definition of what
tracing entries are optional. Implementations MUST NOT place required
tracing entries in a message trailer.
Rousskov & Stecher Expires April 26, 2004 [Page 16]
Internet-Draft HTTP adaptation with OPES October 2003
4. Bypass
An HTTP extension header is introduced to allow for OPES system
bypass as defined in [I-D.ietf-opes-end-comm].
OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry )
bypass-entry = opes-agent-id
Figure 14
This header can be added to HTTP requests to request OPES system
bypass for the listed OPES agents. The asterisk "*" character is used
to represent all possible OPES agents.
See [I-D.ietf-opes-end-comm] for what can be bypassed and bypass
requirements.
Rousskov & Stecher Expires April 26, 2004 [Page 17]
Internet-Draft HTTP adaptation with OPES October 2003
5. IAB Considerations
OPES treatment of IETF Internet Architecture Board (IAB)
considerations [RFC3238] are documented in "OPES Treatment of IAB
Considerations" [I-D.ietf-opes-iab].
Rousskov & Stecher Expires April 26, 2004 [Page 18]
Internet-Draft HTTP adaptation with OPES October 2003
6. Security Considerations
Application-independent security considerations are documented in
application-agnostic OPES specifications. HTTP binding does not
introduce any HTTP-specific security considerations.
Rousskov & Stecher Expires April 26, 2004 [Page 19]
Internet-Draft HTTP adaptation with OPES October 2003
7. Compliance
Compliance with OPES mechanisms is defined in corresponding
application-agnostic specifications. HTTP-specific bindings for
these mechanisms use corresponding compliance definitions from these
specifications, as if each binding was incorporated into the
application-agnostic specification it binds to.
Rousskov & Stecher Expires April 26, 2004 [Page 20]
Internet-Draft HTTP adaptation with OPES October 2003
8. To-do
XXX: Fix all XXXs.
Rousskov & Stecher Expires April 26, 2004 [Page 21]
Internet-Draft HTTP adaptation with OPES October 2003
Appendix A. Acknowledgements
Special thanks to Marshall Rose for his xml2rfc tool.
Rousskov & Stecher Expires April 26, 2004 [Page 22]
Internet-Draft HTTP adaptation with OPES October 2003
Appendix B. Change Log
Internal WG revision control ID: $Id: http.xml,v 1.53 2003/10/27
10:24:37 stecher Exp $
2003/10/27
* Proof reading.
* Renamed document to draft-ietf-opes-http-01.
* Wont-Send-Body parameter refers to DWSY message and
Wont-Look-Body parameter refers to DWLY messages of OCP core.
2003/10/26
* Deleted resolved XXXes.
* Section "Profile Parts": Cleaned-up and removed ambiguities.
* Renamed Wont-Use-Body to Wont-Send-Body and added
Wont-Look-Body
* Documented OCP parameters in TDM as required by OCP core.
* Adjusted the Profile Negotiation example
* Remove Skip-Parts and added Wont-Use-Body and Pause-At-Body. We
agreed that these parameters solve the
what-parts-to-send-or-skip problem that Skip-Parts introduced.
2003/10/24
* Changed beginning of section HTTP Header Correctness to "When
communicating with HTTP applications, OPES processors MUST..."
* Added second variant of adapted parts for request profile and
so introduced short-circuit possibility for callout services.
* Removed the comment about Transfer-Encoding problems; there is
no problem if we have a MUST that precludes any encodings and a
MUST that terminates the transaction if not all encodings can
be removed. Added 2nd MUST and an informal sentence that warns
for interoperability problems if these rules are violated.
* Renamed optional parts to auxiliary parts; Optional-Parts
parameter becomes Aux-Parts
Rousskov & Stecher Expires April 26, 2004 [Page 23]
Internet-Draft HTTP adaptation with OPES October 2003
2003/10/22
* Fixed the after-negotiation part of the profile negotiation
example.
* An OPES processor has to use the adapted version of the skipped
part if it is available or processor's own (original) version
of the part if the callout server did not send an adapted
version.
* AM-Parts not listed in the corresponding section of a
negotiated profile MUST NOT be sent.
* Deleted resolved XXXes.
* Resurrected and polished a note that original parts not
included in the adapted parts list cannot be adapted.
* Skipped parts MAY be sent by processor because a MUST NOT send
requirement would essentially require buffering a potentially
large part at the processor. The MAY requirement moves the
burden to the service, which is likely to be in a better
position than processor to optimize.
* Do not support extension am-parts explicitly; extension/new
profiles can defined them explicitly as needed and a different
profile would most certainly be required to add a meaningful
new part anyway.
* Proof reading
2003/10/21
* Added few more XXXs and commented others. All new comments are
marked with (MS).
* Replaced "am-part string" with "am-part tokens"
2003/10/20
* Made sure that most RFC2119 requirements have a subject.
* Added XXXs to identify places that need more work.
* Added section Application Message Start introducing AM-EL named
parameter
* Removed sizep parameter reference
Rousskov & Stecher Expires April 26, 2004 [Page 24]
Internet-Draft HTTP adaptation with OPES October 2003
* Updated Message Size Recalculation section
* Added references to other documents
* Filled bypass section
* Little first proofreading
2003/10/17
* Completed section HTTP Header Correctness
* Note about header correctness in Transfer-Encodings section
2003/10/16
* Removed Transfer-Encodings as a named parameter of profile
feature
* Moved Transfer-Encodings section
* Added section HTTP Header Correctness
2003/10/13
* Filled transfer- and content-encodings paragraphs
* Fixed negotiation example
2003/10/10
* Filled application message part section.
* Added Data Use Mine Message section.
* Restructured, changed and enhanced Callout Protocol section and
subsections.
2003/09/24
* Removed duplicate and empty Tracing section.
* Moved the Bypass section behind the Tracing section.
head-sid13
* Removed HTTP-transaction profile, added optional parts as
feature parameters, added example.
Rousskov & Stecher Expires April 26, 2004 [Page 25]
Internet-Draft HTTP adaptation with OPES October 2003
head-sid12
* Initial revision.
Rousskov & Stecher Expires April 26, 2004 [Page 26]
Internet-Draft HTTP adaptation with OPES October 2003
Normative References
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.ietf-opes-end-comm]
Barbir, A., "OPES processor and end points
communications", draft-ietf-opes-end-comm-03 (work in
progress), October 2003.
[I-D.ietf-opes-ocp-core]
Rousskov, A., "OPES Callout Protocol Core",
draft-ietf-opes-ocp-core-01 (work in progress), August
2003.
[I-D.ietf-opes-iab]
Barbir, A. and A. Rousskov, "OPES Treatment of IAB
Considerations", draft-ietf-opes-iab-02 (work in
progress), September 2003.
Rousskov & Stecher Expires April 26, 2004 [Page 27]
Internet-Draft HTTP adaptation with OPES October 2003
Informative References
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
Authors' Addresses
Alex Rousskov
The Measurement Factory
EMail: rousskov@measurement-factory.com
URI: http://www.measurement-factory.com/
Martin Stecher
webwasher AG
Vattmannstr. 3
Paderborn 33100
DE
EMail: martin.stecher@webwasher.com
URI: http://www.webwasher.com/
Rousskov & Stecher Expires April 26, 2004 [Page 28]
Internet-Draft HTTP adaptation with OPES October 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 & Stecher Expires April 26, 2004 [Page 29]
Internet-Draft HTTP adaptation with OPES October 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 & Stecher Expires April 26, 2004 [Page 30]
