OPES
Click on the red underlined text to get to the source
...
The Open Pluggable Edge Services (OPES) framework documents several
application-agnostic mechanisms ...
... framework documents several
application-agnostic mechanisms such as OPES processor and endpoints
communications [RFC3897 ...
... endpoints
communications [RFC3897] or OPES callout protocol [RFC4037]. This
document extends those generic mechanisms for adaptation of a
...
... RFC2616]. Together,
application-agnostic OPES documents and this HTTP profile constitute
a complete specification for HTTP ...
... HTTP profile constitute
a complete specification for HTTP adaptation with OPES.
The primary sections of this document specify HTTP ...
... OPES Document Map ...
... OPES specifications produced
by the IETF OPES Working Group. Familiarity with the overall OPES
...
... IETF OPES Working Group. Familiarity with the overall OPES
approach and typical scenarios is often essential when trying to
comprehend isolated OPES documents ...
... 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"
...
... comprehend isolated OPES documents. This section provides an index
of OPES documents to assist the reader with finding "missing"
information.
...
... RFC3752] 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 ...
... considered in scope for OPES and have been used as a motivation
and guidance in designing the OPES architecture.
...
... architecture.
o The OPES architecture and common terminology are described in "An
Architecture ...
... o "Policy, Authorization and Enforcement Requirements of OPES"
[RFC3838] outlines requirements ...
... Security Threats and Risks for OPES" [RFC3837] provides OPES risk
analysis, without recommending specific solutions.
...
... analysis, without recommending specific solutions.
o "OPES Treatment of IAB Considerations" [RFC3914] addresses ...
... o At the core of the OPES architecture are the OPES processor and
the callout server, two network elements ...
... callout server, two network elements that communicate with
each other via an OPES Callout Protocol (OCP). The requirements
...
... requirements
for such protocol are discussed in "Requirements for OPES Callout
Protocols" [RFC3836].
...
... RFC3836].
o "OPES Callout Protocol Core" [RFC4037] specifies an application
agnostic protocol core to be used for the communication between
...
... RFC4037] specifies an application
agnostic protocol core to be used for the communication between
OPES processor and callout server.
...
... callout server.
o "OPES entities and end points communications" [RFC3897] specifies
generic tracing and bypass mechanisms ...
... OCP Core and Communications documents are independent from the
application protocol being adapted by OPES entities. Their
generic mechanisms have to be complemented by application-specific ...
... profile for HTTP. It specifies how application-
agnostic OPES mechanisms are to be used and augmented in order to
support adaptation of HTTP messages.
...
... 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 ...
... terminology, and mechanisms.
OPES processor communicates its desire to adapt HTTP messages via a
Negotiation Offer ...
... 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 ...
... 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
...
... transaction with an error.
An OPES processor MUST NOT send parts that are not listed as
"original" in the negotiated profile. A callout server ...
... circuit" the HTTP transaction, forcing the OPES
processor to return an HTTP response without forwarding an adapted
HTTP request ...
... forbidden.
Unless explicitly configured to do otherwise, an OPES processor MUST
offer all non-auxiliary original parts in Negotiation Offer (NO ...
... 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
...
... listed in the negotiation offer. In case of a violation of the last
rule, the OPES processor MUST terminate the transaction.
...
... transaction.
An OPES processor MUST send each negotiated auxiliary part to the
callout server, unless the part is absent.
...
... Figure 4
When an OPES processor receives a Pause-At-Body parameter, it MUST
behave as if it has received a Want Data Paused ...
...
For example, if the Pause-At-Body value is zero, the OPES processor
should send a Paused My Data (DPM ...
... HTTP response profile. If the Pause-At-Body value is 300, the OPES
processor should send a DPM message after transmitting 300 OCTETs for
...
... 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.
...
... Stop-Receiving-Body value is zero in an HTTP
response profile, the OPES processor should send an Application
Message End (AME) message with result code ...
... 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
...
... 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
...
... Data Use
Yours (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.
...
... Encodings listed first are
preferred to other encodings. An OPES processor MAY use any content
encoding when sending application messages to a callout server ...
... encodings does not imply lack of
support for other encodings. The OPES processor MUST NOT bypass a
service ...
... negotiation response.
The OPES processor offers one profile feature for HTTP response
messages. Besides the standard message parts, the OPES processor ...
... 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 ...
... request-body part.
The OPES processor sends at most the following message parts, in the
specified order, for all transactions in service ...
... 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 ...
... 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 ...
... 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 ...
... forward all HTTP messages for adaptation at callout servers. OPES
bypass instructions, configured HTTP message handling rules, and
OCP ...
...
carefully crafted 100 Continue response; or a malicious CONNECT
request may not get logged if OPES processor does not forward these
messages to a callout service that is supposed to handle them.
...
... 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 ...
... Connection header mechanism). Depending on the environment and
configuration, an OPES processor MAY forward hop-by-hop headers to
callout servers ...
... 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
...
... OPES processor and/or hop-by-hop headers sent by the OPES processor
to the next application hop. Another service may actually handle
...
... application data is still transfer-
encoded (and terminate the transaction). The OPES processor MUST
send a correct Transfer-Encoding header ...
...
When communicating with HTTP applications, OPES processors MUST
ensure correctness of all computable HTTP headers documented in
...
... RFC2616]).
Informally and by default, the OPES processor has to validate and
eventually recalculate, add, or remove ...
... 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,
...
... headers "as is".
An OPES processor MAY forward a partially adapted HTTP message from a
callout server ...
... Before sending the HTTP message to the HTTP peer, the OPES processor
has to ensure correctness of the message length indication according
...
...
Besides ensuring HTTP message correctness, good OPES processors set
up the message to optimize performance, including minimizing delivery ...
... AM-EL parameter with its AMS
message, the OPES processor SHOULD use this value to create a
Content-Length ...
... HTTP rules allow for chunked transfer encoding, the
OPES processor SHOULD use chunked transfer encoding. Note that
any Content-Length ...
... 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 ...
... header.
o Finally, if all optimizations are not applicable, the OPES
processor SHOULD delete any Content-Length header ...
...
By default, the OPES processor MUST assume that the callout service
modifies the content in a way that the MD5 checksum ...
... 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 ...
... OPES processor is considered authoritative for the entity
being adapted. An un-authoritative OPES processor MUST remove the
Content-MD5 ...
...
OCP messages from the OPES processor are marked with "P:" and OCP
messages from the callout server are marked with "S:". The OCP ...
... AMS message, the callout server omits the AM-EL
parameter; the OPES processor is responsible for adjusting the
Content-Length header ...
... [RFC3897] defines application-agnostic tracing facilities in OPES.
Compliance with this specification requires compliance with
[RFC3897 ...
... OPES-Via header if they add their
tracing entries. All OPES agents MUST append their entries.
Informally, OPES ...
... OPES agents MUST append their entries.
Informally, OPES-System is the only required OPES tracing header
...
... agents MUST append their entries.
Informally, OPES-System is the only required OPES tracing header
while OPES ...
... OPES tracing header
while OPES-Via provides optional tracing details; both headers
reflect the order of trace ...
... trace entry additions.
If an OPES-Via header is used in the original application message, an
OPES System ...
... OPES-Via header is used in the original application message, an
OPES System MUST append its entry to the OPES-Via header. Otherwise,
...
... header is used in the original application message, an
OPES System MUST append its entry to the OPES-Via header. Otherwise,
an OPES System ...
... OPES-Via header. Otherwise,
an OPES System MAY append its entry to the OPES-Via header. If an
...
... header. Otherwise,
an OPES System MAY append its entry to the OPES-Via header. If an
OPES System ...
... entries except it MAY omit some or all trace-entry parameters from
the OPES-Via header. Informally, the OPES System entries in the
...
... header. Informally, the OPES System entries in the
OPES-Via header are used to delimit and group OPES ...
... OPES-Via header are used to delimit and group OPES-Via entries from
different OPES Systems without having a priory knowledge about OPES
System ...
... group OPES-Via entries from
different OPES Systems without having a priory knowledge about OPES
System identifiers.
...
... OPES-Via entries from
different OPES Systems without having a priory knowledge about OPES
System identifiers.
...
... extension header-fields is illegal from HTTP's
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
...
... header after OPES
adaptations have been applied by a single OPES processor executing 10
OPES services:
...
... adaptations have been applied by a single OPES processor executing 10
OPES services:
Example:
...
... Content-type: application/octet-stream
OPES-System: http://www.cdn.example.com/opes?session=ac79a749f56
OPES ...
... 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,
...
... Figure 17
In the above example, the OPES processor has not included its trace
entry or its trace ...
... trace
entry or its trace entry was replaced by an OPES system trace entry.
Only 3 out of 10 services ...
... services did not
include their entries or their entries were removed by OPES system or
processor. The last traced service ...
... identifiers in trace entries will probably have no meaning to
the recipient of the message, but may be decoded by OPES System
software.
...
... software.
OPES entities MAY place optional tracing entries in a message trailer
(i.e., entity-headers ...
... protocol. See [RFC3897] for a definition of what tracing entries are
optional. OPES entities MUST NOT place required tracing entries in a
message trailer.
...
... An HTTP extension header is introduced to allow for OPES system
bypass as defined in [RFC3897 ...
... OPES system
bypass for the listed OPES agents. The asterisk "*" character is
used to represent all possible OPES ...
... IAB)
considerations [RFC3238] are documented in "OPES Treatment of IAB
Considerations" [RFC3914 ...
... security considerations are documented in
application-agnostic OPES specifications. HTTP profiles do not
introduce any HTTP ...
... HTTP proxy can act on it. As with any
adaptation, the OPES agents MUST NOT perform such actions without
HTTP client ...
...
Compliance with OPES mechanisms is defined in corresponding
application-agnostic specifications. HTTP profiles ...
... Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004. ...
... Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037prop ...
... Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004. ...
... Beck, A., Hofmann, M., Orman, H., Penno, R., and A. Terzis, "Requirements for Open Pluggable Edge Services (OPES) Callout Protocols", RFC 3836, August 2004. ...
... Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004. ...
... Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004. ...
... Authorization, and Enforcement Requirements of the Open Pluggable Edge Services (OPES)", RFC 3838, August 2004. ...
... Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004. ...