Network Working Group                                          A. Barbir
Internet-Draft                                           Nortel Networks
Expires: March 18, April 3, 2004                               September 18,                                   October 4, 2003

              OPES processor and end points communications
                      draft-ietf-opes-end-comm-02
                      draft-ietf-opes-end-comm-03

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 March 18, April 3, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   This memo documents tracing and non-blocking requirements for Open
   Pluggable Edge Services (OPES).

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  OPES Domain and OPES System  . . . . . . . . . . . . . . . .  4
   3.    OPES Tracing . . . . . . . . .  4
   3.  Requirements for OPES Tracing  . . . . . . . . . . . . . . . .  6  5
   3.1 What is traceable in an OPES Flow? . . . . . . . . . . . . .  6 .  5
   3.2 Requirements for Information Related to Traceable
         Entities?  . . . . . . . . . . . . . . . . . . . . . . . Entities . .  7
   4.  6
   3.3 Requirements for OPES processors . . . . . . . . . . . . . .  8
   5. .  7
   3.4 Requirements for callout servers . . . . . . . . . . . . . .  9
   6.    Privacy considerations . . . . . . . . . . . . . . . . . . . 10
   6.1   Tracing and Trust Domains  . . . . . . . . . . . . . . . . . 10
   7.    How to Support Tracing  7
   3.5 Protocol Binding . . . . . . . . . . . . . . . . . . . 11
   7.1   Tracing and OPES System Granularity . . . .  8
   4.  Non-Blocking . . . . . . . . 11
   7.2   Requirements for In-Band Tracing . . . . . . . . . . . . . . 12
   7.2.1 Tracing Information Granularity and Persistence levels
         Requirements . . .  9
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.3   Protocol Binding . . .
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.    Tracing Examples . . . . . . . . . . . .
       Normative References . . . . . . . . . . 14
   8.1   Single OPES Processor: Detailed Trace . . . . . . . . . . . 14
   8.2   Single OPES Processor: Partial Trace . . . .
       Informative References . . . . . . . . 15
   8.3   Multiple OPES Processors: Full Trace . . . . . . . . . . . . 15
   8.4   Multiple OPES Processors: Partial Trace  . . . . . . . . . . 16
   9.    Optional Notification  . . . . . . . . . . . . . . . . . . . 18
   10.   IANA considerations  . . . . . . . . . . . . . . . . . . . . 20
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 21
         Normative References . . . .
       Author's Address . . . . . . . . . . . . . . . . 22
         Informative References . . . . . . . 15
   A.  Acknowledgements . . . . . . . . . . . . 23
         Author's Address . . . . . . . . . . . 16
       Intellectual Property and Copyright Statements . . . . . . . . . . . 23
   A.    Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
         Intellectual Property and Copyright Statements . . . . . . . 25 17

1. Introduction

   The Open Pluggable Edge Services (OPES) architecture [8] enables
   cooperative application services (OPES services) between a data
   provider, a data consumer, and zero or more OPES processors.  The
   application services under consideration analyze and possibly
   transform application-level messages exchanged between the data
   provider and the data consumer.

   The execution of such services is governed by a set of rules
   installed on the OPES processor.  The rules enforcement can trigger
   the execution of service applications local to the OPES processor.
   Alternatively, the OPES processor can distribute the responsibility
   of service execution by communicating and collaborating with one or
   more remote callout servers. As described in [8], an OPES processor
   communicates with and invokes services on a callout server by using a
   callout protocol.

   The

   This work specify the requirements for providing tracing
   functionality for the OPES architecture [8]. This document specifies tracing
   mechanisms that the OPES architecture could provide that enable Tracing functionality
   enables a data provider application to detect inappropriate client centric actions
   that are performed by OPES entities. The work focus on developing tracing also develops
   requirements that can be used to fulfill the notification IAB Notification and
   Non-Blocking requirements [2].

   In the OPES

   The architecture document [8], there is a requirement of
   relaying requires [8] that tracing information be supported
   in-band. This work investigates this
   possibility and discusses possible methods design goal limits the type of application protocols
   that could be used to
   detect faulty OPES processors or callout servers by end points in an OPES flow. can support. The document details of what a trace record can convey
   is organized as follows: Section 2 defines also dependent on the choice of the application level protocol.

   For these reasons, this work documents requirements for application
   protocols that need to support OPES Domain traces and non-blocking. However,
   the architecture does not prevent implementers of developing
   out-of-band protocols and techniques to address these limitation.

2. OPES System

   This sections provides a definition of OPES System. Section 3 discusses entities that are This is needed in
   order to define what is traceable in an OPES Flow. Sections 4 and 5 discuss tracing requirements for OPES
   systems and callout servers. Section 6 focus on Tracing and Trust
   Domains. Section 7 discusses how to support tracing and provides uses
   cases. Section 8 provides some examples of traces. Section 9 examines
   Optional Notification.  Section 9 looks into IANA considerations.
   Section 10 examines security considerations.

2. OPES Domain and

   Definition: An OPES System

   This sections clarifies the terms OPES system and OPES Domain [8].
   These terms are needed in order to define what is traceable in an
   OPES Flow [8].

   An OPES domain describes the collection of OPES entities that a
   single provider operates. OPES domains can be based on trust or other
   operational boundaries. All entities of an "OPES Domain" MUST be in
   the same trust domain. This would be independent of any specific OPES
   Flow.

   An OPES system consists of a limited set of all OPES entities, parts of a
   single or of multiple OPES domains, organized entities authorized
   by (or on behalf) of either a the data provider application or a the data consumer application to
   perform authorized services on
   process a given application message. Each OPES
   entity

   The nature of the authorization agreement determines if authority
   delegation is transitive (meaning an authorized entities is
   authorized to include other entities). Transitive authority
   delegation is common in information systems.

   If specific authority agreements allow for re-delegation, an OPES
   system MUST be directly addressable at the IP level
   by a data consumer application.

   An OPES system can be formed in a recursive manner. An by induction. In this case, an OPES system
   can start
   starts with either entities directly authorized by a data provider application or (or a
   data consumer
   application (for a given message). consumer) application. The OPES system then includes any OPES
   entity trusted authorized by (accepting authority from) an entity that is already in the OPES system.
   The trust and authority delegation is always viewed in the context of the a given
   application message.

   As implied by the above definition, some

   An OPES entities System is defined on an application message basis. Having an
   authority to process a message does not imply being involved in the
   message processing. Thus, some OPES system
   MAY members may not
   participate in the processing of a given message.

   An OPES domain MUST not Similarly, some members may
   process the same message several times.

   The above definition implies that there can be an OPES sub-system. An OPES domain MUST
   require external resources to provide services. An no more than one OPES domain is
   system processing a
   part of an OPES system belonging to single message at a given operator. OPES domains
   have no incidence time. This is based on
   the structure of an OPES system, but they may
   influence its organization for different reasons such as security,
   payment, quality of service, delivery parameters among others.

   In Figure 1 an OPES Flow is shown assumption that traverses across various OPES
   Domains starting from there is a single data provider application. A and a single data
   consumer as far as a given application MUST be able to receive tracing information on per message basis that enable it to determine the set of transformations
   that were performed on the data for is concerned.

   For example, consider a particular OPES Flow. The
   formation of Content Delivery Network (CDN) delivering an OPES Flow can be static or dynamic, meaning that the
   determination
   image on behalf of which OPES Domains will participate in a given busy web site. OPES
   Flow (per processors and services that
   the CDN uses to adapt and deliver the message basis) can be comprise an OPES
   system. In a function of business arrangements.

               +------------------------------------------+
               |             Data Consumer Application    |
               +------------------------------------------+
                                                     ^
                                                     |
               +-------------------------------------------+
               | more complex example, an OPES System          | O   |
               |                                     |     |
               |     +-------------------------+     | P   |
               |     |        OPES Domain      |     |     |
               |     |      +---------------+  |     | E   |
               |     |      | OPES Entity   |  |     |     |
               |     |      +---------------+  |     | S   |
               |     |           .             |     |     |
               |     |           .             |     |     |
               |     |      +---------------+  |     | F   |
               |     |      |Callout Server |  |     |     |
               |     |      +---------------+  |     | L   |
               |     |                         |     |     |
               |     +-------------------------+     | O   |
               |                   .                 |     |
               |                   .                 | W   |
               |     +-------------------------+     |     |
               |     |        OPES Domain      |     |     |
               |     |      +---------------+  |     |     |
               |     |      | OPES Entity   |  |     |     |
               |     |      +---------------+  |     |     |
               |     |           .             |     |     |
               |     |           .             |     |     |
               |     |      +---------------+  |     |     |
               |     |      | OPES Entity   |  |     |     |
               |     |      +---------------+  |     |     |
               |     +-------------------------+     |     |
               |                                     v     |
               |    +-----------------------------------+  |
               |    |   Data Provider Application       |  |
               |    +-----------------------------------+  |
               |                                           |
               +-------------------------------------------+

                         Figure 1: would contain CDN
   entries as well as 3rd-party OPES System entities that CDN engages to
   perform adaptations (e.g., to adjust image quality).

3. Requirements for OPES Tracing

   Before discussing what is traceable in

   In an OPES flow, it is beneficial
   to define what System tracing means. Tracing is defined as the inclusion of necessary
   information within a message in an OPES flow Flow that could be
   used to identify the set of
   transformations or adaptations that have been performed on its content in an OPES System it before
   its delivery to an end point (for example, the data consumer
   application).

   o An OPES trace: application message trace represents a snap shot of the tracing
   information about OPES entities in
      an OPES System that adapted that have been added to a given application message.

   o  OPES tracing: the process of including, manipulating, and
      interpreting an OPES trace in

   In an OPES System.

   To emphasize, the above definition means that OPES System tracing SHOULD be is performed on per message basis. Trace
   format is dependent on the application protocol that is being adapted
   by OPES. A Data consumer application can use OPES trace to infer the
   actions that have been performed by the OPES system.  The architecture document requires [8]  Actions are the
   set of authorized OPES services that tracing be supported in-band.

   In were performed by OPES entities
   in an OPES System the task of providing System.

   Providing tracing information, must MUST take into account the following
   considerations:

   o  Providers may be hesitant to reveal information about their
      internal network infrastructure.

   o  Within a service provider network, OPES processors may be
      configured to use non-routable, private IP addresses.

   o  A Data consumer applications would prefer to have a single point
      of contact regarding the trace information.

3.1 What is traceable in an OPES Flow?

   This section focuses on identifying the traceable entities in an OPES
   Flow.

   Tracing information MUST be able to provide provides a data consumer application (or a data
   provider application) with useful information without tracing the
   exact OPES Processor or callout servers that adapted the data. It is up to the For
   example, some OPES services are message-agnostic and operate on
   message content or parts of a message. Such services cannot
   manipulate message headers. Hence, a data consumer application would
   be interested in knowing that a translation service on the message
   content was performed. It does not need to know the exact entity that
   has performed the service.

   There are two distinct uses of OPES traces. First, a trace enables an
   "end (content provider or consumer) to have maintained appropriate internal
   detailed traces detect the presence of OPES
   processors within an OPES System. Such "end" should be able to see a
   trace entry, but does not need to be able to find interpret it beyond
   identification of the OPES System.

   Second, the answer OPES System administrator is expected to be able to
   interpret the data contents of an OPES trace. The trace can be provided by
   an end (data consumer applications
   inquiry. or provider) as an opaque string. The
   administrator can use the trace information to identify the
   participating OPES processor(s). The administrator can use the trace
   to identify the applied adaptation services along with other
   message-specific information.

   Since the administrators of various OPES Systems can have various
   ways of looking into tracing, they MAY require the choice of freedom
   in what to put in trace records and how to format them. Trace records
   should be easy to extend beyond basic OPES requirements. Trace
   management algorithms should treat trace records as opaque data to
   the extent possible.

   At the implementation level, for a given trace, an OPES entity
   involved in handling the corresponding application message is
   "traceable"
   traceable or "traced" traced if information about it appears in that  trace.
   OPES entities have different levels of traceability requirements.
   Specifically,

   o  An OPES system MUST add its entry to the trace.

   o  An OPES processor SHOULD add its entry to the trace.

   o  An OPES service SHOULD May add its entry to the trace.

   o  An OPES entity MAY manage trace information from entities that are
      under its control. For example, an OPES processor may add or
      remove callout service entries in order to manage the size of a
      trace. Other considerations include:

      *  The

   From an OPES processor MAY have context, a fixed configuration that enable
         it good tracing approach is similar to respond a trouble
   ticket ready for submission to tracing inquires.

      *  The OPES processor MAY insert a summary of the services that it
         controls. The summary can be used to respond to tracing
         inquiries.

      * known address. The OPES processor MAY package tracing information related to
         the entities that it control based address is
   printed on the policy of a given
         OPES System.

   From an OPES context, a good tracing approach is similar to a trouble
   ticket ready for submission to a known address. ticket. The trace in itself is not necessarily a
   detailed description of what has happened. It is the responsibility
   of the operator to resolve the problems.

3.2 Requirements for Information Related to Traceable Entities? Entities

   The following MUST requirements apply for information as related to
   entities that are traceable in an OPES flow are: flow:

   o  The  Identification of the OPES System privacy policy at the time it
      dealt with the message message.

   o  Identification of the party responsible for setting and enforcing
      that policy policy.

   o  Information pointing to a technical contact contact.

   o  Information that identifies, to the technical contact, the OPES
      processors involved in processing the message.

4.

3.3 Requirements for OPES processors

   In order to facilitate compliance, the concept of an "OPES system"
   being traceable, requires that each OPES processor MUST support
   tracing.  Policy can be set that defines which domain has
   authorization to turn on tracing and its granularity.  An OPES
   provider can have its private policy for trace information, but it
   MUST support tracing mechanisms and it MUST reveal its policy.

   The requirements for OPES processors that are applicable to tracing
   are:

   o  Each OPES processor MUST belong to a single OPES Domain.

   o  Each OPES processor MUST have a Unique Identity be uniquely identified in that Domain. an OPES System.

   o  Each OPES processor MUST support tracing, policy can be used to
      turn tracing on and to determine its granularity.

5. Requirements for callout servers

   In an OPES system, it

   o  If tracing is turned on, then the task of an OPES processor to add trace
   records to application messages. In this case, the callout servers
   that uses the OCP protocol [5] are not affected by tracing
   requirements. In order for an OCP protocol to be tracing neutral, an OPES processor in an OPES system MUST be able add its
      identification to meet the following
   requirements:

   o  Callout services adapt payload regardless of the application
      protocol in use and leave header adjustment to OPES processor. trace.

   o  OPES processor SHOULD be able  to trace it's own invocation and
      service(s) execution since they understand it understands the application
      protocol.

   o  Callout servers To fulfill this:

      *  An OPES processor MAY be able have a fixed configuration that enable it
         to add their own OPES trace records respond to application level messages.

6. Privacy considerations

6.1 Tracing and Trust Domains

   A trust domain may include several OPES systems and entities. Within
   a trust domain, there MUST be at least support for one trace entry
   per OPES system. Entities outside of that system may or may not see
   any traces, depending on domain policies or configuration. tracing inquires. For example, if an OPES system is on the content provider "side",
   end-users are not guaranteed any traces. If an entity X performs
         service Y and so on.

      *  An OPES system is working
   inside end-user domain, the origin server is not guaranteed any
   traces processor MAY package tracing information related to user requests.

7. How to Support Tracing

   In order to support tracing,
         the following aspects must be addressed:

   o  There MUST be a System Identifier entities that identify it control based on the policy of a domain that is
      employing an given
         OPES system.

   o  An System. For example, the trace may state that service W
         was performed. The OPES processor MUST be able to be uniquely identified (MUST
      have an Identifier) within knows that service W is
         composed of services X, Y and Z in a system.

   o  An OPES processor SHOULD add its identification to the trace. given order

   o  An OPES processor SHOULD add to the trace identification of every
      callout service that received processed the application message.

   o  If the policy in an OPES system requires an OPES processor to turn
      tracing on, then the OPES processor MUST add to the trace
      identification of the "system or entity" it belongs to. "System"
      ID MUST make it possible to access "system" privacy policy.

   o  An OPES processor MAY group the above information for sequential
      trace entries having  the same "system/entity" ID. In other words,
      trace  entries produced within the same "system or entity"  MAY be
      merged or aggregated into a single less detailed trace entry.

   o  An OPES processor MAY delegate trace management to  a callout
      service within the same "system or entity".

7.1 Tracing and OPES System Granularity

   There are two distinct uses of traces. First, a trace SHOULD enable System.

3.4 Requirements for callout servers

   In an OPES system, it is the "end (content producer or consumer) to detect task of an OPES processor
   presence within end's trust domain. Such "end" should be able to see
   a trace entry, but does not need to be able to interpret it beyond
   identification of the trust domain(s).

   Second, the domain administrator SHOULD be able to take a trace entry
   (possibly supplied by an "end? as an opaque string) and interpret it.
   The administrator must be able to identify OPES processor(s) involved
   and may be able to identify applied adaptation services along with
   other message-specific information. That information SHOULD help to
   explain what OPES entities were involved and the actions that they
   performed. It may be impractical to provide all the required
   information in all cases. This document view a trace record as a
   hint, as opposed to an exhaustive audit.

   Since the administrators of various trust domains can have various
   ways of looking into tracing, they MAY require the choice of freedom
   in what to put in trace records and how to format them. Trace records
   should be easy to extend beyond basic OPES requirements. Trace
   management algorithms should treat add trace
   records as opaque data to
   the extent possible.

   It is not expected that entities in one trust domain to be able to
   get all OPES-related feedback from entities in other trust domains.
   For example, if an end-user suspects that a service was corrupted by
   a callout service, then, there is no guarantee that the user will be
   able to identify that service, contact its owner, or debug it, unless
   the service is within its trust domain. This is no different from the
   current situation where it is impossible, in general, to know the
   contact person for an application on an origin server that generates
   corrupted HTML; and even if the person is known, one should not
   expect that person to respond to end-user queries.

7.2 Requirements for In-Band Tracing

   The OPES architecture [8] states that traces must be in-band. The
   support of this design goal is dependent on the specifics of the
   message application level protocol that is being used in an OPES
   flow. In-band tracing limits the type of application protocols that
   OPES can support. The details of what a trace record can convey is
   also dependent on the choice of the application level protocol.

   For these reasons, this work documents requirements for application
   protocols that need to support OPES traces. messages. However, the architecture
   does not prevent implementers of developing out-of-band protocols and
   techniques to address the above limitation.

7.2.1 Tracing Information Granularity and Persistence levels
      Requirements

   In order to be able to trace entities that have acted on an
   application message in an OPES flow, there may be requirements to
   keep information that is related to the following:

   o  Message-related information: All data that describes specific
      actions performed on the message SHOULD be provided with that
      message, as there is no other way to find message level details at
      a later stage.

   o  Session related information: Session level data MUST some cases, callout
   servers May add trace information to application messages. This
   should be preserved
      for done under the duration control of the session. OPES processor is responsible for
      inserting notifications if session-level information changes.

   o  End-point related data: What profile is activated? Where to get
      profile details? Where to set preferences?

7.3 System provider.

3.5 Protocol Binding

   The task of adding tracing information is application protocol
   specific. Separate documents will address HTTP and other protocols.
   This work documents what tracing information is required and some
   common tracing elements.

8. Tracing Examples

   This section provides some examples

4. Non-Blocking

   In [9] recommendation addresses the issue of tracing that could be
   generated by non-blocking in an OPES
   System. The examples are based recommendation is restated below for ease of reference.

      (3.3) Non-blocking: If there exists a non-OPES version of content
      available from the content provider, the OPES architecture must
      not prevent users from retrieving this non-OPES version from the
      content provider.

   The IAB recommendation implies that it is up to the content provider
   to make non-OPES versions of a given content available. The actual
   meaning of non-OPES version of the content depended on HTTP [3] the agreement
   between the OPES provider and
   use HTTP extension headers the content provider. The agreement can
   allow OPES to perform some services (such as given in [6]. In [6] trace entries are
   supplied using HTTP extension message headers. These headers are
   defined using #list constructs. logging services) and
   prevent it from performing other services (such as data to audio
   transformation).

   Whether an OPES System honor a non-blocking request from a data
   consumer application (user) can also be a function of deployment.
   Consider the case where Company A valid HTTP message may contain
   multiple entries has as contract with an OPES
   provider to perform virus checking on all e-mail attachments. An
   employee X of each header. Company A can issue a non-blocking request for the
   virus scanning service. However, the request could be ignored by the
   OPES provider since it contradicts its agreement with Company A.  As
   a second example, a user may issue a non-blocking request for adult
   content, this request may be declined by the OPES provider simply
   because it contradicts its internal policy or its agreement with the
   end subscriber.

   In some cases, a data consumer application will issue a non-blocking
   request since it suspects that the OPES System is corrupting the
   data. For example, an OPES Systems, these headers
   MUST entity has determined that a Virus is
   present in an attachment, while the user is aware that some versions
   of virus scanners will make that mistake. In this case, the user can
   use the non-blocking technique (can be used in combination with the
   tracing facility) to represent solve the trace entries.

   In [6], problem. However, whether the following HTTP extensions are defined:

      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

8.1 Single OPES Processor: Detailed Trace

   This example consider
   System will honor the case non-blocking request or not is still a function
   of the deployment scenario, content availability and related
   policies.

   Like tracing, Non-blocking operates on per application message bases.
   Non-Blocking is an OPES System consisting of end-end operation as opposed to a
   single OPES Processor that is capable hop-by-hop
   operation. Non-blocking requests are generally client centric and go
   in the opposite direction of  locally performing three
   OPES services. A data consumer tracing requests. Non-blocking can be
   performed out of band or in-band. This work requires non-blocking to
   be performed in-band as an extension to an application may receive specific
   protocol. Non-OPES entities should be able to safely ignore the following
   HTTP response message header after
   extensions. The work does not prevent OPES adaptations have been
   applied:

      HTTP/1.1 200 OK

      Date: Wed, 15 Nov 1995 06:25:24 GMT

      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

      Content-type: application/octet-stream

      OPES-System: http://www.example-opes-systemA.com/
      opes?session=ac79a7901549f56

      OPES-Service: http:// www.example-opes-systemA.com /?sid=123

      OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=124

      OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=125
   In this example, the trace has identified Systems from developing
   their own out of band protocols.

   Non-blocking format is dependent on the application protocol that is
   being adapted by OPES. For a given application protocol, in an OPES
   System and all the
   OPES there can be services that were performed operate on the data consumer application
   original request.

8.2 Single OPES Processor: Partial Trace

   In this example, the OPES System consisting message
   headers and those that just operate on content. This mix of a two service
   requires that an OPES Processor.
   Each Processor processor that is capable of locally performing many OPES services. A
   data consumer application may receive calling the following HTTP response
   message header after OPES adaptations have been applied:

      HTTP/1.1 200 OK

      Date: Wed, 15 Nov 1995 06:25:24 GMT

      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

      Content-type: application/octet-stream

      OPES-System: http://www.example-opes-systemA.com/
      opes?session=ac79a7901549f56

      OPES-Service: http:// www.example-opes-systemA.com /?sid=123

      OPES-Service: http:// www.example-opes-systemA.com /cat/?sid=124 ;
      Mode = Aggregate

   In this example, several OPES services may be performed on service(s) to
   handle the non-blocking request. However, In some cases, the trace has one entry first OPES
   processor that fully identifies one
   service and will get the other services are identified through a common ID.
   The OPES system is expected to non-blocking request may not be able to detail the other services
   when queried by the data consumer application.

8.3 Multiple first
   OPES Processors: Full Trace

   In this example, processor that will know whether a non-OPES version of the
   content is available or not.

   In an OPES System consisting of a two System, the OPES Processors.
   Each processor provider is capable of locally performing two expected to configure at
   least one OPES services. A
   data consumer application may receive the following HTTP response
   message processor to process a non-blocking header after OPES adaptations have been applied:

      HTTP/1.1 200 OK

      Date: Wed, 15 Nov 1995 06:25:24 GMT

      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

      Content-type: application/octet-stream
      OPES-System: http://www.example-opes-systemA.com/
      opes?session=ac79a7901549f56

      OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
      ?sid=123

      OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
      ?sid=124

      OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
      ?sid=111

      OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
      ?sid=112 based on
   content availability and related policies. In this example, the trace has identified case the OPES System and all
   processor is expected to determine the
   OPES set of services that were performed on will be
   bypassed (or those services that will be performed) or whether the
   request should be forwarded directly to the data consumer provider application
   original request.

8.4 Multiple
   (origin content provider).

   Although, IAB recommendation (3.3) has intended for non-blocking
   approach to be used as a vehicle to bypass faulty OPES Processors: Partial Trace

   In
   intermediaries. However, this example, work recognizes that the OPES System consisting of same technique
   can be used to enable a two OPES Processors.
   Each processor is capable of locally performing several OPES
   services. A data consumer application may receive to select the following HTTP
   response message header after OPES adaptations have been applied:

      HTTP/1.1 200 OK

      Date: Wed, 15 Nov 1995 06:25:24 GMT

      Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT

      Content-type: application/octet-stream

      OPES-System: http://www.example-opes-systemA.com/
      opes?session=ac79a7901549f56

      OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
      ?sid=123

      OPES-Service: http:// www.example-opes-Service-Provider1.com /cat/
      ?sid=124 ; Mode A

      OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
      ?sid=111

      OPES-Service: http:// www.example-opes-Service-Provider2.com /xxx/
      ?sid=112 ; Mode B
   In this example, several OPES set
   of services may that it would like to be performed on the
   request. However, the trace partially indicates the services bypassed for a given application
   message. For this reason, a non-blocking request is viewed as a
   bypass instruction that
   were performed. The contains a URI that identifies an OPES system is expected entity
   or a group of OPES entities that perform a service (or services) to
   be able bypassed. An instruction may contain more than one such URI. A
   special wildcard identifier can be used to detail the
   other services when queried by the data consumer application.

9. Optional Notification

   This section examines IAB [2] considerations (3.1) and (3.2)
   regarding notification in an represent all possible
   URIs (i.e., all possible OPES architecture.

   Notification propagates in opposite direction services). This version of tracing and cannot
   be attached the work
   requires that all non-blocking instructions to use the wildcard
   approach.

   For example, an application messages that it notifies about.
   Notification level protocol (such as HTTP) can be done out-band and may require
   extended to include the development of
   a new protocol. following OPES non-blocking related header:

      OPES-Bypass: *

   The direction of data flow following requirements apply for tracing and
   notification are depicted in Figure 2.

                                      Notification
                +-----------------------------------------------
                |                                               |
                |                                               V
          +---------------+            +-------+       +---------------+
          |               |            |       |       | Data Provider |
          | Data Consumer | Tracing    | non-blocking feature:

   o  An OPES  |<----->|  Application  |
          |  Application  |<-----------|       |       +---------------+
          +---------------+            +-------+
                                           ^
                                           |OCP
                                           |
                                           V
                                       +---------+
                                       | Callout |
                                       | Server  |
                                       +---------+

                      Figure 2: Notification Flow

   In [9] it was argued that Notification is an expensive approach for
   providing tracing information. However, System MUST support the current work does not
   prevent an non-blocking feature for requests
      of non-OPES content for a given application message.

   o  An OPES System from publishing policy and specifications MUST treat the non-blocking feature as an
      end-to-end operation.

      *  This means that
   allow Optional Notification. For example, there MUST be at least one OPES processor in an
         OPES System can adopt a
   mechanism that uses a flag that would allow a data consumer knows how to interpret and a
   data provider application process the
         non-blocking feature.

      *  The recipient MUST forward the bypass instructions to signal the next
         application hop provided that the next hop speaks application
         protocol with OPES bypass support.

      *  This requirement applies to each other all bypass instructions, including
         those that they are
   interested identify known-to-recipient entities.

   o  Application-specific bindings MUST map the above non-blocking
      mechanism to receive an explicit notification their application protocol.

   End users may not be able to know if an their non-blocking request was
   honored or not by the OPES service is
   applied to a specific message. The value of System. In this optional flag/field
   can be a URI that identifies notification method plus parameters. If
   a processor understands the method, case, it would be able
   beneficial if tracing can provide additional information regarding
   whether a non-blocking request was honored or not. For this reason,
   the following requirement also apply to further
   decode the field and send a notification. The specification of tracing facility:

   o  An OPES System SHOULD assist the
   field name and format for an data consumer application protocol can be stated in
      determining if a non-blocking request was performed by the associated binding document. The details of the notification
   protocol system.

   Assistance is beyond viewed as the scope addition of this document.

   For example, the following HTTP header:

      OPES-Notify: URI *(pname=pvalue)

   Or,

      My-OPES-Notify: foo=bar q=0.5

   can information about services
   that were skipped and those that could not be used.

10. bypassed.

5. IANA considerations

   This work does not require any IANA consideration since any actions
   will be addressed in [6].

11.

6. Security Considerations

   The security considerations for OPES are documented in [7]. This
   document is a requirement document for tracing and non-blocking and
   as such does not develop any new protocols that require security
   considerations.

Normative References

   [1]  A. Barbir et al., "OPES Use Cases and Deployment Scenarios",
        Internet-Draft http://www.ietf.org/internet-drafts/
        draft-ietf-opes-scenarios-01.txt, Auguest August 2002.

   [2]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
        Considerations for Open Pluggable Edge Services", RFC 3238,
        January 2002.

   [3]  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.

   [4]  A. Barbir et al., "Policy, Authorization and Enforcement
        Requirements of OPES", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-authorization-02.txt, February
        2003.

   [5]  Rousskov, A., "OPES Callout Protocol Core", Internet-Draft
        http://www.ietf.org/internet-drafts/
        draft-ietf-opes-ocp-core-01.txt, August  2003.

   [6]  Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
        September 2003.

   [7]  A. Barbir et al., "Security Threats and Risks for Open Pluggable
        Edge Services", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-threats-02.txt, February 2003.

   [8]  A. Barbir et al., "An Architecture for Open Pluggable Edge
        Services (OPES)", Internet-Draft http://www.ietf.org/
        internet-drafts/draft-ietf-opes-architecture-04, December  2002.

   [9]  A. Barbir et al., "OPES Treatment of IAB Considerations",
        Internet-Draft http://www.ietf.org/internet-drafts/
        draft-ietf-opes-iab-01.txt, February  2004.

Informative References

   [10]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
         Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
         Waldbusser, "Terminology for Policy-Based Management", RFC
         3198, November 2001.

   [11]  L. Cranor,  et. al, "The Platform for Privacy Preferences 1.0
         (P3P1.0) Specification", W3C Recommendation 16 http://
         www.w3.org/TR/2002/REC-P3P-20020416/ , April  2002.

Author's Address

   Abbie Barbir
   Nortel Networks
   3500 Carling Avenue
   Nepean, Ontario  K2H 8E9
   Canada

   Phone: +1 613 763 5229
   EMail: abbieb@nortelnetworks.com

Appendix A. Acknowledgements

   Several people has contributed to this work. Many thanks to: Alex
   Rousskov, Hilarie Orman, Oscar Batuner, Markus Huffman, Martin
   Stecher, Marshall Rose and Reinaldo Penno.

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
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.