HTTP Adaptation with Open Pluggable Edge Services (OPES)
draft-ietf-opes-http-03
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4236.
|
|
|---|---|---|---|
| Authors | Alex Rousskov , Martin Stecher | ||
| Last updated | 2013-03-02 (Latest revision 2005-04-20) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4236 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Ted Hardie | ||
| Send notices to | (None) |
draft-ietf-opes-http-03
Open Pluggable Edge Services A. Rousskov
Internet-Draft The Measurement Factory
Expires: October 21, 2004 M. Stecher
CyberGuard Corporation
April 19, 2004
HTTP adaptation with OPES
draft-ietf-opes-http-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 October 21, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Open Pluggable Edge Services (OPES) framework documents several
application-agnostic mechanisms such as OPES tracing, OPES bypass,
and OPES callout protocol. This document extends those generic
mechanisms for Hypertext Transfer Protocol (HTTP) adaptation.
Together, application-agnostic OPES documents and this HTTP profile
constitute a complete specification for HTTP adaptation with OPES.
Rousskov & Stecher Expires October 21, 2004 [Page 1]
Internet-Draft HTTP adaptation with OPES April 2004
Table of Contents
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. OPES Document Map . . . . . . . . . . . . . . . . . . . . . . 4
3. Callout Protocol . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Application Message Parts . . . . . . . . . . . . . . . . 6
3.2 Application Profile Features . . . . . . . . . . . . . . . 7
3.2.1 Profile Parts . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Profile Structure . . . . . . . . . . . . . . . . . . 9
3.2.3 Aux-Parts . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4 Pause-At-Body . . . . . . . . . . . . . . . . . . . . 10
3.2.5 Stop-Receiving-Body . . . . . . . . . . . . . . . . . 11
3.2.6 Preservation-Interest-Body . . . . . . . . . . . . . . 11
3.2.7 Content-Encodings . . . . . . . . . . . . . . . . . . 12
3.2.8 Profile Negotiation Example . . . . . . . . . . . . . 13
3.3 Application Message Start Message . . . . . . . . . . . . 14
3.4 DUM Message . . . . . . . . . . . . . . . . . . . . . . . 14
3.5 Selective Adaptation . . . . . . . . . . . . . . . . . . . 15
3.6 Hop-by-hop Headers . . . . . . . . . . . . . . . . . . . . 16
3.7 Transfer Encodings . . . . . . . . . . . . . . . . . . . . 16
3.8 HTTP Header Correctness . . . . . . . . . . . . . . . . . 17
3.8.1 Message Size Recalculation . . . . . . . . . . . . . . 17
3.8.2 Content-MD5 Header . . . . . . . . . . . . . . . . . . 18
3.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18
4. Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 30
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1 Normative References . . . . . . . . . . . . . . . . . . . 38
10.2 Informative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . 40
Rousskov & Stecher Expires October 21, 2004 [Page 2]
Internet-Draft HTTP adaptation with OPES April 2004
1. Scope
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 extends those generic
mechanisms for adaptation of a specific application protocol, HTTP
[RFC2616]. Together, application-agnostic OPES documents and this
HTTP profile constitute a complete specification for HTTP adaptation
with OPES.
The primary sections of this document specify HTTP-specific
extensions for the corresponding application-agnostic mechanisms
documented elsewhere.
Rousskov & Stecher Expires October 21, 2004 [Page 3]
Internet-Draft HTTP adaptation with OPES April 2004
2. OPES Document Map
This document belongs to a large set of OPES specifications produced
by the IETF OPES Working Group. Familiarity with the overall OPES
approach and typical scenarios is often essential when trying to
comprehend isolated OPES documents. This section provides an index
of OPES documents to assist the reader with finding "missing"
information.
o The document on "OPES Use Cases and Deployment Scenarios"
[I-D.ietf-opes-scenarios] describes a set of services and
applications that are considered in scope for OPES and have been
used as a motivation and guidance in designing the OPES
architecture.
o The OPES architecture and common terminology are described in "An
Architecture for Open Pluggable Edge Services (OPES)" [I-D.ietf-
opes-architecture].
o "Policy, Authorization and Enforcement Requirements of OPES"
[I-D.ietf-opes-authorization] outlines requirements and
assumptions on the policy framework, without specifying concrete
authorization and enforcement methods.
o "Security Threats and Risks for OPES" [I-D.ietf-opes-threats]
provides OPES risk analysis, without recommending specific
solutions.
o "OPES Treatment of IAB Considerations" [I-D.ietf-opes-iab]
addresses all architecture-level considerations expressed by the
IETF Internet Architecture Board (IAB) when the OPES WG was
chartered.
o At the core of the OPES architecture are the OPES processor and
the callout server, two network elements that communicate with
each other via an OPES Callout Protocol (OCP). The requirements
for such protocol are discussed in "Requirements for OPES Callout
Protocols" [I-D.ietf-opes-protocol-reqs].
o "OPES Callout Protocol Core" [I-D.ietf-opes-ocp-core] specifies an
application agnostic protocol core to be used for the
communication between OPES processor and callout server.
o "OPES entities and end points communications" [I-D.ietf-opes-end-
comm] specifies generic tracing and bypass mechanisms for OPES.
o The OCP Core and Communications documents are independent from the
application protocol being adapted by OPES entities. Their
Rousskov & Stecher Expires October 21, 2004 [Page 4]
Internet-Draft HTTP adaptation with OPES April 2004
generic mechanisms have to be complemented by application-specific
profiles. This document, HTTP adaptation with OPES, is such an
application profile for HTTP. It specifies how application-
agnostic OPES mechanisms are to be used and augmented in order to
support adaptation of HTTP messages.
o Finally, "P: Message Processing Language" [I-D.ietf-opes-rules-p]
defines a language for specifying what OPES adaptations (e.g,
translation) must be applied to what application messages (e.g.,
e-mail from bob@example.com). P language is meant for configuring
application proxies (OPES processors).
Rousskov & Stecher Expires October 21, 2004 [Page 5]
Internet-Draft HTTP adaptation with OPES April 2004
3. Callout Protocol
This section documents the HTTP profile for the OPES Callout Protocol
(OCP) Core [I-D.ietf-opes-ocp-core]. Familiarity with OCP Core is
required to understand the HTTP profile. This section uses OCP Core
conventions, terminology, and mechanisms.
OPES processor communicates its desire to adapt HTTP messages via a
Negotiation Offer (NO) message with HTTP-specific feature identifiers
documented in Section 3.2. HTTP-specific OCP optimization mechanisms
can be negotiated at the same time. A callout server that supports
adaptation of HTTP messages has a chance to negotiate what HTTP
message parts will participate in adaptation, including negotiation
of HTTP request parts as metadata for HTTP response adaptation.
Negotiable HTTP message parts are documented in Section 3.1.
HTTP profile introduces a new parameter for the Application Message
Start (AMS) message to communicate known HTTP message length (HTTP
headers often do not convey length information reliably or at all).
This parameter is documented in Section 3.3. Section 3.4 documents a
mechanism to report HTTP message part with Data Use Mine (DUM)
messages.
The remaining OCP sections document various OCP marshaling corner
cases such as handling of HTTP transfer encodings and 100 Continue
responses.
3.1 Application Message Parts
An HTTP message may have several well-known parts: headers, body, and
trailers. HTTP OPES processors are likely to have information about
HTTP message parts because they have to isolate and interpret HTTP
headers and find HTTP message boundaries. Callout servers may either
not care about certain parts or may benefit from reusing HTTP OPES
processor work on isolating and categorizing interesting parts.
The following is the declaration of am-part (application message
part) type using OCP Core Protocol Element Type Declaration Mnemonic
(PETDM):
am-part: extends atom;
am-parts: extends list of am-part;
Figure 1
The following six "am-part" atoms are valid values:
Rousskov & Stecher Expires October 21, 2004 [Page 6]
Internet-Draft HTTP adaptation with OPES April 2004
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].
3.2 Application Profile Features
This document defines two HTTP profiles for OCP: request and response
profiles. These two profiles are described below. Each profile has
a unique feature identifier, a list of original application message
parts, and a list of adapted application message parts:
profile ID: http://www.iana.org/assignments/opes/ocp/http/request
original request parts: request-header, request-body, request-
trailer
adapted request parts: request-header, request-body, request-
trailer
adapted response parts: response-header, response-body, response-
trailer
profile ID: http://www.iana.org/assignments/opes/ocp/http/response
original transaction parts: request-header (aux), request-body
(aux), request-trailer (aux), response-header, response-body,
response-trailer
Rousskov & Stecher Expires October 21, 2004 [Page 7]
Internet-Draft HTTP adaptation with OPES April 2004
adapted response parts: response-header, response-body, response-
trailer
The request profile contains two variants of adapted part lists: HTTP
request parts and HTTP response parts. Parts marked with an "(aux)"
suffix are auxiliary parts that can only be used if explicitly
negotiated for a profile. See Section 3.2.1 for specific rules
governing negotiation and use of am-parts.
The scope of a negotiated profile is the OCP connection (default) or
the service group specified via the SG parameter.
3.2.1 Profile Parts
An OCP agent MUST send application message parts in the order implied
by the profile parts lists 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.
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
application message parts.
An OCP agent MUST send present non-auxiliary parts and it MUST send
those present auxiliary parts that were negotiated via the Aux-Parts
(Section 3.2.3) parameter. OCP agents MUST NOT send auxiliary parts
that were not negotiated via the Aux-Parts (Section 3.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.
In the request profile, the callout server MUST send either adapted
Rousskov & Stecher Expires October 21, 2004 [Page 8]
Internet-Draft HTTP adaptation with OPES April 2004
request parts or adapted response parts. An OPES processor receiving
adapted flow with application message parts from both lists (in
violation of the previous rule) MUST terminate the OCP transaction
with an error. Informally, the callout server sends adapted response
parts to "short-circuit" the HTTP transaction, forcing the OPES
processor to return an HTTP response without forwarding an adapted
HTTP request. This short-circuiting is useful for responding, for
example, to an HTTP request that the callout service defines as
forbidden.
Unless explicitly configured to do otherwise, an OPES processor MUST
offer all non-auxiliary original parts in Negotiation Offer (NO)
messages. See Section 3.5 for this rule rationale and examples of
harmful side-effects from selective adaptation.
3.2.2 Profile Structure
An HTTP application profile feature extends semantics of the feature
type of OCP Core while adding the following named parameters to that
type:
o Aux-Parts (Section 3.2.3)
o Pause-At-Body (Section 3.2.4)
o Stop-Receiving-Body (Section 3.2.5)
o Preservation-Interest-Body (Section 3.2.6)
o Content-Encodings (Section 3.2.7)
The definition of the HTTP profile feature structure using PETDM
follows:
HTTP-Profile: extends Feature with {
[Aux-Parts: am-parts];
[Pause-At-Body: size];
[Stop-Receiving-Body: size];
[Preservation-Interest-Body: size];
[Content-Encodings: codings];
};
Figure 2
An HTTP profile structure can be used in feature lists of Negotiation
Offer (NO) messages and as anonymous parameter of an Negotiation
Response (NR) message. All profile parameters apply to any OCP
transaction within profile scope.
Rousskov & Stecher Expires October 21, 2004 [Page 9]
Internet-Draft HTTP adaptation with OPES April 2004
3.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.
When receiving a Negotiation Offer (NO) message, the callout server
MUST ignore any non-auxiliary part listed in the Aux-Parts parameter.
When sending a Negotiation Response (NR) message, the callout server
MUST NOT select any application message part that was not explicitly
listed in the negotiation offer. In case of a violation of the last
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
3.2.4 Pause-At-Body
A callout server MAY use the Pause-At-Body parameter to request a
pause in original application message body transmission before
original dataflow starts. The parameter's value is of type "offset".
The parameter specifies the start of the non-auxiliary application
message body suffix that the sender is temporary not interested in
seeing.
[headers][ body prefix | body suffix ][trailer]
<-- ? --><-- offset --><-- ? ---------------->
<-- equiv. DWP offset ->
Figure 4
When an OPES processor receives a Pause-At-Body parameter, it MUST
behave as if it has received a Want Data Paused (DWP) message with
the corresponding org-offset. Note that the latter offset is
different from the Pause-At-Body offset and is unknown until the size
of the HTTP message headers is known.
Rousskov & Stecher Expires October 21, 2004 [Page 10]
Internet-Draft HTTP adaptation with OPES April 2004
For example, if the Pause-At-Body value is zero, the OPES processor
should send a Paused My Data (DPM) message just before it sends the
first Data Use Mine (DUM) message with the response-body part in the
HTTP response profile. If the Pause-At-Body value is 300, the OPES
processor should send a DPM message after transmitting 300 OCTETs for
that application message part.
Example:
Pause-At-Body: 0
Figure 5
3.2.5 Stop-Receiving-Body
A callout server MAY use the Stop-Receiving-Body parameter to imply a
DWSR message behavior before the original dataflow starts. The
parameter's value is of type "offset". The parameter specifies an
offset into the original, non-auxiliary message body part (request-
body in request profile and response-body in response profile).
A callout service MAY send a Stop-Receiving-Body parameter with its
negotiation response if there is a fixed offset into the message body
for all transactions of a profile for which a Want Stop Receiving
Data (DWSR) message would be sent. An OPES processor MUST behave as
if it has received a DWSR message with the corresponding offset.
Note that the latter offset is different from the Stop-Receiving-Body
offset and is unknown until the size of the HTTP message headers is
known.
For example, if the Stop-Receiving-Body value is zero in an HTTP
response profile, the OPES processor should send an AME message with
result code 206 immediately after sending the response-header message
part and before starting with the response-body message part.
Example:
Stop-Receiving-Body: 0
Figure 6
3.2.6 Preservation-Interest-Body
The Preservation-Interest-Body parameter can be used to optimize data
preservation at the OPES processor. The parameter's value is of type
"size" and denominates a prefix size of the original, non-auxiliary
message body part (request-body in HTTP request profile and response-
body in response profile).
Rousskov & Stecher Expires October 21, 2004 [Page 11]
Internet-Draft HTTP adaptation with OPES April 2004
A callout service MAY send a Preservation-Interest-Body parameter
with its negotiation response if there is a fixed-size prefix of the
application message body for which a Data Preservation Interest (DPI)
message would be sent. An OPES processor MUST behave as if it
receives a DPI message with org-offset zero and org-size equal to the
value of the Preservation-Interest-Body parameter.
For example, if the Preservation-Interest-Body value is zero 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
information to optimize its data preservation behavior even before it
makes the decision to preserve data.
Example:
Preservation-Interest-Body: 0
Figure 7
3.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;
Example:
Content-Encodings: (gzip)
Figure 8
The semantics of content-coding is defined in section 3.5 of
[RFC2616].
Rousskov & Stecher Expires October 21, 2004 [Page 12]
Internet-Draft HTTP adaptation with OPES April 2004
3.2.8 Profile Negotiation Example
Example:
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
})
SG: 5
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Pause-At-Body: 30
Preservation-Interest-Body: 0
Content-Encodings: (gzip)
}
SG: 5
;
Figure 9
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 part, but is
not interested in receiving the request-body part.
The OPES processor sends at most 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
part that was not explicitly requested). Some of the response parts
may not be sent if the original message lacks them.
The callout server indicates through the Preservation-Interest-Body
parameter with size zero that it will not send any DUY messages. The
OPES processor may therefore preserve no preservation for any
transaction of this profile.
By sending a Pause-At-Body value of 30, the callout server requests a
data pause. The OPES processor sends a Paused My Data (DPM) message
immediately after sending at least 30 OCTETs of the response-body
part. Thereafter, the OPES processor waits for a Want More Data
(DWM) message from the callout service.
Rousskov & Stecher Expires October 21, 2004 [Page 13]
Internet-Draft HTTP adaptation with OPES April 2004
3.3 Application Message Start Message
A new named parameter for Application Message Start (AMS) messages is
introduced.
AM-EL: size
Figure 10
AM-EL value is the size of the request-body part in the HTTP request
profile, and is the size of the response-body part in the HTTP
response profile, before any transfer codings have been applied (or
after all transfer codings have been removed). This definition is
consistent with the HTTP entity length definition.
An OCP agent that knows the exact length of the HTTP message entity
(see 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 exact entity length is not
known, an OCP agent MUST NOT send an AM-EL parameter. Relaying
correct entity length can have significant performance advantages for
the recipient, and implementations are strongly encouraged to relay
known entity lengths. Similarly, relaying incorrect entity length
can have drastic correctness consequences for the recipient, and
implementations are urged to exercise great care when relaying entity
length.
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
Section 3.8.1).
3.4 DUM Message
A new named parameter for Data Use Mine (DUM) messages is introduced.
AM-Part: am-part
Figure 11
An OCP agent MUST send 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.
Rousskov & Stecher Expires October 21, 2004 [Page 14]
Internet-Draft HTTP adaptation with OPES April 2004
The following example shows three DUM messages containing an abridged
HTTP response message. The response-body part is fragmented and sent
within two DUM messages.
Example:
P: DUM 88 1 0
Kept: 0
AM-Part: response-header
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 51
;
P: DUM 88 1 64
Kept: 64
AM-Part: response-body
19:<html><body>This is
;
P: DUM 88 1 83
Kept: 83
AM-Part: response-body
32: a simple message.</body></html>
;
Figure 12
3.5 Selective Adaptation
The HTTP profile for OCP applies to all HTTP messages. That scope
includes HTTP messages such as 1xx (Informational) responses, POST,
CONNECT, and OPTIONS requests as well as responses with extension
status codes and requests with extension methods. Unless
specifically configured to do otherwise, an OPES processor MUST
forward all HTTP messages for adaptation at callout servers. OPES
bypass instructions, configured HTTP message handling rules, and OCP-
negotiation with a callout server are all examples of an acceptable
"specific configuration" that provides an exception to this rule.
While it may seem useless to attempt to adapt "control" messages such
as a 100 (Continue) response, skipping such messages by default may
lead to serious security flaws and interoperability problems. For
example, sensitive company information might be relayed via a
carefully crafted 100 Continue response or a malicious CONNECT
request may not get logged if OPES processor does not forward these
Rousskov & Stecher Expires October 21, 2004 [Page 15]
Internet-Draft HTTP adaptation with OPES April 2004
messages to a callout service that is supposed to handle them.
By design, OPES processor implementation cannot unilaterally decide
that an HTTP message is not worth adapting. It needs a callout
server opinion, a configuration setting, or another external
information to make the decision.
3.6 Hop-by-hop Headers
HTTP defines several hop-by-hop headers (e.g., Connection) and allows
for extension headers to be specified as hop-by-hop ones (via the
Connection header mechanism). Depending on the environment and
configuration, an OPES processor MAY forward hop-by-hop headers to
callout servers and MAY use hop-by-hop headers returned by callout
servers to build an HTTP message for the next application hop.
However, see Section 3.7 for requirements specific to the Transfer-
Encoding header.
For example, a logging or statistics collection service may want to
see hop-by-hop headers sent by the previous application hop to the
OPES processor and/or hop-by-hop headers sent by the OPES processor
to the next application hop. Another service may actually handle
HTTP logic of removing and adding hop-by-hop headers. Many services
will ignore hop-by-hop headers. This specification does not define a
mechanism for distinguishing these use cases.
3.7 Transfer Encodings
HTTP messages may use transfer encodings, a hop-by-hop encoding
feature of HTTP. Adaptations that use HTTP transfer encodings have
to 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
message bodies.
Informally, the above rule means that the agent or its environment
have to make sure that all transfer encodings are stripped from an
HTTP message body before it enters OCP scope. An agent MUST
terminate the OCP transaction if it has to send an application
message body but cannot remove all transfer encodings. Violations of
these rules 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 MUST remove the
Transfer-Encoding header before sending the header part to the
Rousskov & Stecher Expires October 21, 2004 [Page 16]
Internet-Draft HTTP adaptation with OPES April 2004
callout service. A callout server receiving a Transfer-Encoding
header MAY assume that original application data is still transfer-
encoded (and terminate the transaction). The OPES processor MUST
send a correct Transfer-Encoding header to the next HTTP recipient
independent of what header (if any) the callout server returned.
Logging and wiretapping are the examples where negotiating acceptable
transfer encodings may be worthwhile. While a callout server may not
be able to strip an encoding, it may still want to log the entire
message "as is". In most cases, however, the callout server would
not be able to meaningfully handle unknown transfer encodings.
3.8 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 and by default, the OPES processor has to validate and
eventually recalculate, add, or remove computable HTTP headers in
order to build a compliant HTTP message from an adapted application
message returned by the callout server. 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 a partially adapted HTTP message from a
callout server to the next callout server, 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.
3.8.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
has to ensure correctness of the message length indication according
to section 4.4 of [RFC2616].
Rousskov & Stecher Expires October 21, 2004 [Page 17]
Internet-Draft HTTP adaptation with OPES April 2004
Besides ensuring HTTP message correctness, good OPES processors set
up the message to optimize performance, including minimizing delivery
latency. Specifically, indicating the end of a message by closing
the HTTP connection ought to be the last resort:
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 HTTP rules prohibit a Content-Length header
to be used in transfer encoded messages.
o If AM-EL parameter or equivalent entity length information is not
available, and HTTP rules allow for chunked transfer encoding, the
OPES processor SHOULD use chunked transfer encoding. Note that
any Content-Length header has to be removed in this case.
o If the message size is not known a priori and chunked transfer
coding cannot be used, but the OPES processor can wait for the OCP
transaction to finish before forwarding the adapted HTTP message
on a persistent HTTP connection, then the processor SHOULD compute
and add a Content-Length header.
o Finally, if all optimizations are not applicable, the OPES
processor SHOULD delete any Content-Length header and forward
adapted data immediately, while indicating the message end by
closing the HTTP connection.
3.8.2 Content-MD5 Header
By default, the OPES processor MUST assume that the callout service
modifies the content in a way that the MD5 checksum of the message
body becomes invalid.
According to section 14.15 of [RFC2616], HTTP intermediaries must not
generate Content-MD5 headers. 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 detects that the HTTP message was not
modified; in this case it MAY leave the Content-MD5 header in the
message. When such detection significantly increases message
latency, deleting the Content-MD5 header may be a better option.
3.9 Examples
This is a possible OCP message flow using an HTTP request profile.
An end-user wants to access the home page of
www.restricted.example.com, through the proxy, but access is denied
Rousskov & Stecher Expires October 21, 2004 [Page 18]
Internet-Draft HTTP adaptation with OPES April 2004
by a URL blocking service running on the callout server used by the
proxy.
OCP messages from the OPES processor are marked with "P:" and OCP
messages from the callout server are marked with "S:". The OCP
connection is not closed at the end but kept open for the next OCP
transaction.
Rousskov & Stecher Expires October 21, 2004 [Page 19]
Internet-Draft HTTP adaptation with OPES April 2004
Example:
P: CS;
S: CS;
P: SGC 11 ({"31:ocp-test.example.com/url-filter"});
P: NO ({"53:http://www.iana.org/assignments/opes/ocp/http/request"})
SG: 11
;
S: NR {"53:http://www.iana.org/assignments/opes/ocp/http/request"}
SG: 11
;
P: TS 55 11;
P: AMS 55
AM-EL: 0
;
P: DUM 55 0
Kept: 0
AM-Part: request-header
235:GET http://www.restricted.example.com/ HTTP/1.1
Accept: */*
Accept-Language: de
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; Windows NT 5.0)
Host: www.restricted.example.com
Proxy-Connection: Keep-Alive
;
P: AME 55;
S: AMS 55;
S: DUM 55 0
AM-Part: response-header
76:HTTP/1.1 403 Forbidden
Content-Type: text/html
Proxy-Connection: close
;
S: DUM 55 0
AM-Part: response-body
67:<html><body>You are not allowed to
access this page.</body></html>
;
S: AME 55;
P: TE 55;
S: TE 55;
Rousskov & Stecher Expires October 21, 2004 [Page 20]
Internet-Draft HTTP adaptation with OPES April 2004
Figure 13
The next example is a language translation of a small plain text file
that gets transferred in an HTTP response. In this example, OCP
agents negotiate a profile for the whole OCP connection. The OCP
connection remains open in the end of the OCP transaction. (Note
that NO and NR messages were rendered with an extra new line to
satisfy RFC formatting requirements.)
Example:
P: CS;
S: CS;
P: NO
({"54:http://www.iana.org/assignments/opes/ocp/http/response"});
S: NR
{"54:http://www.iana.org/assignments/opes/ocp/http/response"};
P: SGC 12 ({"44:ocp-test.example.com/translate?from=EN&to=DE"});
P: TS 89 12;
P: AMS 89
AM-EL: 86
;
P: DUM 89 0
AM-Part: response-header
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 86
;
P: DUM 89 65
AM-Part: response-body
86:Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune
;
P: AME 89;
S: AMS 89
AM-EL: 78
;
P: TE 89;
S: DUM 89 0
AM-Part: response-header
65:HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 78
Rousskov & Stecher Expires October 21, 2004 [Page 21]
Internet-Draft HTTP adaptation with OPES April 2004
;
S: DUM 89 63
AM-Part: response-body
80:Ob's edler im Gemuet, die Pfeil und Schleudern
des wuetenden Geschicks erdulden
;
S: AME 89;
S: TE 89;
Figure 14
The following example shows modification of an HTML resource and
demonstrates data preservation optimization. The callout server uses
a DUY message to send back an unchanged response header part but
because it does not know the size of the altered HTML resource at the
time it sends the AMS message, the callout server omits the AM-EL
parameter; the OPES processor is responsible for adjusting the
Content-Length header.
Example:
P: CS;
S: CS;
P: SGC 10 ({"30:ocp-test.example.com/ad-filter"});
P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header,request-body)
},{"45:http://www.iana.org/assignments/opes/ocp/MIME"})
SG: 10
;
S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
Aux-Parts: (request-header)
Content-Encodings: (gzip)
}
SG: 10
;
P: TS 88 10;
P: AMS 88
AM-EL: 95
;
P: DUM 88 0
AM-Part: request-header
65:GET /opes/adsample.html HTTP/1.1
Host: www.martin-stecher.de
;
P: DUM 88 65
Rousskov & Stecher Expires October 21, 2004 [Page 22]
Internet-Draft HTTP adaptation with OPES April 2004
Kept: 65 64
AM-Part: response-header
64:HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 95
;
P: DUM 88 129
Kept: 65 90
AM-Part: response-body
26:<html>
<body>
This is my
;
S: AMS 88;
P: DUM 88 155
Kept: 65 158
AM-Part: response-body
68: new ad: <img src="my_ad.gif"
width=88 height=31>
</body>
</html>
;
S: DUY 88 65 64
S: DPI 88 129 2147483647;
P: AME 88;
S: DUM 88 0
AM-Part: response-body
52:<html>
<body>
This is my new ad:
</body>
</html>
;
S: DPI 88 129 0;
P: TE 88;
S: AME 88;
S: TE 88;
Figure 15
Rousskov & Stecher Expires October 21, 2004 [Page 23]
Internet-Draft HTTP adaptation with OPES April 2004
4. Tracing
[I-D.ietf-opes-end-comm] defines application-agnostic tracing
facilities in OPES. Compliance with this specification requires
compliance with [I-D.ietf-opes-end-comm]. 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-Via = "OPES-Via" ":" #trace-entry
trace-entry = opes-agent-id *( ";" parameter )
opes-agent-id = absoluteURI
Figure 16
An OPES System MUST add its trace entry to the OPES-System header.
Other OPES agents MUST use the OPES-Via header if they add their
tracing entries. All OPES agents MUST append their entries.
Informally, OPES-System is the only required OPES tracing header
while OPES-Via provides optional tracing details; both headers
reflect the order of trace entry additions.
If an OPES-Via header is used in the original application message, an
OPES System MUST append its entry to the OPES-Via header. Otherwise,
an OPES System MAY append its entry to the OPES-Via header. If an
OPES System is using both headers, it MUST add identical trace
entries except it MAY omit some or all trace-entry parameters from
the the OPES-Via header. Informally, the OPES System entries in the
OPES-Via header are used to delimit and group OPES-Via entries from
different OPES Systems without having a priory knowledge about OPES
System identifiers.
Note that all of these headers are defined using #list constructs
and, hence, a valid HTTP message may contain multiple trace entries
per header. OPES agents SHOULD use a single header-field rather than
using multiple equally-named fields to record a long trace. Using
multiple equally-named extension header-fields is illegal from HTTP
point of view and may not work with some of the OPES-unaware HTTP
proxies.
For example, here is an HTTP response message header after OPES
adaptations have been applied by a single OPES processor executing 10
OPES services:
Rousskov & Stecher Expires October 21, 2004 [Page 24]
Internet-Draft HTTP adaptation with OPES April 2004
Example:
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-System: http://www.cdn.example.com/opes?session=ac79a749f56
OPES-Via: http://www.cdn.example.com/opes?session=ac79a749f56,
http://www.srvcs-4u.example.com/cat/?sid=123,
http://www.srvcs-4u.example.com/cat/?sid=124,
http://www.srvcs-4u.example.com/cat/?sid=125 ; mode=A
Figure 17
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 System
software.
OPES entities 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. OPES entities MUST NOT place required
tracing entries in a message trailer.
Rousskov & Stecher Expires October 21, 2004 [Page 25]
Internet-Draft HTTP adaptation with OPES April 2004
5. 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 18
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 for bypass
requirements.
Rousskov & Stecher Expires October 21, 2004 [Page 26]
Internet-Draft HTTP adaptation with OPES April 2004
6. 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 October 21, 2004 [Page 27]
Internet-Draft HTTP adaptation with OPES April 2004
7. Security Considerations
Application-independent security considerations are documented in
application-agnostic OPES specifications. HTTP profiles do not
introduce any HTTP-specific security considerations. However, that
does not imply that HTTP adaptations are immune from security
threats.
Specific threat examples include such adaptations as rewriting the
Request-URI of an HTTP CONNECT request or removing an HTTP hop-by-hop
Upgrade header before the HTTP proxy can act on it. As with any
adaptation, the OPES agents MUST NOT perform such actions without
HTTP client or server consent.
Rousskov & Stecher Expires October 21, 2004 [Page 28]
Internet-Draft HTTP adaptation with OPES April 2004
8. IANA Considerations
The IANA registers request and response profile features
(Section 3.2) using the registration procedure outlined in the "IANA
Considerations" Section of OCP Core [I-D.ietf-opes-ocp-core]. The
corresponding "uri" parameters for the two features are:
o http://www.iana.org/assignments/opes/ocp/http/request
o http://www.iana.org/assignments/opes/ocp/http/response
Rousskov & Stecher Expires October 21, 2004 [Page 29]
Internet-Draft HTTP adaptation with OPES April 2004
9. Compliance
Compliance with OPES mechanisms is defined in corresponding
application-agnostic specifications. HTTP profiles for these
mechanisms use corresponding compliance definitions from these
specifications, as if each profile was incorporated into the
application-agnostic specification it profiles.
Rousskov & Stecher Expires October 21, 2004 [Page 30]
Internet-Draft HTTP adaptation with OPES April 2004
Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of Robert
Collins (Syncretize) and Larry Masinter (Adobe). Larry Masinter
provided an early review of this document.
Rousskov & Stecher Expires October 21, 2004 [Page 31]
Internet-Draft HTTP adaptation with OPES April 2004
Appendix B. Change Log
Internal WG revision control ID: $Id: http.xml,v 1.78 2005/04/20 04:
57:40 rousskov Exp $
version 03
* Added IANA Considerations section that was written and sent to
IESG after version 02 in a failed attempt to speed up
publication.
* Updated IANA IDs for request and response features. Slightly
reformatted examples so that updated feature IDs fit RFC line
width.
* Updated examples to use example.com URIs.
* Updated Security Considerations to address Allison Mankin's
DISCUSS.
* Updated Martin's affiliation.
* Use RFC 3978 boilerplate.
* Fixed "ho-by-hop" typo.
2004/01/14
* Polished examples rendering consistency. Use P: and S:
prefixes for all OCP messages. Do not separate messages by
empty lines. Use "Example" caption for all examples.
* Replaced German umlauts in example.
2004/01/13
* Changed Transfer-Encoding header handling rule: OPES processor
MUST delete it when it strips transfer encodings. This seems
like a much more consistent/clean approach than the old SHOULD
rule of leaving the header in. If a logging or similar service
needs virgin headers, that service would either log headers
only (and then stripping transfer encoding is not necessary) or
it will not use HTTP profiles defined here so that it can log
original transfer encodings as well.
* Removed ToDo section.
Rousskov & Stecher Expires October 21, 2004 [Page 32]
Internet-Draft HTTP adaptation with OPES April 2004
* Editorial changes.
2004/01/07
* Added second and third example.
* Changed example syntax using now P: and S: prefixes.
* OCP example section with first example
2003/12/19
* Let Pause-At-Body parameter refer to new Paused My Data (DPM)
OCP core message.
* Renamed Wont-Look-Body to Stop-Receiving-Body and changed
reference to Want Stop Receiving Data (DWSR) OCP core message.
* Renamed Wont-Send-Body to Preservation-Interest-Body, reverted
logic of size parameter and changed reference to Data
Preservation Interest (DPI) OCP core message.
2003/12/14
* Added a Selective Adaptation section to cover adaptation of 100
Continue, CONNECT, and other "unusual" HTTP messages.
* Added new requirement: an OPES processor MUST offer all non-
auxiliary original parts in NO messages. Without this
requirement, the "Selective Adaptation" section would make
little sense since vital HTTP message parts could be
selectively skipped by the processor.
* Added an introduction to the OCP section.
* Added an OPES Document Map boilerplate.
2003/12/14
* Explicitly require OCP Core familiarity for OCP HTTP Profile
understanding.
* Added Robert Collins and Larry Masinter to the Acknowledgments
section.
* Renamed "binding" to "profile" as suggested by external
reviews.
Rousskov & Stecher Expires October 21, 2004 [Page 33]
Internet-Draft HTTP adaptation with OPES April 2004
2003/11/21
* Moved profile part notes completely to the "Profile Parts"
section and changed labels of original and adapted part lists.
2003/11/18
* Re-documented OPES tracing headers. Use OPES System entries in
OPES-Via to indicate system boundaries. Note that using
multiple OPES- headers may be illegal from HTTP point of view,
but header-values may be repeated.
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
Rousskov & Stecher Expires October 21, 2004 [Page 34]
Internet-Draft HTTP adaptation with OPES April 2004
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
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"
Rousskov & Stecher Expires October 21, 2004 [Page 35]
Internet-Draft HTTP adaptation with OPES April 2004
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
* 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.
Rousskov & Stecher Expires October 21, 2004 [Page 36]
Internet-Draft HTTP adaptation with OPES April 2004
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.
head-sid12
* Initial revision.
Rousskov & Stecher Expires October 21, 2004 [Page 37]
Internet-Draft HTTP adaptation with OPES April 2004
10. References
10.1 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 entities and end points communication",
draft-ietf-opes-end-comm-06 (work in progress),
December 2003.
[I-D.ietf-opes-ocp-core]
Rousskov, A., "OPES Callout Protocol Core",
draft-ietf-opes-ocp-core-04 (work in progress),
December 2003.
10.2 Informative References
[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.
[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-threats]
Barbir, A., "Security Threats and Risks for Open",
draft-ietf-opes-threats-03 (work in progress),
December 2003.
[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-opes-authorization]
Batuner, O., Beck, A., Chan, T., Orman, H., and A. Barbir,
"Policy, Authorization and Enforcement Requirements of
OPES", draft-ietf-opes-authorization-03 (work in
progress), April 2004.
[I-D.ietf-opes-rules-p]
Beck, A. and A. Rousskov, "P: Message Processing
Rousskov & Stecher Expires October 21, 2004 [Page 38]
Internet-Draft HTTP adaptation with OPES April 2004
Language", draft-ietf-opes-rules-p-02 (work in progress),
October 2003.
[I-D.ietf-opes-iab]
Barbir, A. and A. Rousskov, "OPES Treatment of IAB
Considerations", draft-ietf-opes-iab-05 (work in
progress), April 2004.
[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
CyberGuard Corporation
Vattmannstr. 3
Paderborn 33100
DE
Email: martin.stecher@webwasher.com
URI: http://www.webwasher.com/
Rousskov & Stecher Expires October 21, 2004 [Page 39]
Internet-Draft HTTP adaptation with OPES April 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Rousskov & Stecher Expires October 21, 2004 [Page 40]