HTTP adaptation with OPES

Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing and bypass [XXX] or OPES callout protocol [XXX]. This document binds those mechanisms to a specific application protocol, HTTP [XXX]. 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 to the corresponding application-agnostic mechanisms documented elsewhere.

(XXX: document OPES-Trace HTTP extension-header)

(XXX: document OPES-Bypass HTTP extension-header)

Two HTTP profiles are defined for OCP, depending on the original and adapted parts exchanged between OCP agents. These profiles are described below. For both profiles, the feature identifier as well as original and adapted parts are documented; optional parts are marked. Note that not all original parts are meant to be adapted. The order of parts within each flow is mandatory. (XXX: but one might receive a response before a complete request is sent!) Optional parts MUST be indicated as feature parameters, i.e. they are optional in the profile feature description, but once the agents negotiated a profile with optional parts, those parts become mandantory. request-header, request-body, request-trailer request-header, request-body, request-trailer request-header (optional), request-body (optional), request-trailer (optional), response-header, response-body, response-trailer response-header, response-body, response-trailer An agent agreeing to use a given profile during negotiation MUST send, accept, and adapt corresponding application message parts for the duration of the OCP connection (the profile scope). If the agent is unable to send a part, it MUST NOT initiate the transaction or MUST abort already initiated transaction. If an agent does not receive an expected part, and the missing part has not default value, the agent MUST abort the transaction. If an agent receives an unexpected part, the agent MUST abort the transaction. Application message part expectancy is determined based on part identifier alone (and not content). Example:

Note that the line break in the NO message is for rendering purpose in this document only; the real message MUST NOT have that line break. The OPES processor offers two profile features, both specify HTTP responses; the first profile includes the standard parts only, the second profile includes also the HTTP request header part. The callout server selects the profile with the additional HTTP request information. The application message sent by the OPES processor will then contain the parts request-header, response-header, response-body, response-trailer (in this order) and the callout server will respond with the parts response-header, response-body, response-trailer.

(XXX: document HTTP message body encoding feature)

(XXX: document HTTP-specific values of AM-Part: named-parameter of Data Use Mine (DUM) OCP message)

OPES treatment of IETF Internet Architecture Board (IAB) considerations are documented in [XXX].

Application-independent security considerations are documented in application-agnostic OPES specifications. HTTP binding does not introduce any HTTP-specific security considerations (XXX: really?).

Compliance with OPES mechanisms is defined in corresponding application-agnostic specifications. HTTP-specific bindings for those mechanisms use corresponding compliance definitions from those specifications, as if each binding was incorporated into the application-agnostic specification it binds to.

Fix all XXXs.

Special thanks to Marshall Rose for his xml2rfc tool. Internal WG revision control ID: $Id: http.xml,v 1.15 2003/07/14 20:13:59 rousskov Exp $ Removed HTTP-transaction profile, added optional parts as feature parameters, added example. Initial revision.