[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 RFC 4236

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/