GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4037

Network Working Group A. Rousskov Request for Comments: 4037 The Measurement Factory Category: Standards Track March 2005

  Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document specifies the core of the Open Pluggable Edge Services
 (OPES) Callout Protocol (OCP).  OCP marshals application messages
 from other communication protocols: An OPES intermediary sends
 original application messages to a callout server; the callout server
 sends adapted application messages back to the processor.  OCP is
 designed with typical adaptation tasks in mind (e.g., virus and spam
 management, language and format translation, message anonymization,
 or advertisement manipulation).  As defined in this document, the OCP
 Core consists of application-agnostic mechanisms essential for
 efficient support of typical adaptations.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  OPES Document Map  . . . . . . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . .  6
 2.  Overall Operation  . . . . . . . . . . . . . . . . . . . . . .  7
     2.1.  Initialization . . . . . . . . . . . . . . . . . . . . .  7
     2.2.  Original Dataflow  . . . . . . . . . . . . . . . . . . .  8
     2.3.  Adapted Dataflow . . . . . . . . . . . . . . . . . . . .  8
     2.4.  Multiple Application Messages  . . . . . . . . . . . . .  9
     2.5.  Termination  . . . . . . . . . . . . . . . . . . . . . .  9
     2.6.  Message Exchange Patterns  . . . . . . . . . . . . . . .  9
     2.7.  Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.8.  Environment  . . . . . . . . . . . . . . . . . . . . . . 11
 3.  Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Rousskov Standards Track [Page 1] RFC 4037 OPES Callout Protocol Core March 2005

     3.1.  Message Format . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Message Rendering  . . . . . . . . . . . . . . . . . . . 13
     3.3.  Message Examples . . . . . . . . . . . . . . . . . . . . 14
     3.4.  Message Names  . . . . . . . . . . . . . . . . . . . . . 15
 4.  Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 15
 5.  Invalid Input  . . . . . . . . . . . . . . . . . . . . . . . . 16
 6.  Negotiation  . . . . . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  Negotiation Phase  . . . . . . . . . . . . . . . . . . . 17
     6.2.  Negotiation Examples . . . . . . . . . . . . . . . . . . 18
 7.  'Data Preservation' Optimization . . . . . . . . . . . . . . . 20
 8.  'Premature Dataflow Termination' Optimizations . . . . . . . . 21
     8.1.  Original Dataflow  . . . . . . . . . . . . . . . . . . . 22
     8.2.  Adapted Dataflow . . . . . . . . . . . . . . . . . . . . 23
     8.3.  Getting Out of the Loop  . . . . . . . . . . . . . . . . 24
 9.  Protocol Element Type Declaration Mnemonic (PETDM) . . . . . . 25
     9.1     Optional Parameters  . . . . . . . . . . . . . . . . . 27
 10. Message Parameter Types  . . . . . . . . . . . . . . . . . . . 28
     10.1.   uri. . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.2.   uni. . . . . . . . . . . . . . . . . . . . . . . . . . 28
     10.3.   size . . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.4.   offset . . . . . . . . . . . . . . . . . . . . . . . . 29
     10.5.   percent  . . . . . . . . . . . . . . . . . . . . . . . 29
     10.6.   boolean. . . . . . . . . . . . . . . . . . . . . . . . 30
     10.7.   xid .  . . . . . . . . . . . . . . . . . . . . . . . . 30
     10.8.   sg-id. . . . . . . . . . . . . . . . . . . . . . . . . 30
     10.9.   modp. . . . . . . . . . . . . . . . . . . . . . . . .  30
     10.10.  result. . . . . . . . . . . . . . . . . . . . . . . .  30
     10.11.  feature . . . . . . . . . . . . . . . . . . . . . . .  32
     10.12.  features. . . . . . . . . . . . . . . . . . . . . . .  32
     10.13.  service . . . . . . . . . . . . . . . . . . . . . . .  32
     10.14.  services. . . . . . . . . . . . . . . . . . . . . . .  33
     10.15.  Dataflow Specializations. . . . . . . . . . . . . . .  33
 11. Message Definitions . . . . . . . . . . . . . . . . . . . . .  33
     11.1.   Connection Start (CS) . . . . . . . . . . . . . . . .  34
     11.2.   Connection End (CE) . . . . . . . . . . . . . . . . .  35
     11.3.   Service Group Created (SGC) . . . . . . . . . . . . .  35
     11.4.   Service Group Destroyed (SGD) . . . . . . . . . . . .  36
     11.5.   Transaction Start (TS). . . . . . . . . . . . . . . .  36
     11.6.   Transaction End (TE). . . . . . . . . . . . . . . . .  36
     11.7.   Application Message Start (AMS) . . . . . . . . . . .  37
     11.8.   Application Message End (AME) . . . . . . . . . . . .  37
     11.9.   Data Use Mine (DUM) . . . . . . . . . . . . . . . . .  38
     11.10.  Data Use Yours (DUY). . . . . . . . . . . . . . . . .  39
     11.11.  Data Preservation Interest (DPI). . . . . . . . . . .  39
     11.12.  Want Stop Receiving Data (DWSR) . . . . . . . . . . .  40
     11.13.  Want Stop Sending Data (DWSS) . . . . . . . . . . . .  41
     11.14.  Stop Sending Data (DSS) . . . . . . . . . . . . . . .  41
     11.15.  Want Data Paused (DWP). . . . . . . . . . . . . . . .  42

Rousskov Standards Track [Page 2] RFC 4037 OPES Callout Protocol Core March 2005

     11.16.  Paused My Data (DPM). . . . . . . . . . . . . . . . .  43
     11.17.  Want More Data (DWM). . . . . . . . . . . . . . . . .  43
     11.18.  Negotiation Offer (NO). . . . . . . . . . . . . . . .  44
     11.19.  Negotiation Response (NR) . . . . . . . . . . . . . .  45
     11.20.  Ability Query (AQ). . . . . . . . . . . . . . . . . .  46
     11.21.  Ability Answer (AA) . . . . . . . . . . . . . . . . .  46
     11.22.  Progress Query (PQ) . . . . . . . . . . . . . . . . .  47
     11.23.  Progress Answer (PA). . . . . . . . . . . . . . . . .  47
     11.24.  Progress Report (PR). . . . . . . . . . . . . . . . .  48
 12. IAB Considerations  . . . . . . . . . . . . . . . . . . . . .  48
 13. Security Considerations . . . . . . . . . . . . . . . . . . .  48
 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  50
 15. Compliance  . . . . . . . . . . . . . . . . . . . . . . . . .  50
     15.1.  Extending OCP Core . . . . . . . . . . . . . . . . . .  51
 A.  Message Summary . . . . . . . . . . . . . . . . . . . . . . .  52
 B.  State Summary   . . . . . . . . . . . . . . . . . . . . . . .  53
 C.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  54
 16. References  . . . . . . . . . . . . . . . . . . . . . . . . .  54
     16.1.  Normative References . . . . . . . . . . . . . . . . .  54
     16.2.  Informative References . . . . . . . . . . . . . . . .  54
 Author's Address. . . . . . . . . . . . . . . . . . . . . . . . .  55
 Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .  56

1. Introduction

 The Open Pluggable Edge Services (OPES) architecture [RFC3835]
 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 OPES processor can delegate the responsibility of service
 execution by communicating with callout servers.  As described in
 [RFC3836], an OPES processor invokes and communicates with services
 on a callout server by using an OPES callout protocol (OCP).  This
 document specifies the core of that protocol ("OCP Core").
 The OCP Core specification documents general application-independent
 protocol mechanisms.  A separate series of documents describes
 application-specific aspects of OCP.  For example, "HTTP Adaptation
 with OPES" [OPES-HTTP] describes, in part, how HTTP messages and HTTP
 meta-information can be communicated over OCP.
 Section 1.2 provides a brief overview of the entire OPES document
 collection, including documents describing OPES use cases and
 security threats.

Rousskov Standards Track [Page 3] RFC 4037 OPES Callout Protocol Core March 2005

1.1. Scope

 The OCP Core specification documents the behavior of OCP agents and
 the requirements for OCP extensions.  OCP Core does not contain
 requirements or mechanisms specific for application protocols being
 adapted.
 As an application proxy, the OPES processor proxies a single
 application protocol or converts from one application protocol to
 another.  At the same time, OPES processor may be an OCP client,
 using OCP to facilitate adaptation of proxied messages at callout
 servers.  It is therefore natural to assume that an OPES processor
 takes application messages being proxied, marshals them over OCP to
 callout servers, and then puts the adaptation results back on the
 wire.  However, this assumption implies that OCP is applied directly
 to application messages that OPES processor is proxying, which may
 not be the case.
    OPES processor scope                         callout server scope
    +-----------------+                           +-----------------+
    | pre-processing  |         OCP scope         |                 |
    |            +- - - - - - - - - - - - - - - - - - -+            |
    | iteration  |     <== ( application data ) ==>    | adaptation |
    |            +- - - - - - - - - - - - - - - - - - -+            |
    | post-processing |                           |                 |
    +-----------------+                           +-----------------+
 An OPES processor may preprocess (or postprocess) proxied application
 messages before (or after) they are adapted at callout servers.  For
 example, a processor may take an HTTP response being proxied and pass
 it as-is, along with metadata about the corresponding HTTP
 connection.  Another processor may take an HTTP response, extract its
 body, and pass that body along with the content-encoding metadata.
 Moreover, to perform adaptation, the OPES processor may execute
 several callout services, iterating over several callout servers.
 Such preprocessing, postprocessing, and iterations make it impossible
 to rely on any specific relationship between application messages
 being proxied and application messages being sent to a callout
 service.  Similarly, specific adaptation actions at the callout
 server are outside OCP Core scope.
 This specification does not define or require any specific
 relationship among application messages being proxied by an OPES
 processor and application messages being exchanged between an OPES
 processor and a callout server via OCP.  The OPES processor usually
 provides some mapping among these application messages, but the
 processor's specific actions are beyond OCP scope.  In other words,
 this specification is not concerned with the OPES processor role as

Rousskov Standards Track [Page 4] RFC 4037 OPES Callout Protocol Core March 2005

 an application proxy or as an iterator of callout services.  The
 scope of OCP Core is communication between a single OPES processor
 and a single callout server.
 Furthermore, an OPES processor may choose which proxied application
 messages or information about them to send over OCP.  All proxied
 messages on all proxied connections (if connections are defined for a
 given application protocol), everything on some connections, selected
 proxied messages, or nothing might be sent over OCP to callout
 servers.  OPES processor and callout server state related to proxied
 protocols can be relayed over OCP as application message metadata.

1.2. OPES Document Map

 This document belongs to a large set of OPES specifications produced
 by the IETF OPES Working Group.  Familiarity with the overall OPES
 approach and typical scenarios is often essential when one tries to
 comprehend isolated OPES documents.  This section provides an index
 of OPES documents to assist the reader with finding "missing"
 information.
 o  "OPES Use Cases and Deployment Scenarios" [RFC3752] describes a
    set of services and applications that are considered in scope for
    OPES and that have been used as a motivation and guidance in
    designing the OPES architecture.
 o  The OPES architecture and common terminology are described in "An
    Architecture for Open Pluggable Edge Services (OPES)" [RFC3835].
 o  "Policy, Authorization, and Enforcement Requirements of OPES"
    [RFC3838] outlines requirements and assumptions on the policy
    framework, without specifying concrete authorization and
    enforcement methods.
 o  "Security Threats and Risks for OPES" [RFC3837] provides OPES risk
    analysis, without recommending specific solutions.
 o  "OPES Treatment of IAB Considerations" [RFC3914] addresses all
    architecture-level considerations expressed by the IETF Internet
    Architecture Board (IAB) when the OPES WG was chartered.
 o  At the core of the OPES architecture are the OPES processor and
    the callout server, two network elements that communicate with
    each other via an OPES Callout Protocol (OCP).  The requirements
    for this protocol are discussed in "Requirements for OPES Callout
    Protocols" [RFC3836].

Rousskov Standards Track [Page 5] RFC 4037 OPES Callout Protocol Core March 2005

 o  This document specifies an application agnostic protocol core to
    be used for the communication between an OPES processor and a
    callout server.
 o  "OPES Entities and End Points Communications" [RFC3897] specifies
    generic tracing and bypass mechanisms for OPES.
 o  The OCP Core and communications documents are independent from the
    application protocol being adapted by OPES entities.  Their
    generic mechanisms have to be complemented by application-specific
    profiles.  "HTTP Adaptation with OPES" [OPES-HTTP] is such an
    application profile for HTTP.  It specifies how
    application-agnostic OPES mechanisms are to be used and augmented
    in order to support adaptation of HTTP messages.
 o  Finally, "P: Message Processing Language" [OPES-RULES] defines a
    language for specifying what OPES adaptations (e.g., translation)
    must be applied to what application messages (e.g., e-mail from
    bob@example.com).  P language is intended for configuring
    application proxies (OPES processors).

1.3. Terminology

 In this document, the keywords "MUST", "MUST NOT", "REQUIRED",
 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
 and "OPTIONAL" in this document are to be interpreted as described in
 [RFC2119].  When used with the normative meanings, these keywords
 will be all uppercase.  Occurrences of these words in lowercase
 constitute normal prose usage, with no normative implications.
 The OPES processor works with messages from application protocols and
 may relay information about those application messages to a callout
 server.  OCP is also an application protocol.  Thus, protocol
 elements such as "message", "connection", or "transaction" exist in
 OCP and other application protocols.  In this specification, all
 references to elements from application protocols other than OCP are
 used with an explicit "application" qualifier.  References without
 the "application" qualifier refer to OCP elements.
 OCP message: A basic unit of communication between an OPES processor
    and a callout server.  The message is a sequence of octets
    formatted according to syntax rules (section 3.1).  Message
    semantics is defined in section 11.
 application message: An entity defined by OPES processor and callout
    server negotiation.  Usually, the negotiated definition would
    match the definition from an application protocol (e.g., [RFC2616]
    definition of an HTTP message).

Rousskov Standards Track [Page 6] RFC 4037 OPES Callout Protocol Core March 2005

 application message data: An opaque sequence of octets representing a
    complete or partial application message.  OCP Core does not
    distinguish application message structures (if there are any).
    Application message data may be empty.
 data: Same as application message data.
 original: Referring to an application message flowing from the OPES
    processor to a callout server.
 adapted: Referring to an application message flowing from an OPES
    callout server to the OPES processor.
 adaptation: Any kind of access by a callout server, including
    modification, generation, and copying.  For example, translating
    or logging an SMTP message is adaptation of that application
    message.
 agent: The actor for a given communication protocol.  The OPES
    processor and callout server are OCP agents.  An agent can be
    referred to as a sender or receiver, depending on its actions in a
    particular context.
 immediate: Performing the specified action before reacting to new
    incoming messages or sending any new messages unrelated to the
    specified action.
 OCP extension: A specification extending or adjusting this document
    for adaptation of an application protocol (a.k.a., application
    profile; e.g., [OPES-HTTP]), new OCP functionality (e.g.,
    transport encryption and authentication), and/or new OCP Core
    version.

2. Overall Operation

 The OPES processor may use the OPES callout protocol (OCP) to
 communicate with callout servers.  Adaptation using callout services
 is sometimes called "bump in the wire" architecture.

2.1. Initialization

 The OPES processor establishes transport connections with callout
 servers to exchange application messages with the callout server(s)
 by using OCP.  After a transport-layer connection (usually TCP/IP) is
 established, communicating OCP agents exchange Connection Start (CS)
 messages.  Next, OCP features can be negotiated between the processor
 and the callout server (see section 6).  For example, OCP agents may
 negotiate transport encryption and application message definition.

Rousskov Standards Track [Page 7] RFC 4037 OPES Callout Protocol Core March 2005

 When enough settings are negotiated, OCP agents may start exchanging
 application messages.
 OCP Core provides negotiation and other mechanisms for agents to
 encrypt OCP connections and authenticate each other.  OCP Core does
 not require OCP connection encryption or agent authentication.
 Application profiles and other OCP extensions may document and/or
 require these and other security mechanisms.  OCP is expected to be
 used, in part, in closed environments where trust and privacy are
 established by means external to OCP.  Implementations are expected
 to demand necessary security features via the OCP Core negotiation
 mechanism, depending on agent configuration and environment.

2.2. Original Dataflow

 When the OPES processor wants to adapt an application message, it
 sends a Transaction Start (TS) message to initiate an OCP transaction
 dedicated to that application message.  The processor then sends an
 Application Message Start (AMS) message to prepare the callout server
 for application data that will follow.  Once the application message
 scope is established, application data can be sent to the callout
 server by using Data Use Mine (DUM) and related OCP message(s).  All
 of these messages correspond to the original dataflow.

2.3. Adapted Dataflow

 The callout server receives data and metadata sent by the OPES
 processor (original dataflow).  The callout server analyses metadata
 and adapts data as it comes in.  The server usually builds its
 version of metadata and responds to the OPES processor with an
 Application Message Start (AMS) message.  Adapted application message
 data can be sent next, using Data Use Mine (DUM) OCP message(s).  The
 application message is then announced to be "completed" or "closed"
 by using an Application Message End (AME) message.  The transaction
 may be closed by using a Transaction End (TE) message, as well.  All
 these messages correspond to adapted data flow.
     +---------------+                             +-------+
     |     OPES      | == (original data flow) ==> |callout|
     |   processor   | <== (adapted data flow) === |server |
     +---------------+                             +-------+
 The OPES processor receives the adapted application message sent by
 the callout server.  Other OPES processor actions specific to the
 application message received are outside scope of this specification.

Rousskov Standards Track [Page 8] RFC 4037 OPES Callout Protocol Core March 2005

2.4. Multiple Application Messages

 OCP Core specifies a transactions interface dedicated to exchanging a
 single original application message and a single adapted application
 message.  Some application protocols may require multiple adapted
 versions for a single original application message or even multiple
 original messages to be exchanged as a part of a single OCP
 transaction.  For example, a single original e-mail message may need
 to be transformed into several e-mail messages, with one custom
 message for each recipient.
 OCP extensions MAY document mechanisms for exchanging multiple
 original and/or multiple adapted application messages within a single
 OCP transaction.

2.5. Termination

 Either OCP agent can terminate application message delivery,
 transaction, or connection by sending an appropriate OCP message.
 Usually, the callout server terminates adapted application message
 delivery and the transaction.  Premature and abnormal terminations at
 arbitrary times are supported.  The termination message includes a
 result description.

2.6. Message Exchange Patterns

 In addition to messages carrying application data, OCP agents may
 also exchange messages related to their configuration, state,
 transport connections, application connections, etc.  A callout
 server may remove itself from the application message processing
 loop.  A single OPES processor can communicate with many callout
 servers and vice versa.  Though many OCP exchange patterns do not
 follow a classic client-server model, it is possible to think of an
 OPES processor as an "OCP client" and of a callout server as an "OCP
 server".  The OPES architecture document [RFC3835] describes
 configuration possibilities.
 The following informal rules illustrate relationships between
 connections, transactions, OCP messages, and application messages:
 o  An OCP agent may communicate with multiple OCP agents.  This is
    outside the scope of this specification.
 o  An OPES processor may have multiple concurrent OCP connections to
    a callout server.  Communication over multiple OCP connections is
    outside the scope of this specification.

Rousskov Standards Track [Page 9] RFC 4037 OPES Callout Protocol Core March 2005

 o  A connection may carry multiple concurrent transactions.  A
    transaction is always associated with a single connection (i.e., a
    transaction cannot span multiple concurrent connections).
 o  A connection may carry at most one message at a time, including
    control messages and transaction-related messages.  A message is
    always associated with a single connection (i.e., a message cannot
    span multiple concurrent connections).
 o  A transaction is a sequence of messages related to application of
    a given set of callout services to a single application message.
    A sequence of transaction messages from an OPES processor to a
    callout server is called original flow.  A sequence of transaction
    messages from a callout server to an OPES processor is called
    adapted flow.  The two flows may overlap in time.
 o  In OCP Core, a transaction is associated with a single original
    and a single adapted application message.  OCP Core extensions may
    extend transaction scope to more application messages.
 o  An application message (adapted or original) is transferred by
    using a sequence of OCP messages.

2.7. Timeouts

 OCP violations, resource limits, external dependencies, and other
 factors may lead to states in which an OCP agent is not receiving
 required messages from the other OCP agent.  OCP Core defines no
 messages to address such situations.  In the absence of any extension
 mechanism, OCP agents must implement timeouts for OCP operations.  An
 OCP agent MUST forcefully terminate any OCP connection, negotiation,
 transaction, etc.  that is not making progress.  This rule covers
 both dead- and livelock situations.
 In their implementation, OCP agents MAY rely on transport-level or
 other external timeouts if such external timeouts are guaranteed to
 happen for a given OCP operation.  Depending on the OCP operation, an
 agent may benefit from "pinging" the other side with a Progress Query
 (PQ) message before terminating an OCP transaction or connection.
 The latter is especially useful for adaptations that may take a long
 time at the callout server before producing any adapted data.

Rousskov Standards Track [Page 10] RFC 4037 OPES Callout Protocol Core March 2005

2.8. Environment

 OCP communication is assumed usually to take place over TCP/IP
 connections on the Internet (though no default TCP port is assigned
 to OCP in this specification).  This does not preclude OCP from being
 implemented on top of other transport protocols, or on other
 networks.  High-level transport protocols such as BEEP [RFC3080] may
 be used.  OCP Core requires a reliable and message-order-preserving
 transport.  Any protocol with these properties can be used; the
 mapping of OCP message structures onto the transport data units of
 the protocol in question is outside the scope of this specification.
 OCP Core is application agnostic.  OCP messages can carry
 application-specific information as a payload or as
 application-specific message parameters.
 OCP Core overhead in terms of extra traffic on the wire is about 100
 - 200 octets per small application message.  Pipelining, preview,
 data preservation, and early termination optimizations, as well as
 as-is encapsulation of application data, make fast exchange of
 application messages possible.

3. Messages

 As defined in section 1.3, an OCP message is a basic unit of
 communication between an OPES processor and a callout server.  A
 message is a sequence of octets formatted according to syntax rules
 (section 3.1).  Message semantics is defined in section 11.  Messages
 are transmitted on top of OCP transport.
 OCP messages deal with transport, transaction management, and
 application data exchange between a single OPES processor and a
 single callout server.  Some messages can be emitted only by an OPES
 processor; some only by a callout server; and some by both OPES
 processor and callout server.  Some messages require responses (one
 could call such messages "requests"); some can only be used in
 response to other messages ("responses"); some may be sent without
 solicitation; and some may not require a response.

Rousskov Standards Track [Page 11] RFC 4037 OPES Callout Protocol Core March 2005

3.1. Message Format

 An OCP message consists of a message name followed by optional
 parameters and a payload.  The exact message syntax is defined by the
 following Augmented Backus-Naur Form (ABNF) [RFC2234]:
 message = name [SP anonym-parameters]
           [CRLF named-parameters CRLF]
           [CRLF payload CRLF]
           ";" CRLF
 anonym-parameters = value *(SP value)               ; space-separated
 named-parameters  = named-value *(CRLF named-value) ; CRLF-separated
 list-items        = value *("," value)              ; comma-separated
 payload = data
 named-value = name ":" SP value
 value     = structure / list / atom
 structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}"
 list      = "(" [ list-items ] ")"
 atom      = bare-value / quoted-value
 name = ALPHA *safe-OCTET
 bare-value = 1*safe-OCTET
 quoted-value = DQUOTE data DQUOTE
 data = size ":" *OCTET                   ; exactly size octets
 safe-OCTET = ALPHA / DIGIT / "-" / "_"
 size = dec-number                        ; 0-2147483647
 dec-number = 1*DIGIT                     ; no leading zeros or signs
 Several normative rules accompany the above ABNF:
 o  There is no "implied linear space" (LWS) rule.  LWS rules are
    common to MIME-based grammars but are not used here.  The
    whitespace syntax is restricted to what is explicitly allowed by
    the above ABNF.
 o  All protocol elements are case sensitive unless it is specified
    otherwise.  In particular, message names and parameter names are
    case sensitive.
 o  Sizes are interpreted as decimal values and cannot have leading
    zeros.
 o  Sizes do not exceed 2147483647.

Rousskov Standards Track [Page 12] RFC 4037 OPES Callout Protocol Core March 2005

 o  The size attribute in a quoted-value encoding specifies the exact
    number of octets following the column (':') separator.  If size
    octets are not followed by a quote ('"') character, the encoding
    is syntactically invalid.
 o  Empty quoted values are encoded as a 4-octet sequence "0:".
 o  Any bare value can be encoded as a quoted value.  A quoted value
    is interpreted after the encoding is removed.  For example, number
    1234 can be encoded as four octets 1234 or as eight octets
    "4:1234", yielding exactly the same meaning.
 o  Unicode UTF-8 is the default encoding.  Note that ASCII is a UTF-8
    subset, and that the syntax prohibits non-ASCII characters outside
    of the "data" element.
 Messages violating formatting rules are, by definition, invalid.  See
 section 5 for rules governing processing of invalid messages.

3.2. Message Rendering

 OCP message samples in this specification and its extensions may not
 be typeset to depict minor syntactical details of OCP message format.
 Specifically, SP and CRLF characters are not shown explicitly.  No
 rendering of an OCP message can be used to infer message format.  The
 message format definition above is the only normative source for all
 implementations.
 On occasion, an OCP message line exceeds text width allowed by this
 specification format.  A backslash ("\"), a "soft line break"
 character, is used to emphasize a protocol-violating
 presentation-only linebreak.  Bare backslashes are prohibited by OCP
 syntax.  Similarly, an "\r\n" string is sometimes used to emphasize
 the presence of a CRLF sequence, usually before OCP message payload.
 Normally, the visible end of line corresponds to the CRLF sequence on
 the wire.
 The next section (section 3.3) contains specific OCP message
 examples, some of which illustrate the above rendering techniques.

Rousskov Standards Track [Page 13] RFC 4037 OPES Callout Protocol Core March 2005

3.3. Message Examples

 OCP syntax provides for compact representation of short control
 messages and required parameters while allowing for parameter
 extensions.  Below are examples of short control messages.  The
 required CRLF sequence at the end of each line is not shown
 explicitly (see section 3.2).
 PQ;
 TS 1 2;
 DWM 22;
 DWP 22 16;
 x-doit "5:xyzzy";
 The above examples contain atomic anonymous parameter values, such as
 number and string constants.  OCP messages sometimes use more
 complicated parameters such as item lists or structures with named
 values.  As both messages below illustrate, structures and lists can
 be nested:
 NO ({"32:http://www.iana.org/assignments/opes/ocp/tls"});
 NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
 Optional-Parts: (request-header)
 },{"54:http://www.iana.org/assignments/opes/ocp/http/response"
 Optional-Parts: (request-header,request-body)
 Transfer-Encodings: (chunked)
 });
 Optional parameters and extensions are possible with a named
 parameters approach, as illustrated by the following example.  The
 DWM (section 11.17) message in the example has two anonymous
 parameters (the last one being an extension) and two named parameters
 (the last one being an extension).
 DWM 1 3
 Size-Request: 16384
 X-Need-Info: "26:twenty six octet extension";
 Finally, any message may have a payload part.  For example, the Data
 Use Mine (DUM) message below carries 8865 octets of raw data.
 DUM 1 13
 Modp: 75
 \r\n
 8865:... 8865 octets of raw data ...;

Rousskov Standards Track [Page 14] RFC 4037 OPES Callout Protocol Core March 2005

3.4. Message Names

 Most OCP messages defined in this specification have short names,
 formed by abbreviating or compressing a longer but human-friendlier
 message title.  Short names without a central registration system
 (such as this specification or the IANA registry) are likely to cause
 conflicts.  Informal protocol extensions should avoid short names.
 To emphasize what is already defined by message syntax,
 implementations cannot assume that all message names are very short.

4. Transactions

 An OCP transaction is a logical sequence of OCP messages processing a
 single original application message.  The result of the processing
 may be zero or more application messages, adapted from the original.
 A typical transaction consists of two message flows: a flow from the
 OPES processor to the callout server (sending the original
 application message), and a flow from the callout server to the OPES
 processor (sending adapted application messages).  The number of
 application messages produced by the callout server and whether the
 callout server actually modifies the original application message may
 depend on the requested callout service and other factors.  The OPES
 processor or the callout server can terminate the transaction by
 sending a corresponding message to the other side.
 An OCP transaction starts with a Transaction Start (TS) message sent
 by the OPES processor.  A transaction ends with the first Transaction
 End (TE) message sent or received, explicit or implied.  A TE message
 can be sent by either side.  Zero or more OCP messages associated
 with the transaction can be exchanged in between.  The figure below
 illustrates a possible message sequence (prefix "P" stands for the
 OPES processor; prefix "S" stands for the callout server).  Some
 message details are omitted.
 P: TS 10;
 P: AMS 10 1;
    ... processor sending application data to the callout server
 S: AMS 10 2;
    ... callout server sending application data to the processor
    ... processor sending application data to the callout server
 P: AME 10 1 result;
 S: AME 10 2 result;
 P: TE 10 result;

Rousskov Standards Track [Page 15] RFC 4037 OPES Callout Protocol Core March 2005

5. Invalid Input

 This specification contains many criteria for valid OCP messages and
 their parts, including syntax rules, semantics requirements, and
 relationship to agents state.  In this context, "Invalid input" means
 messages or message parts that violate at least one of the normative
 rules.  A message with an invalid part is, by definition, invalid.
 If OCP agent resources are exhausted while parsing or interpreting a
 message, the agent MUST treat the corresponding OCP message as
 invalid.
 Unless explicitly allowed to do otherwise, an OCP agent MUST
 terminate the transaction if it receives an invalid message with
 transaction scope and MUST terminate the connection if it receives an
 invalid message with a connection scope.  A terminating agent MUST
 use the result status code of 400 and MAY specify termination cause
 information in the result status reason parameter (see section
 10.10).  If an OCP agent is unable to determine the scope of an
 invalid message it received, the agent MUST treat the message as
 having connection scope.
 OCP usually deals with optional but invasive application message
 manipulations for which correctness ought to be valued above
 robustness.  For example, a failure to insert or remove certain
 optional web page content is usually far less disturbing than
 corrupting (making unusable) the host page while performing that
 insertion or removal.  Most OPES adaptations are high level in
 nature, which makes it impossible to assess correctness of the
 adaptations automatically, especially if "robustness guesses" are
 involved.

6. Negotiation

 The negotiation mechanism allows OCP agents to agree on the mutually
 acceptable set of features, including optional and
 application-specific behavior and OCP extensions.  For example,
 transport encryption, data format, and support for a new message can
 be negotiated.  Negotiation implies intent for a behavioral change.
 For a related mechanism allowing an agent to query capabilities of
 its counterpart without changing the counterpart's behavior, see the
 Ability Query (AQ) and Ability Answer (AA) message definitions.
 Most negotiations require at least one round trip time delay.  In
 rare cases when the other side's response is not required
 immediately, negotiation delay can be eliminated, with an inherent
 risk of an overly optimistic assumption about the negotiation
 response.

Rousskov Standards Track [Page 16] RFC 4037 OPES Callout Protocol Core March 2005

 A detected violation of negotiation rules leads to OCP connection
 termination.  This design reduces the number of negotiation scenarios
 resulting in a deadlock when one of the agents is not compliant.
 Two core negotiation primitives are supported: negotiation offer and
 negotiation response.  A Negotiation Offer (NO) message allows an
 agent to specify a set of features from which the responder has to
 select at most one feature that it prefers.  The selection is sent by
 using a Negotiation Response (NR) message.  If the response is
 positive, both sides assume that the selected feature is in effect
 immediately (see section 11.19 for details).  If the response is
 negative, no behavioral changes are assumed.  In either case, further
 offers may follow.
 Negotiating OCP agents have to take into account prior negotiated
 (i.e., already enabled) features.  OCP agents MUST NOT make and MUST
 reject offers that would lead to a conflict with already negotiated
 features.  For example, an agent cannot offer an HTTP application
 profile for a connection that already has an SMTP application profile
 enabled, as there would be no way to resolve the conflict for a given
 transaction.  Similarly, once TLSv1 connection encryption is
 negotiated, an agent must not offer and must reject offers for SSLv2
 connection encryption (unless a negotiated feature explicitly allows
 for changing an encryption scheme on the fly).
 Negotiation Offer (NO) messages may be sent by either agent.  OCP
 extensions documenting negotiation MAY assign the initiator role to
 one of the agents, depending on the feature being negotiated.  For
 example, negotiation of transport security feature should be
 initiated by OPES processors to avoid situations where both agents
 wait for the other to make an offer.
 As either agent may make an offer, two "concurrent" offers may be
 made at the same time, by the two communicating agents.  Unmanaged
 concurrent offers may lead to a negotiation deadlock.  By giving OPES
 processor a priority, offer-handling rules (section 11.18) ensure
 that only one offer per OCP connection is honored at a time, and that
 the other concurrent offers are ignored by both agents.

6.1. Negotiation Phase

 A Negotiation Phase is a mechanism ensuring that both agents have a
 chance to negotiate all features they require before proceeding
 further.  Negotiation Phases have OCP connection scope and do not
 overlap.  For each OCP agent, the Negotiation Phase starts with the
 first Negotiation Offer (NO) message received or the first
 Negotiation Response (NR) message sent, provided the message is not a
 part of an existing Phase.  For each OCP agent, Negotiation Phase

Rousskov Standards Track [Page 17] RFC 4037 OPES Callout Protocol Core March 2005

 ends with the first Negotiation Response (NR) message (sent or
 received), after which the agent expects no more negotiations.  Agent
 expectation rules are defined later in this section.
 During a Negotiation Phase, an OCP agent MUST NOT send messages other
 than the following "Negotiation Phase messages": Negotiation Offer
 (NO), Negotiation Response (NR), Ability Query (AQ), Ability Answer
 (AA), Progress Query (PQ), Progress Answer (PA), Progress Report
 (PR), and Connection End (CE).
 Multiple Negotiation Phases may happen during the lifespan of a
 single OCP connection.  An agent may attempt to start a new
 Negotiation Phase immediately after the old Phase is over, but it is
 possible that the other agent will send messages other than
 "Negotiation Phase messages" before receiving the new Negotiation
 Offer (NO).  The agent that starts a Phase has to be prepared to
 handle those messages while its offer is reaching the recipient.
 An OPES processor MUST make a negotiation offer immediately after
 sending a Connection Start (CS) message.  If the OPES processor has
 nothing to negotiate, the processor MUST send a Negotiation Offer
 (NO) message with an empty features list.  These two rules bootstrap
 the first Negotiation Phase.  Agents are expected to negotiate at
 least the application profile for OCP Core.  Thus, these
 bootstrapping requirements are unlikely to result in any extra work.
 Once a Negotiation Phase starts, an agent MUST expect further
 negotiations if and only if the last NO sent or the last NR received
 contained a true "Offer-Pending" parameter value.  Informally, an
 agent can keep the phase open by sending true "Offer-Pending"
 parameters with negotiation offers or responses.  Moreover, if there
 is a possibility that the agent may need to continue the Negotiation
 Phase, the agent must send a true "Offer-Pending" parameter.

6.2. Negotiation Examples

 Below is an example of the simplest negotiation possible.  The OPES
 processor is offering nothing and is predictably receiving a
 rejection.  Note that the NR message terminates the Negotiation Phase
 in this case because neither of the messages contains a true
 "Offer-Pending" value:
 P: NO ();
 S: NR;
 The next example illustrates how a callout server can force
 negotiation of a feature that an OPES processor has not negotiated.
 Note that the server sets the "Offer-Pending" parameter to true when

Rousskov Standards Track [Page 18] RFC 4037 OPES Callout Protocol Core March 2005

 responding to the processor Negotiation Offer (NO) message.  The
 processor chooses to accept the feature:
 P: NO ();
 S: NR
    Offer-Pending: true
    ;
 S: NO ({"22:ocp://feature/example/"})
    Offer-Pending: false
    ;
 P: NR {"22:ocp://feature/example/"};
 If the server seeks to stop the above negotiations after sending a
 true "Offer-Pending" value, its only option would be send an empty
 negotiation offer (see the first example above).  If the server does
 nothing instead, the OPES processor would wait for the server and
 would eventually time out the connection.
 The following example shows a dialog with a callout server that
 insists on enabling two imaginary features: strong transport
 encryption and volatile storage for responses.  The server is
 designed not to exchange sensitive messages until both features are
 enabled.  Naturally, the volatile storage feature has to be
 negotiated securely.  The OPES processor supports one of the strong
 encryption mechanisms but prefers not to offer (to volunteer support
 for) strong encryption, perhaps for performance reasons.  The server
 has to send a true "Offer-Pending" parameter to get a chance to offer
 strong encryption (which is successfully negotiated in this case).
 Any messages sent by either agent after the (only) successful NR
 response are encrypted with "strongB" encryption scheme.  The OPES
 processor does not understand the volatile storage feature, and the
 last negotiation fails (over a strongly encrypted transport
 connection).
 P: NO ({"29:ocp://example/encryption/weak"})
    ;
 S: NR
    Offer-Pending: true
    ;
 S: NO ({"32:ocp://example/encryption/strongA"},\
    {"32:ocp://example/encryption/strongB"})
    Offer-Pending: true
    ;
 P: NR {"32:ocp://example/encryption/strongB"}
    ;
 ... all traffic below is encrypted using strongB ...

Rousskov Standards Track [Page 19] RFC 4037 OPES Callout Protocol Core March 2005

 S: NO ({"31:ocp://example/storage/volatile"})
    Offer-Pending: false
    ;
 P: NR
    Unknowns: ({"31:ocp://example/storage/volatile"})
    ;
 S: CSE { 400 "33:lack of VolStore protocol support" }
    ;
 The following example from [OPES-HTTP] illustrates successful HTTP
 application profile negotiation:
 P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response"
    Aux-Parts: (request-header,request-body)
    })
    SG: 5;
 S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response"
    Aux-Parts: (request-header)
    Pause-At-Body: 30
    Wont-Send-Body: 2147483647
    Content-Encodings: (gzip)
    }
    SG: 5;

7. 'Data Preservation' Optimization

 Many adaptations do not require any data modifications (e.g., message
 logging or blocking).  Some adaptations modify only a small portion
 of application message content (e.g., HTTP cookies filtering or ad
 insertion).  Yet, in many cases, the callout service has to see
 complete data.  By default, unmodified data would first travel from
 the OPES processor to the callout server and then back.  The "data
 preservation" optimization in OCP helps eliminate the return trip if
 both OCP agents cooperate.  Such cooperation is optional: OCP agents
 MAY support data preservation optimization.
 To avoid sending back unmodified data, a callout service has to know
 that the OPES processor has a copy of the data.  As data sizes can be
 very large and the callout service may not know in advance whether it
 will be able to use the processor copy, it is not possible to require
 the processor to keep a copy of the entire original data.  Instead,
 it is expected that a processor may keep some portion of the data,
 depending on processor settings and state.
 When an OPES processor commits to keeping a data chunk, it announces
 its decision and the chunk parameters via a Kept parameter of a Data
 Use Mine (DUM) message.  The callout server MAY "use" the chunk by
 sending a Data Use Yours (DUY) message referring to the preserved

Rousskov Standards Track [Page 20] RFC 4037 OPES Callout Protocol Core March 2005

 chunk.  That OCP message does not have payload and, therefore, the
 return trip is eliminated.
 As the mapping between original and adapted data is not known to the
 processor, the processor MUST keep the announced-as-preserved chunk
 until the end of the corresponding transaction, unless the callout
 server explicitly tells the processor that the chunk is not needed.
 As implied by the above requirement, the processor cannot assume that
 a data chunk is no longer needed just because the callout server sent
 a Data Use Yours (DUY) message or adapted data with, for instance,
 the same offset as the preserved chunk.
 For simplicity, preserved data is always a contiguous chunk of
 original data, described by an (offset, size) pair using a "Kept"
 parameter of a Data Use Mine (DUM) message.  An OPES processor may
 volunteer to increase the size of the kept data.  An OPES processor
 may increase the offset if the callout server indicated that the kept
 data is no longer needed.
 Both agents may benefit from data reuse.  An OPES processor has to
 allocate storage to support this optimization, but a callout server
 does not.  On the other hand, it is the callout server that is
 responsible for relieving the processor from data preservation
 commitments.  There is no simple way to resolve this conflict of
 interest on a protocol level.  Some OPES processors may allocate a
 relatively small buffer for data preservation purposes and stop
 preserving data when the buffer becomes full.  This technique would
 benefit callout services that can quickly reuse or discard kept data.
 Another processor strategy would be to size the buffer based on
 historical data reuse statistics.  To improve chances of beneficial
 cooperation, callout servers are strongly encouraged to immediately
 notify OPES processors of unwanted data.  The callout server that
 made a decision not to send Data Use Yours (DUY) messages (for a
 specific data ranges or at all) SHOULD immediately inform the OPES
 processor of that decision with the corresponding Data Preservation
 Interest (DPI) message(s) or other mechanisms.

8. 'Premature Dataflow Termination' Optimizations

 Many callout services adapt small portions of large messages and
 would preferably not to be in the loop when that adaptation is over.
 Some callout services may not seek data modification and would
 preferably not send data back to the OPES processor, even if the OPES
 processor is not supporting the data preservation optimization
 (Section 7).  By OCP design, unilateral premature dataflow
 termination by a callout server would lead to termination of an OCP
 transaction with an error.  Thus, the two agents must cooperate to
 allow for error-free premature termination.

Rousskov Standards Track [Page 21] RFC 4037 OPES Callout Protocol Core March 2005

 This section documents two mechanisms for premature termination of
 original or adapted dataflow.  In combination, the mechanisms allow
 the callout server to get out of the processing loop altogether.

8.1. Original Dataflow

 There are scenarios where a callout server is not interested in the
 remaining original dataflow.  For example, a simple access blocking
 or "this site is temporary down" callout service has to send an
 adapted (generated) application message but would preferably not
 receive original data from the OPES processor.
 OCP Core supports premature original dataflow termination via the
 Want Stop Receiving Data (DWSR) message.  A callout server that does
 not seek to receive additional original data (beyond a certain size)
 sends a DWSR message.  The OPES processor receiving a DWSR message
 terminates original dataflow by sending an Application Message End
 (AME) message with a 206 (partial) status code.
 The following figure illustrates a typical sequence of events.  The
 downward lines connecting the two dataflows illustrate the
 transmission delay that allows for more OCP messages to be sent while
 an agent waits for the opposing agent reaction.
 OPES                 Callout
 Processor            Server
     DUM>             <DUM
     DUM>             <DWSR  <-- Server is ready to stop receiving
     ...        _____/<DUM   <-- Server continues as usual
     DUM>______/      <DUM
     AME>             ...    <-- Processor stops sending original data
         \_____       <DUM
               \______<DUM
                      <DUM   <-- Server continues to send adapted data
                      ...
                      <AME
 The mechanism described in this section has no effect on the adapted
 dataflow.  Receiving an Application Message End (AME) message with
 206 (partial) result status code from the OPES processor does not
 introduce any special requirements for the adapted dataflow
 termination.  However, it is not possible to terminate adapted
 dataflow prematurely after the original dataflow has been prematurely
 terminated (see section 8.3).

Rousskov Standards Track [Page 22] RFC 4037 OPES Callout Protocol Core March 2005

8.2. Adapted Dataflow

 There are scenarios where a callout service may want to stop sending
 adapted data before a complete application message has been sent.
 For example, a logging-only callout service has to receive all
 application messages but would preferably not send copies back to the
 OPES processor.
 OCP Core supports premature adapted dataflow termination via a
 combination of Want Stop Sending Data (DWSS) and Stop Sending Data
 (DSS) messages.  A callout service that seeks to stop sending data
 sends a DWSS message, soliciting an OPES processor permission to
 stop.  While waiting for the permission, the server continues with
 its usual routine.
 An OPES processor receiving a Want Stop Sending Data message responds
 with a Stop Sending Data (DSS) message.  The processor may then pause
 to wait for the callout server to terminate the adapted dataflow or
 may continue sending original data while making a copy of it.  Once
 the server terminates the adapted dataflow, the processor is
 responsible for using original data (sent or paused after sending
 DSS) instead of the adapted data.
 The callout server receiving a DSS message terminates the adapted
 dataflow (see the Stop Sending Data (DSS) message definition for the
 exact requirements and corner cases).
 The following figure illustrates a typical sequence of events,
 including a possible pause in original dataflow when the OPES
 processor is waiting for the adapted dataflow to end.  The downward
 lines connecting the two dataflows illustrate the transmission delay
 that allows for more OCP messages to be sent while an agent waits for
 the opposing agent reaction.

Rousskov Standards Track [Page 23] RFC 4037 OPES Callout Protocol Core March 2005

 OPES                 Callout
 Processor            Server
     DUM>             <DUM
     DUM>             <DWSS    <-- Server is ready to stop sending
     ...        _____/<DUM     <-- Server continues as usual,
     DUM>______/      <DUM         waiting for DSS
     DSS>             ...
         \_____       <DUM
   possible    \______<DUM
   org-dataflow       <AME 206 <-- Server terminates adapted dataflow
   pause        _____/             upon receiving the DSS message
         ______/
     DUM>                      <-- Processor resumes original dataflow
     DUM>                          to the server and starts using
     ...                           original data without adapting it
     AME>
 Premature adapted dataflow preservation is not trivial, as the OPES
 processor relies on the callout server to provide adapted data
 (modified or not) to construct the adapted application message.  If
 the callout server seeks to quit its job, special care must be taken
 to ensure that the OPES processor can construct the complete
 application message.  On a logical level, this mechanism is
 equivalent to switching from one callout server to another
 (non-modifying) callout server in the middle of an OCP transaction.
 Other than a possible pause in the original dataflow, the mechanism
 described in this section has no effect on the original dataflow.
 Receiving an Application Message End (AME) message with 206 (partial)
 result status code from the callout server does not introduce any
 special requirements for the original dataflow termination.

8.3. Getting Out of the Loop

 Some adaptation services work on application message prefixes and do
 not seek to be in the adaptation loop once their work is done.  For
 example, an ad insertion service that did its job by modifying the
 first fragment of a web "page" would not seek to receive more
 original data or to perform further adaptations.  The 'Getting Out of
 the Loop' optimization allows a callout server to get completely out
 of the application message processing loop.
 The "Getting Out of the Loop" optimization is made possible by
 terminating the adapted dataflow (section 8.2) and then by
 terminating the original dataflow (section 8.1).  The order of
 termination is very important.

Rousskov Standards Track [Page 24] RFC 4037 OPES Callout Protocol Core March 2005

 If the original dataflow is terminated first, the OPES processor
 would not allow the adapted dataflow to be terminated prematurely, as
 the processor would not be able to reconstruct the remaining portion
 of the adapted application message.  The processor would not know
 which suffix of the remaining original data has to follow the adapted
 parts.  The mapping between original and adapted octets is known only
 to the callout service.
 An OPES processor that received a DWSS message followed by a DWSR
 message MUST NOT send an AME message with a 206 (partial) status code
 before sending a DSS message.  Informally, this rule means that a
 callout server that wants to get out of the loop fast should send a
 DWSS message immediately followed by a DWSR message; the server does
 not have to wait for the OPES processor's permission to terminate
 adapted dataflow before requesting that the OPES processor terminates
 original dataflow.

9. Protocol Element Type Declaration Mnemonic (PETDM)

 A protocol element type is a named set of syntax and semantics rules.
 This section defines a simple, formal declaration mnemonic for
 protocol element types, labeled PETDM.  PETDM simplicity is meant to
 ease type declarations in this specification.  PETDM formality is
 meant to improve interoperability among implementations.  Two
 protocol elements are supported by PETDM: message parameter values
 and messages.
 All OCP Core parameter and message types are declared by using PETDM.
 OCP extensions SHOULD use PETDM when declaring new types.
 Atom, list, structure, and message constructs are four available base
 types.  Their syntax and semantics rules are defined in section 3.1.
 New types can be declared in PETDM to extend base types semantics by
 using the following declaration templates.  The new semantics rules
 are meant to be attached to each declaration using prose text.
 Text in angle brackets "<>" are template placeholders, to be
 substituted with actual type names or parameter name tokens.  Square
 brackets "[]" surround optional elements such as structure members or
 message payload.
 o  Declaring a new atomic type:
 <new-type-name>: extends atom;
 o  Declaring a new list with old-type-name items:
 <new-type-name>: extends list of <old-type-name>;
 Unless it is explicitly noted otherwise, empty lists are valid and
 have the semantics of an absent parameter value.

Rousskov Standards Track [Page 25] RFC 4037 OPES Callout Protocol Core March 2005

 o  Declaring a new structure with members:
 <new-type-name>: extends structure with {
         <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
         <member-name1>: <old-type-name1>;
         <member-name2>: <old-type-name2>;
         [<member-name3>: <old-type-name3>];
         ...
 };
 The new structure may have anonymous members and named members.
 Neither group has to exist.  Note that it is always possible for
 extensions to add more members to old structures without affecting
 type semantics because unrecognized members are ignored by compliant
 agents.
 o  Declaring a new message with parameters:
 <new-type-name>: extends message with {
         <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
         <parameter-name1>: <old-type-name1>;
         <parameter-name2>: <old-type-name2>;
         [<parameter-name3>: <old-type-name3>];
         ...
 };
 The new type name becomes the message name.  Just as when a structure
 is extended, the new message may have anonymous parameters and named
 parameters.  Neither group has to exist.  Note that it is always
 possible for extensions to add more parameters to old messages
 without affecting type semantics because unrecognized parameters are
 ignored by compliant agents.
 o  Extending a type with more semantics details:
 <new-type-name>: extends <old-type-name>;
 o  Extending a structure- or message-base type:
 <new-type-name>: extends <old-type-name> with {
         <old-type-nameA> <old-type-nameB> [<old-type-nameC>] ...;
         <member-name1>: <old-type-name1>;
         <member-name2>: <old-type-name2>;
         [<member-name3>: <old-type-name3>];
         ...
 };
 New anonymous members are appended to the anonymous members of the
 old type, and new named members are merged with named members of the
 old type.

Rousskov Standards Track [Page 26] RFC 4037 OPES Callout Protocol Core March 2005

 o  Extending a message-base type with payload semantics:
 <new-type-name>: extends <old-type-name> with {
         ...
 } and payload;
 Any any OCP message can have payload, but only some message types
 have known payload semantics.  Like any parameter, payload may be
 required or optional.
 o  Extending type semantics without renaming the type:
 <old-type-name>: extends <namespace>::<old-type-name>;
 The above template can be used by OCP Core extensions that seek to
 change the semantics of OCP Core types without renaming them.  This
 technique is essential for extending OCP messages because the message
 name is the same as the message type name.  For example, an SMTP
 profile for OCP might use the following declaration to extend an
 Application Message Start (AMS) message with Am-Id, a parameter
 defined in that profile:
 AMS: extends Core::AMS with {
         Am-Id: am-id;
 };
 All extended types may be used as replacements of the types they
 extend.  For example, a Negotiation Offer (NO) message uses a
 parameter of type Features.  Features (section 10.12) is a list of
 feature (section 10.11) items.  A Feature is a structure-based type.
 An OCP extension (e.g., an HTTP application profile) may extend the
 feature type and use a value of that extended type in a negotiation
 offer.  Recipients that are aware of the extension will recognize
 added members in feature items and negotiate accordingly.  Other
 recipients will ignore them.
 The OCP Core namespace tag is "Core".  OCP extensions that declare
 types MUST define their namespace tags (so that other extensions and
 documentation can use them in their PETDM declarations).

9.1. Optional Parameters

 Anonymous parameters are positional: The parameter's position (i.e.,
 the number of anonymous parameters to the left) is its "name".  Thus,
 when a structure or message has multiple optional anonymous
 parameters, parameters to the right can be used only if all
 parameters to the left are present.  The following notation
 [name1] [name2] [name3] ... [nameN]
 is interpreted as

Rousskov Standards Track [Page 27] RFC 4037 OPES Callout Protocol Core March 2005

 [name1 [ name2 [ name3 ... [nameN] ... ]]]
 When an anonymous parameter is added to a structure or message that
 has optional anonymous parameters, the new parameter has to be
 optional and can only be used if all old optional parameters are in
 use.  Named parameters do not have these limitations, as they are not
 positional, but associative; they are identified by their explicit
 and unique names.

10. Message Parameter Types

 This section defines parameter value types that are used for message
 definitions (section 11).  Before using a parameter value, an OCP
 agent MUST check whether the value has the expected type (i.e.,
 whether it complies with all rules from the type definition).  A
 single rule violation means that the parameter is invalid.  See
 Section 5 for rules on processing invalid input.
 OCP extensions MAY define their own types.  If they do, OCP
 extensions MUST define types with exactly one base format and MUST
 specify the type of every new protocol element they introduce.

10.1. uri

 uri: extends atom;
 Uri (universal resource identifier) is an atom formatted according to
 URI rules in [RFC2396].
 Often, a uri parameter is used as a unique (within a given scope)
 identifier.  Uni semantics is incomplete without the scope
 specification.  Many uri parameters are URLs.  Unless it is noted
 otherwise, URL identifiers do not imply the existence of a
 serviceable resource at the location they specify.  For example, an
 HTTP request for an HTTP-based URI identifier may result in a 404
 (Not Found) response.

10.2. uni

 uni: extends atom;
 Uni (unique numeric identifier) is an atom formatted as dec-number
 and with a value in the [0, 2147483647] range, inclusive.
 A uni parameter is used as a unique (within a given scope)
 identifier.  Uni semantics is incomplete without the scope
 specification.  Some OCP messages create identifiers (i.e., bring
 them into scope).  Some OCP messages destroy them (i.e, remove them

Rousskov Standards Track [Page 28] RFC 4037 OPES Callout Protocol Core March 2005

 from scope).  An OCP agent MUST NOT create the same uni value more
 than once within the same scope.  When creating a new identifier of
 the same type and within the same scope as some old identifier, an
 OCP agent MUST use a higher numerical value for the new identifier.
 The first rule makes uni identifiers suitable for cross-referencing
 logs and other artifacts.  The second rule makes efficient checks of
 the first rule possible.
 For example, a previously used transaction identifier "xid" must not
 be used for a new Transaction Start (TS) message within the same OCP
 transaction, even if a prior Transaction End (TE) message was sent
 for the same transaction.
 An OCP agent MUST terminate the state associated with uni uniqueness
 scope if all unique values have been used up.

10.3. size

 size: extends atom;
 Size is an atom formatted as dec-number and with a value in the [0,
 2147483647] range, inclusive.
 Size value is the number of octets in the associated data chunk.
 OCP Core cannot handle application messages that exceed 2147483647
 octets in size, that require larger sizes as a part of OCP marshaling
 process, or that use sizes with granularity other than 8 bits.  This
 limitation can be addressed by OCP extensions, as hinted in section
 15.1.

10.4. offset

 offset: extends atom;
 Offset is an atom formatted as dec-number and with a value in the [0,
 2147483647] range, inclusive.
 Offset is an octet position expressed in the number of octets
 relative to the first octet of the associated dataflow.  The offset
 of the first data octet has a value of zero.

10.5. percent

 percent: extends atom;
 Percent is an atom formatted as dec-number and with a value in the
 [0, 100] range, inclusive.

Rousskov Standards Track [Page 29] RFC 4037 OPES Callout Protocol Core March 2005

 Percent semantics is incomplete unless its value is associated with a
 boolean statement or assertion.  The value of 0 indicates absolute
 impossibility.  The value of 100 indicates an absolute certainty.  In
 either case, the associated statement can be relied upon as if it
 were expressed in boolean rather than probabilistic terms.  Values in
 the [1,99] inclusive range indicate corresponding levels of certainty
 that the associated statement is true.

10.6. boolean

 boolean: extends atom;
 Boolean type is an atom with two valid values: true and false.  A
 boolean parameter expresses the truthfulness of the associated
 statement.

10.7. xid

 xid: extends uni;
 Xid, an OCP transaction identifier, uniquely identifies an OCP
 transaction within an OCP connection.

10.8. sg-id

 sg-id: extends uni;
 Sg-id, a service group identifier, uniquely identifies a group of
 services on an OCP connection.

10.9. modp

 modp: extends percent;
 Modp extends the percent type to express the sender's confidence that
 application data will be modified.  The boolean statement associated
 with the percentage value is "data will be modified".  Modification
 is defined as adaptation that changes the numerical value of at least
 one data octet.

10.10. result

 result: extends structure with {
         atom [atom];
 };
 The OCP processing result is expressed as a structure with two
 documented members: a required Uni status code and an optional

Rousskov Standards Track [Page 30] RFC 4037 OPES Callout Protocol Core March 2005

 reason.  The reason member contains informative textual information
 not intended for automated processing.  For example:
 { 200 OK }
 { 200 "6:got it" }
 { 200 "27:27 octets in UTF-8 encoding" }
 This specification defines the following status codes:
 Result Status Codes
 +--------+--------------+-------------------------------------------+
 |   code |     text     | semantics                                 |
 +--------+--------------+-------------------------------------------+
 |    200 |      OK      | Overall success.  This specification does |
 |        |              | not contain any general actions for a 200 |
 |        |              | status code recipient.                    |
 |    206 |    partial   | Partial success.  This status code is     |
 |        |              | documented for Application Message End    |
 |        |              | (AME) messages only.  The code indicates  |
 |        |              | that the agent terminated the             |
 |        |              | corresponding dataflow prematurely (i.e., |
 |        |              | more data would be needed to reconstruct  |
 |        |              | a complete application message).          |
 |        |              | Premature termination of one dataflow     |
 |        |              | does not introduce any special            |
 |        |              | requirements for the other dataflow       |
 |        |              | termination.  See dataflow termination    |
 |        |              | optimizations (section 8) for use cases.  |
 |    400 |    failure   | An error, exception, or trouble.  A       |
 |        |              | recipient of a 400 (failure) result of an |
 |        |              | AME, TE, or CE message MUST destroy any   |
 |        |              | state or data associated with the         |
 |        |              | corresponding dataflow, transaction, or   |
 |        |              | connection.  For example, an adapted      |
 |        |              | version of the application message data   |
 |        |              | must be purged from the processor         |
 |        |              | cache if the OPES processor receives an   |
 |        |              | Application Message End (AME) message     |
 |        |              | with result code of 400.                  |
 +--------+--------------+-------------------------------------------+
 Specific OCP messages may require code-specific actions.
 Extending result semantics is made possible by adding new "result"
 structure members or by negotiating additional result codes (e.g., as
 a part of a negotiated profile).  A recipient of an unknown (in

Rousskov Standards Track [Page 31] RFC 4037 OPES Callout Protocol Core March 2005

 then-current context) result code MUST act as if code 400 (failure)
 were received.
 The recipient of a message without the actual result parameter, but
 with an optional formal result parameter, MUST act as if code 200
 (OK) were received.
 Textual information (the second anonymous parameter of the result
 structure) is often referred to as "reason" or "reason phrase".  To
 assist manual troubleshooting efforts, OCP agents are encouraged to
 include descriptive reasons with all results indicating a failure.
 In this specification, an OCP message with result status code of 400
 (failure) is called "a message indicating a failure".

10.11. feature

 feature: extends structure with {
         uri;
 };
 The feature type extends structure to relay an OCP feature identifier
 and to reserve a "place" for optional feature-specific parameters
 (sometimes called feature attributes).  Feature values are used to
 declare support for and to negotiate use of OCP features.
 This specification does not define any features.

10.12. features

 features: extends list of feature;
 Features is a list of feature values.  Unless it is noted otherwise,
 the list can be empty, and features are listed in decreasing
 preference order.

10.13. service

 service: extends structure with {
         uri;
 };
 Service structure has one anonymous member, an OPES service
 identifier of type uri.  Services may have service-dependent
 parameters.  An OCP extension defining a service for use with OCP
 MUST define service identifier and service-dependent parameters, if
 there are any, as additional "service" structure members.  For
 example, a service value may look like this:

Rousskov Standards Track [Page 32] RFC 4037 OPES Callout Protocol Core March 2005

 {"41:http://www.iana.org/assignments/opes/ocp/tls" "8:blowfish"}

10.14. services

 services: extends list of service;
 Services is a list of service values.  Unless it is noted otherwise,
 the list can be empty, and the order of the values is the requested
 or actual service application order.

10.15. Dataflow Specializations

 Several parameter types, such as offset apply to both original and
 adapted dataflow.  It is relatively easy to misidentify a type's
 dataflow affiliation, especially when parameters with different
 affiliations are mixed together in one message declaration.  The
 following statements declare new dataflow-specific types by using
 their dataflow-agnostic versions (denoted by a <type> placeholder).
 The following new types refer to original data only:
 org-<type>: extends <type>;
 The following new types refer to adapted data only:
 adp-<type>: extends <type>;
 The following new types refer to the sender's dataflow only:
 my-<type>: extends <type>;
 The following new types refer to the recipient's dataflow only:
 your-<type>: extends <type>;
 OCP Core uses the above type-naming scheme to implement dataflow
 specialization for the following types: offset, size, and sg-id.  OCP
 extensions SHOULD use the same scheme.

11. Message Definitions

 This section describes specific OCP messages.  Each message is given
 a unique name and usually has a set of anonymous and/or named
 parameters.  The order of anonymous parameters is specified in the
 message definitions below.  No particular order for named parameters
 is implied by this specification.  OCP extensions MUST NOT introduce
 order-dependent named parameters.  No more than one named-parameter

Rousskov Standards Track [Page 33] RFC 4037 OPES Callout Protocol Core March 2005

 with a given name can appear in the message; messages with multiple
 equally named parameters are semantically invalid.
 A recipient MUST be able to parse any message in valid format (see
 section 3.1), subject to the limitations of the recipient's
 resources.
 Unknown or unexpected message names, parameters, and payloads may be
 valid extensions.  For example, an "extra" named parameter may be
 used for a given message, in addition to what is documented in the
 message definition below.  A recipient MUST ignore any valid but
 unknown or unexpected name, parameter, member, or payload.
 Some message parameter values use uni identifiers to refer to various
 OCP states (see section 10.2 and Appendix B).  These identifiers are
 created, used, and destroyed by OCP agents via corresponding
 messages.  Except when creating a new identifier, an OCP agent MUST
 NOT send a uni identifier that corresponds to an inactive state
 (i.e., that was either never created or already destroyed).  Such
 identifiers invalidate the host OCP message (see section 5).  For
 example, the recipient must terminate the transaction when the xid
 parameter in a Data Use Mine (DUM) message refers to an unknown or
 already terminated OCP transaction.

11.1. Connection Start (CS)

 CS: extends message;
 A Connection Start (CS) message indicates the start of an OCP
 connection.  An OCP agent MUST send this message before it sends any
 other message on the connection.  If the first message an OCP agent
 receives is not Connection Start (CS), the agent MUST terminate the
 connection with a Connection End (CE) message having 400 (failure)
 result status code.  An OCP agent MUST send Connection Start (CS)
 message exactly once.  An OCP agent MUST ignore repeated Connection
 Start (CS) messages.
 At any time, a callout server MAY refuse further processing on an OCP
 connection by sending a Connection End (CE) message with the status
 code 400 (failure).  Note that the above requirement to send a CS
 message first still applies.
 With TCP/IP as transport, raw TCP connections (local and remote peer
 IP addresses with port numbers) identify an OCP connection.  Other
 transports may provide OCP connection identifiers to distinguish
 logical connections that share the same transport.  For example, a
 single BEEP [RFC3080] channel may be designated as a single OCP
 connection.

Rousskov Standards Track [Page 34] RFC 4037 OPES Callout Protocol Core March 2005

11.2. Connection End (CE)

 CE: extends message with {
         [result];
 };
 A Connection End (CE) Indicates the end of an OCP connection.  The
 agent initiating closing or termination of a connection MUST send
 this message immediately prior to closing or termination.  The
 recipient MUST free associated state, including transport state.
 Connection termination without a Connection End (CE) message
 indicates that the connection was prematurely closed, possibly
 without the closing-side agent's prior knowledge or intent.  When an
 OCP agent detects a prematurely closed connection, the agent MUST act
 as if a Connection End (CE) message indicating a failure was
 received.
 A Connection End (CE) message implies the end of all transactions,
 negotiations, and service groups opened or active on the connection
 being ended.

11.3. Service Group Created (SGC)

 SGC: extends message with {
         my-sg-id services;
 };
 A Service Group Created (SGC) message informs the recipient that a
 list of adaptation services has been associated with the given
 service group identifier ("my-sg-id").  Following this message, the
 sender can refer to the group by using the identifier.  The recipient
 MUST maintain the association until a matching Service Group
 Destroyed (SGD) message is received or the corresponding OCP
 connection is closed.
 Service groups have a connection scope.  Transaction management
 messages do not affect existing service groups.
 Maintaining service group associations requires resources (e.g.,
 storage to keep the group identifier and a list of service IDs).
 Thus, there is a finite number of associations an implementation can
 maintain.  Callout servers MUST be able to maintain at least one
 association for each OCP connection they accept.  If a recipient of a
 Service Group Created (SGC) message does not create the requested
 association, it MUST immediately terminate the connection with a
 Connection End (CE) message indicating a failure.

Rousskov Standards Track [Page 35] RFC 4037 OPES Callout Protocol Core March 2005

11.4. Service Group Destroyed (SGD)

 SGD: extends message with {
         my-sg-id;
 };
 A Service Group Destroyed (SGD) message instructs the recipient to
 forget about the service group associated with the specified
 identifier.  The recipient MUST destroy the identified service group
 association.

11.5. Transaction Start (TS)

 TS: extends message with {
         xid my-sg-id;
 };
 Sent by an OPES processor, a Transaction Start (TS) message indicates
 the start of an OCP transaction.  Upon receiving this message, the
 callout server MAY refuse further transaction processing by
 responding with a corresponding Transaction End (TE) message.  A
 callout server MUST maintain the state until it receives a message
 indicating the end of the transaction or until it terminates the
 transaction itself.
 The required "my-sg-id" identifier refers to a service group created
 with an a Service Group Created (SGC) message.  The callout server
 MUST apply the list of services associated with "my-sg-id", in the
 specified order.
 This message introduces the transaction identifier (xid).

11.6. Transaction End (TE)

 TE: extends message with {
         xid [result];
 };
 A Transaction End (TE) indicates the end of the identified OCP
 transaction.
 An OCP agent MUST send a Transaction End (TE) message immediately
 after it makes a decision to send no more messages related to the
 corresponding transaction.  Violating this requirement may cause, for

Rousskov Standards Track [Page 36] RFC 4037 OPES Callout Protocol Core March 2005

 example, unnecessary delays, rejection of new transactions, and even
 timeouts for agents that rely on this end-of-file condition to
 proceed.
 This message terminates the life of the transaction identifier (xid).

11.7. Application Message Start (AMS)

 AMS: extends message with {
         xid;
         [Services: services];
 };
 An Application Message Start (AMS) message indicates the start of the
 original or adapted application message processing and dataflow.  The
 recipient MAY refuse further processing by sending an Application
 Message End (AME) message indicating a failure.
 When an AMS message is sent by the OPES processor, the callout server
 usually sends an AMS message back, announcing the creation of an
 adapted version of the original application message.  This
 announcement may be delayed.  For example, the callout server may
 wait for more information from the OPES processor.
 When an AMS message is sent by the callout server, an optional
 "Services" parameter describes OPES services that the server MAY
 apply to the original application message.  Usually, the "services"
 value matches what was asked by the OPES processor.  The callout
 server SHOULD send a "Services" parameter if its value would differ
 from the list of services requested by the OPES processor.  As the
 same service may be known under many names, the mismatch does not
 necessarily imply an error.

11.8. Application Message End (AME)

 AME: extends message with {
         xid [result];
 };
 An Application Message End (AME) message indicates the end of the
 original or adapted application message processing and dataflow.  The
 recipient should expect no more data for the corresponding
 application message.
 An Application Message End (AME) message ends any data preservation
 commitments and any other state associated with the corresponding
 application message.

Rousskov Standards Track [Page 37] RFC 4037 OPES Callout Protocol Core March 2005

 An OCP agent MUST send an Application Message End (AME) message
 immediately after it makes a decision to stop processing of its
 application message.  Violating this requirement may cause, for
 example, unnecessary delays, rejection of new transactions, and even
 timeouts for agents that rely on this end-of-file condition to
 proceed.

11.9. Data Use Mine (DUM)

 DUM: extends message with {
         xid my-offset;
         [As-is: org-offset];
         [Kept: org-offset org-size ];
         [Modp: modp];
 } and payload;
 A Data Use Mine (DUM) message carries application data.  It is the
 only OCP Core message with a documented payload.  The sender MUST NOT
 make any gaps in data supplied by Data Use Mine (DUM) and Data Use
 Yours (DUY) messages (i.e., the my-offset of the next data message
 must be equal to the my-offset plus the payload size of the previous
 data message).  Messages with gaps are invalid.  The sender MUST send
 payload and MAY use empty payload (i.e., payload with zero size).  A
 DUM message without payload is invalid.  Empty payloads are useful
 for communicating meta-information about the data (e.g., modification
 predictions or preservation commitments) without sending data.
 An OPES processor MAY send a "Kept" parameter to indicate its current
 data preservation commitment (section 7) for original data.  When an
 OPES processor sends a "Kept" parameter, the processor MUST keep a
 copy of the specified data (the preservation commitment starts or
 continues).  The Kept offset parameter specifies the offset of the
 first octet of the preserved data.  The Kept size parameter is the
 size of preserved data.  Note that data preservation rules allow
 (i.e., do not prohibit) an OPES processor to decrease offset and to
 specify a data range not yet fully delivered to the callout server.
 OCP Core does not require any relationship between DUM payload and
 the "Kept" parameter.
 If the "Kept" parameter value violates data preservation rules but
 the recipient has not sent any Data Use Yours (DUY) messages for the
 given OCP transaction yet, then the recipient MUST NOT use any
 preserved data for the given transaction (i.e., must not sent any
 Data Use Yours (DUY) messages).  If the "Kept" parameter value
 violates data preservation rules and the recipient has already sent
 Data Use Yours (DUY) messages, the DUM message is invalid, and the
 rules of section 5 apply.  These requirements help preserve data
 integrity when "Kept" optimization is used by the OPES processor.

Rousskov Standards Track [Page 38] RFC 4037 OPES Callout Protocol Core March 2005

 A callout server MUST send a "Modp" parameter if the server can
 provide a reliable value and has not already sent the same parameter
 value for the corresponding application message.  The definition of
 "reliable" is entirely up to the callout server.  The data
 modification prediction includes DUM payload.  That is, if the
 attached payload has been modified, the modp value cannot be 0%.
 A callout server SHOULD send an "As-is" parameter if the attached
 data is identical to a fragment at the specified offset in the
 original dataflow.  An "As-is" parameter specifying a data fragment
 that has not been sent to the callout server is invalid.  The
 recipient MUST ignore invalid "As-is" parameters.  Identical means
 that all adapted octets have the same numeric value as the
 corresponding original octets.  This parameter is meant to allow for
 partial data preservation optimizations without a preservation
 commitment.  The preserved data still crosses the connection with the
 callout server twice, but the OPES processor may be able to optimize
 its handling of the data.
 The OPES processor MUST NOT terminate its data preservation
 commitment (section 7) in reaction to receiving a Data Use Mine (DUM)
 message.

11.10. Data Use Yours (DUY)

 DUY: extends message with {
         xid org-offset org-size;
 };
 The callout server tells the OPES processor to use the "size" bytes
 of preserved original data, starting at the specified offset, as if
 that data chunk came from the callout server in a Data Use Mine (DUM)
 message.
 The OPES processor MUST NOT terminate its data preservation
 commitment (section 7) in reaction to receiving a Data Use Yours
 (DUY) message.

11.11. Data Preservation Interest (DPI)

 DPI: extends message with {
         xid org-offset org-size;
 };
 The Data Preservation Interest (DPI) message describes an original
 data chunk by using the first octet offset and size as parameters.
 The chunk is the only area of original data that the callout server
 may be interested in referring to in future Data Use Yours (DUY)

Rousskov Standards Track [Page 39] RFC 4037 OPES Callout Protocol Core March 2005

 messages.  This data chunk is referred to as "reusable data".  The
 rest of the original data is referred to as "disposable data".  Thus,
 disposable data consists of octets below the specified offset and at
 or above the (offset + size) offset.
 After sending this message, the callout server MUST NOT send Data Use
 Yours (DUY) messages referring to disposable data chunk(s).  If an
 OPES processor is not preserving some reusable data, it MAY start
 preserving that data.  If an OPES processor preserves some disposable
 data, it MAY stop preserving that data.  If an OPES processor does
 not preserve some disposable data, it MAY NOT start preserving that
 data.
 A callout server MUST NOT indicate reusable data areas that overlap
 with disposable data areas indicated in previous Data Preservation
 Interest (DPI) messages.  In other words, reusable data must not
 grow, and disposable data must not shrink.  If a callout server
 violates this rule, the Data Preservation Interest (DPI) message is
 invalid (see section 5).
 The Data Preservation Interest (DPI) message cannot force the OPES
 processor to preserve data.  In this context, the term reusable
 stands for callout server interest in reusing the data in the future,
 given the OPES processor cooperation.
 For example, an offset value of zero and the size value of 2147483647
 indicate that the server may want to reuse all the original data.
 The size value of zero indicates that the server is not going to send
 any more Data Use Yours (DUY) messages.

11.12. Want Stop Receiving Data (DWSR)

 DWSR: extends message with {
         xid org-size;
 };
 The Want Stop Receiving Data (DWSR) message informs OPES processor
 that the callout server wants to stop receiving original data any
 time after receiving at least an org-size amount of an application
 message prefix.  That is, the server is asking the processor to
 terminate original dataflow prematurely (see section 8.1) after
 sending at least org-size octets.
 An OPES processor receiving a Want Stop Receiving Data (DWSR) message
 SHOULD terminate original dataflow by sending an Application Message
 End (AME) message with a 206 (partial) status code.

Rousskov Standards Track [Page 40] RFC 4037 OPES Callout Protocol Core March 2005

 An OPES processor MUST NOT terminate its data preservation commitment
 (section 7) in reaction to receiving a Want Stop Receiving Data
 (DWSR) message.  Just like with any other message, an OPES processor
 may use information supplied by Want Stop Receiving Data (DWSR) to
 decide on future preservation commitments.

11.13. Want Stop Sending Data (DWSS)

 DWSS: extends message with {
         xid;
 };
 The Want Stop Sending Data (DWSS) message informs the OPES processor
 that the callout server wants to stop sending adapted data as soon as
 possible; the server is asking the processor for permission to
 terminate adapted dataflow prematurely (see section 8.2).  The OPES
 processor can grant this permission by using a Stop Sending Data
 (DSS) message.
 Once the DWSS message is sent, the callout server MUST NOT
 prematurely terminate adapted dataflow until the server receives a
 DSS message from the OPES processor.  If the server violates this
 rule, the OPES processor MUST act as if no DWSS message were
 received.  The latter implies that the OCP transaction is terminated
 by the processor, with an error.
 An OPES processor receiving a DWSS message SHOULD respond with a Stop
 Sending Data (DSS) message, provided the processor would not violate
 DSS message requirements by doing so.  The processor SHOULD respond
 immediately once DSS message requirements can be satisfied.

11.14. Stop Sending Data (DSS)

 DSS: extends message with {
         xid;
 };
 The Stop Sending Data (DSS) message instructs the callout server to
 terminate adapted dataflow prematurely by sending an Application
 Message End (AME) message with a 206 (partial) status code.  A
 callout server is expected to solicit the Stop Sending Data (DSS)
 message by sending a Want Stop Sending Data (DWSS) message (see
 section 8.2).
 A callout server receiving a solicited Stop Sending Data (DSS)
 message for a yet-unterminated adapted dataflow MUST immediately
 terminate dataflow by sending an Application Message End (AME)
 message with a 206 (partial) status code.  If the callout server

Rousskov Standards Track [Page 41] RFC 4037 OPES Callout Protocol Core March 2005

 already terminated adapted dataflow, the callout server MUST ignore
 the Stop Sending Data (DSS) message.  A callout server receiving an
 unsolicited DSS message for a yet-unterminated adapted dataflow MUST
 either treat that message as invalid or as solicited (i.e., the
 server cannot simply ignore unsolicited DSS messages).
 The OPES processor sending a Stop Sending Data (DSS) message MUST be
 able to reconstruct the adapted application message correctly after
 the callout server terminates dataflow.  This requirement implies
 that the processor must have access to any original data sent to the
 callout after the Stop Sending Data (DSS) message, if there is any.
 Consequently, the OPES processor either has to send no data at all or
 has to keep a copy of it.
 If a callout server receives a DSS message and, in violation of the
 above rules, waits for more original data before sending an
 Application Message End (AME) response, a deadlock may occur: The
 OPES processor may wait for the Application Message End (AME) message
 to send more original data.

11.15. Want Data Paused (DWP)

 DWP: extends message with {
         xid your-offset;
 };
 The Want Data Paused (DWP) message indicates the sender's temporary
 lack of interest in receiving data starting with the specified
 offset.  This disinterest implies nothing about sender's intent to
 send data.
 The "your-offset" parameter refers to dataflow originating at the OCP
 agent receiving the parameter.
 If, at the time the Want Data Paused (DWP) message is received, the
 recipient has already sent data at the specified offset, the message
 recipient MUST stop sending data immediately.  Otherwise, the
 recipient MUST stop sending data immediately after it sends the
 specified offset.  Once the recipient stops sending more data, it
 MUST immediately send a Paused My Data (DPM) message and MUST NOT
 send more data until it receives a Want More Data (DWM) message.
 As are most OCP Core mechanisms, data pausing is asynchronous.  The
 sender of the Want Data Paused (DWP) message MUST NOT rely on the
 data being paused exactly at the specified offset or at all.

Rousskov Standards Track [Page 42] RFC 4037 OPES Callout Protocol Core March 2005

11.16. Paused My Data (DPM)

 DPM: extends message with {
         xid;
 };
 The Paused My Data (DPM) message indicates the sender's commitment to
 send no more data until the sender receives a Want More Data (DWM)
 message.
 The recipient of the Paused My Data (DPM) message MAY expect the data
 delivery being paused.  If the recipient receives data despite this
 expectation, it MAY abort the corresponding transaction with a
 Transaction End (TE) message indicating a failure.

11.17. Want More Data (DWM)

 DWM: extends message with {
         xid;
         [Size-request: your-size];
 };
 The Want More Data (DWM) message indicates the sender's need for more
 data.
 Message parameters always refer to dataflow originating at the other
 OCP agent.  When sent by an OPES processor, your-size is adp-size;
 when sent by a callout server, your-size is org-size.
 The "Size-request" parameter refers to dataflow originating at the
 OCP agent receiving the parameter.  If a "Size-request" parameter is
 present, its value is the suggested minimum data size.  It is meant
 to allow the recipient to deliver data in fewer chunks.  The
 recipient MAY ignore the "Size-request" parameter.  An absent
 "Size-request" parameter implies "any size".
 The message also cancels the Paused My Data (DPM) message effect.  If
 the recipient was not sending any data because of its DPM message,
 the recipient MAY resume sending data.  Note, however, that the Want
 More Data (DWM) message can be sent regardless of whether the
 dataflow in question has been paused.  The "Size-request" parameter
 makes this message a useful stand-alone optimization.

Rousskov Standards Track [Page 43] RFC 4037 OPES Callout Protocol Core March 2005

11.18. Negotiation Offer (NO)

 NO: extends message with {
         features;
         [SG: my-sg-id];
         [Offer-Pending: boolean];
 };
 A Negotiation Offer (NO) message solicits a selection of a single
 "best" feature out of a supplied list, using a Negotiation Response
 (NR) message.  The sender is expected to list preferred features
 first when it is possible.  The recipient MAY ignore sender
 preferences.  If the list of features is empty, the negotiation is
 bound to fail but remains valid.
 Both the OPES processor and the callout server are allowed to send
 Negotiation Offer (NO) messages.  The rules in this section ensure
 that only one offer is honored if two offers are submitted
 concurrently.  An agent MUST NOT send a Negotiation Offer (NO)
 message if it still expects a response to its previous offer on the
 same connection.
 If an OPES processor receives a Negotiation Offer (NO) message while
 its own offer is pending, the processor MUST disregard the server
 offer.  Otherwise, it MUST respond immediately.
 If a callout server receives a Negotiation Offer (NO) message when
 its own offer is pending, the server MUST disregard its own offer.
 In either case, the server MUST respond immediately.
 If an agent receives a message sequence that violates any of the
 above rules in this section, the agent MUST terminate the connection
 with a Connection End (CE) message indicating a failure.
 An optional "Offer-Pending" parameter is used for Negotiation Phase
 maintenance (section 6.1).  The option's value defaults to "false".
 An optional "SG" parameter is used to narrow the scope of
 negotiations to the specified service group.  If SG is present, the
 negotiated features are negotiated and enabled only for transactions
 that use the specified service group ID.  Connection-scoped features
 are negotiated and enabled for all service groups.  The presence of
 scope does not imply automatic conflict resolution common to
 programming languages; no conflicts are allowed.  When negotiating
 connection-scoped features, an agent MUST check for conflicts within
 each existing service group.  When negotiating group-scoped features,
 an agent MUST check for conflicts with connection-scoped features

Rousskov Standards Track [Page 44] RFC 4037 OPES Callout Protocol Core March 2005

 already negotiated.  For example, it must not be possible to
 negotiate a connection-scoped HTTP application profile if one service
 group already has an SMTP application profile, and vice versa.
 OCP agents SHOULD NOT send offers with service groups used by pending
 transactions.  Unless it is explicitly noted otherwise in a feature
 documentation, OCP agents MUST NOT apply any negotiations to pending
 transactions.  In other words, negotiated features take effect with
 the new OCP transaction.
 As with other protocol elements, OCP Core extensions may document
 additional negotiation restrictions.  For example, specification of a
 transport security feature may prohibit the use of the SG parameter
 in negotiation offers, to avoid situations where encryption is
 enabled for only a portion of overlapping transactions on the same
 transport connection.

11.19. Negotiation Response (NR)

 NR: extends message with {
         [feature];
         [SG: my-sg-id];
         [Rejects: features];
         [Unknowns: features];
         [Offer-Pending: boolean];
 };
 A Negotiation Response (NR) message conveys recipient's reaction to a
 Negotiation Offer (NO) request.  An accepted offer (a.k.a., positive
 response) is indicated by the presence of an anonymous "feature"
 parameter, containing the selected feature.  If the selected feature
 does not match any of the offered features, the offering agent MUST
 consider negotiation failed and MAY terminate the connection with a
 Connection End (CE) message indicating a failure.
 A rejected offer (negative response) is indicated by omitting the
 anonymous "feature" parameter.
 The successfully negotiated feature becomes effective immediately.
 The sender of a positive response MUST consider the corresponding
 feature enabled immediately after the response is sent; the recipient
 of a positive response MUST consider the corresponding feature
 enabled immediately after the response is received.  Note that the
 scope of the negotiated feature application may be limited to a
 specified service group.  The negotiation phase state does not affect
 enabling of the feature.

Rousskov Standards Track [Page 45] RFC 4037 OPES Callout Protocol Core March 2005

 If negotiation offer contains an SG parameter, the responder MUST
 include that parameter in the Negotiation Response (NR) message.  The
 recipient of an NR message without the expected SG parameter MUST
 treat negotiation response as invalid.
 If the negotiation offer lacks an SG parameter, the responder MUST
 NOT include that parameter in the Negotiation Response (NR) message.
 The recipient of an NR message with an unexpected SG parameter MUST
 treat the negotiation response as invalid.
 An optional "Offer-Pending" parameter is used for Negotiation Phase
 maintenance (section 6.1).  The option's value defaults to "false".
 When accepting or rejecting an offer, the sender of the Negotiation
 Response (NR) message MAY supply additional details via Rejects and
 Unknowns parameters.  The Rejects parameter can be used to list
 features that were known to the Negotiation Offer (NO) recipient but
 could not be supported given negotiated state that existed when NO
 message was received.  The Unknowns parameter can be used to list
 features that were unknown to the NO recipient.

11.20. Ability Query (AQ)

 AQ: extends message with {
         feature;
 };
 An Ability Query (AQ) message solicits an immediate Ability Answer
 (AA) response.  The recipient MUST respond immediately with an AA
 message.  This is a read-only, non-modifying interface.  The
 recipient MUST NOT enable or disable any features due to an AQ
 request.
 OCP extensions documenting a feature MAY extend AQ messages to supply
 additional information about the feature or the query itself.
 The primary intended purpose of the ability inquiry interface is
 debugging and troubleshooting and not automated fine-tuning of agent
 behavior and configuration.  The latter may be better achieved by the
 OCP negotiation mechanism (section 6).

11.21. Ability Answer (AA)

 AA: extends message with {
         boolean;
 };

Rousskov Standards Track [Page 46] RFC 4037 OPES Callout Protocol Core March 2005

 An Ability Answer (AA) message expresses the sender's support for a
 feature requested via an Ability Query (AQ) message.  The sender MUST
 set the value of the anonymous boolean parameter to the truthfulness
 of the following statement: "At the time of this answer generation,
 the sender supports the feature in question".  The meaning of
 "support" and additional details are feature specific.  OCP
 extensions documenting a feature MUST document the definition of
 "support" in the scope of the above statement and MAY extend AA
 messages to supply additional information about the feature or the
 answer itself.

11.22. Progress Query (PQ)

 PQ: extends message with {
         [xid];
 };
 A Progress Query (PQ) message solicits an immediate Progress Answer
 (PA) response.  The recipient MUST immediately respond to a PQ
 request, even if the transaction identifier is invalid from the
 recipient's point of view.

11.23. Progress Answer (PA)

 PA: extends message with {
         [xid];
         [Org-Data: org-size];
 };
 A PA message carries the sender's state.  The "Org-Data" size is the
 total original data size received or sent by the agent so far for the
 identified application message (an agent can be either sending or
 receiving original data, so there is no ambiguity).  When referring
 to received data, progress information does not imply that the data
 has otherwise been processed in some way.
 The progress inquiry interface is useful for several purposes,
 including keeping idle OCP connections "alive", gauging the agent
 processing speed, verifying the agent's progress, and debugging OCP
 communications.  Verifying progress, for example, may be essential to
 implement timeouts for callout servers that do not send any adapted
 data until the entire original application message is received and
 processed.
 A recipient of a PA message MUST NOT assume that the sender is not
 working on any transaction or application message not identified in
 the PA message.  A PA message does not carry information about
 multiple transactions or application messages.

Rousskov Standards Track [Page 47] RFC 4037 OPES Callout Protocol Core March 2005

 If an agent is working on the transaction identified in the Progress
 Query (PQ) request, the agent MUST send the corresponding transaction
 ID (xid) when answering the PQ with a PA message.  Otherwise, the
 agent MUST NOT send the transaction ID.  If an agent is working on
 the original application message for the specified transaction, the
 agent MUST send the Org-Data parameter.  If the agent has already
 sent or received the Application Message End (AME) message for the
 original dataflow, the agent MUST NOT send the Org-data parameter.
 Informally, the PA message relays the sender's progress with the
 transaction and original dataflow identified by the Progress Query
 (PQ) message, provided the transaction identifier is still valid at
 the time of the answer.  Absent information in the answer indicates
 invalid, unknown, or closed transaction and/or original dataflow from
 the query recipient's point of view.

11.24. Progress Report (PR)

 PR: extends message with {
         [xid];
         [Org-Data: org-size];
 };
 A Progress Report (PR) message carries the sender's state.  The
 message semantics and associated requirements are identical to those
 of a Progress Answer (PA) message except that the PR message, is sent
 unsolicited.  The sender MAY report progress at any time.  The sender
 MAY report progress unrelated to any transaction or original
 application message or related to any valid (current) transaction or
 original dataflow.
 Unsolicited progress reports are especially useful for OCP extensions
 dealing with "slow" callout services that introduce significant
 delays for the final application message recipient.  The report may
 contain progress information that will make that final recipient more
 delay tolerant.

12. IAB Considerations

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

13. Security Considerations

 This section examines security considerations for OCP.  OPES threats
 are documented in [RFC3837]

Rousskov Standards Track [Page 48] RFC 4037 OPES Callout Protocol Core March 2005

 OCP relays application messages that may contain sensitive
 information.  Appropriate transport encryption can be negotiated to
 prevent information leakage or modification (see section 6), but OCP
 agents may support unencrypted transport by default.  These
 configurations will expose application messages to third-party
 recording and modification, even if OPES proxies themselves are
 secure.
 OCP implementation bugs may lead to security vulnerabilities in OCP
 agents, even if OCP traffic itself remains secure.  For example, a
 buffer overflow in a callout server caused by a malicious OPES
 processor may grant that processor access to information from other
 (100% secure) OCP connections, including connections with other OPES
 processors.
 Careless OCP implementations may rely on various OCP identifiers to
 be unique across all OCP agents.  A malicious agent can inject an OCP
 message that matches identifiers used by other agents, in an attempt
 to gain access to sensitive data.  OCP implementations must always
 check an identifier for being "local" to the corresponding connection
 before using that identifier.
 OCP is a stateful protocol.  Several OCP commands increase the amount
 of state that the recipient has to maintain.  For example, a Service
 Group Created (SGC) message instructs the recipient to maintain an
 association between a service group identifier and a list of
 services.
 Implementations that cannot correctly handle resource exhaustion
 increase security risks.  The following are known OCP-related
 resources that may be exhausted during a compliant OCP message
 exchange:
 OCP message structures: OCP message syntax does not limit the nesting
    depth of OCP message structures and does not place an upper limit
    on the length (number of OCTETs) of most syntax elements.
 concurrent connections: OCP does not place an upper limit on the
    number of concurrent connections that a callout server may be
    instructed to create via Connection Start (CS) messages.
 service groups: OCP does not place an upper limit on the number of
    service group associations that a callout server may be instructed
    to create via Service Group Created (SGC) messages.
 concurrent transactions: OCP does not place an upper limit on the
    number of concurrent transactions that a callout server may be
    instructed to maintain via Transaction Start (TS) messages.

Rousskov Standards Track [Page 49] RFC 4037 OPES Callout Protocol Core March 2005

 concurrent flows: OCP Core does not place an upper limit on the
    number of concurrent adapted flows that an OPES processor may be
    instructed to maintain via Application Message Start (AMS)
    messages.

14. IANA Considerations

 The IANA maintains a list of OCP features, including application
 profiles (section 10.11).  For each feature, its uri parameter value
 is registered along with the extension parameters (if there are any).
 Registered feature syntax and semantics are documented with PETDM
 notation (section 9).
 The IESG is responsible for assigning a designated expert to review
 each standards-track registration prior to IANA assignment.  The OPES
 working group mailing list may be used to solicit commentary for both
 standards-track and non-standards-track features.
 Standards-track OCP Core extensions SHOULD use
 http://www.iana.org/assignments/opes/ocp/ prefix for feature uri
 parameters.  It is suggested that the IANA populate resources
 identified by such "uri" parameters with corresponding feature
 registrations.  It is also suggested that the IANA maintain an index
 of all registered OCP features at the
 http://www.iana.org/assignments/opes/ocp/ URL or on a page linked
 from that URL.
 This specification defines no OCP features for IANA registration.

15. Compliance

 This specification defines compliance for the following compliance
 subjects:  OPES processors (OCP client implementations), callout
 servers (OCP server implementations), and OCP extensions.  An OCP
 agent (a processor or callout server) may also be referred to as the
 "sender" or "recipient" of an OCP message.
 A compliance subject is compliant if it satisfies all applicable
 "MUST" and "SHOULD" requirements.  By definition, to satisfy a "MUST"
 requirement means to act as prescribed by the requirement; to satisfy
 a "SHOULD" requirement means either to act as prescribed by the
 requirement or to have a reason to act differently.  A requirement is
 applicable to the subject if it instructs (addresses) the subject.
 Informally, OCP compliance means that there are no known "MUST"
 violations, and that all "SHOULD" violations are deliberate.  In
 other words, "SHOULD" means "MUST satisfy or MUST have a reason to
 violate".  It is expected that compliance claims be accompanied by a

Rousskov Standards Track [Page 50] RFC 4037 OPES Callout Protocol Core March 2005

 list of unsupported SHOULDs (if any), in an appropriate format,
 explaining why the preferred behavior was not chosen.
 Only normative parts of this specification affect compliance.
 Normative parts are those parts explicitly marked with the word
 "normative", definitions, and phrases containing unquoted capitalized
 keywords from [RFC2119].  Consequently, examples and illustrations
 are not normative.

15.1. Extending OCP Core

 OCP extensions MUST NOT change the OCP Core message format, as
 defined by ABNF and accompanying normative rules in Section 3.1.
 This requirement is intended to allow OCP message viewers,
 validators, and "intermediary" software to at least isolate and
 decompose any OCP message, even a message with semantics unknown to
 them (i.e., extended).
 OCP extensions are allowed to change normative OCP Core requirements
 for OPES processors and callout servers.  However, OCP extensions
 SHOULD NOT make these changes and MUST require on a "MUST"-level that
 these changes are negotiated prior to taking effect.  Informally,
 this specification defines compliant OCP agent behavior until changes
 to this specification (if any) are successfully negotiated.
 For example, if an RTSP profile for OCP requires support for offsets
 exceeding 2147483647 octets, the profile specification can document
 appropriate OCP changes while requiring that RTSP adaptation agents
 negotiate "large offsets" support before using large offsets.  This
 negotiation can be bundled with negotiating another feature (e.g.,
 negotiating an RTSP profile may imply support for "large offsets").
 As implied by the above rules, OCP extensions may dynamically alter
 the negotiation mechanism itself, but such an alternation would have
 to be negotiated first, using the negotiation mechanism defined by
 this specification.  For example, successfully negotiating a feature
 might change the default "Offer-Pending" value from false to true.

Rousskov Standards Track [Page 51] RFC 4037 OPES Callout Protocol Core March 2005

Appendix A. Message Summary

 This appendix is not normative.  The table below summarizes key OCP
 message properties.  For each message, the table provides the
 following information:
 name: Message name as seen on the wire.
 title: Human-friendly message title.
 P: Whether this specification documents message semantics as sent by
    an OPES processor.
 S: Whether this specification documents message semantics as sent by
    a callout server.
 tie: Related messages such as associated request, response message,
    or associated state message.
 +-------+----------------------------+-------+-------+--------------+
 |  name |            title           |   P   |   S   |      tie     |
 +-------+----------------------------+-------+-------+--------------+
 |   CS  |      Connection Start      |   X   |   X   |      CE      |
 |   CE  |       Connection End       |   X   |   X   |      CS      |
 |  SGC  |    Service Group Created   |   X   |   X   |    SGD TS    |
 |  SGD  |   Service Group Destroyed  |   X   |   X   |      SGC     |
 |   TS  |      Transaction Start     |   X   |       |    TE SGC    |
 |   TE  |       Transaction End      |   X   |   X   |      TS      |
 |  AMS  |  Application Message Start |   X   |   X   |      AME     |
 |  AME  |   Application Message End  |   X   |   X   |    AMS DSS   |
 |  DUM  |        Data Use Mine       |   X   |   X   |    DUY DWP   |
 |  DUY  |       Data Use Yours       |       |   X   |    DUM DPI   |
 |  DPI  | Data Preservation Interest |       |   X   |      DUY     |
 |  DWSS |   Want Stop Sending Data   |       |   X   |   DWSR DSS   |
 |  DWSR |  Want Stop Receiving Data  |       |   X   |     DWSS     |
 |  DSS  |      Stop Sending Data     |   X   |       |     DWSS     |
 |  DWP  |      Want Data Paused      |   X   |   X   |      DPM     |
 |  DPM  |       Paused My Data       |   X   |   X   |    DWP DWM   |
 |  DWM  |       Want More Data       |   X   |   X   |      DPM     |
 |   NO  |      Negotiation Offer     |   X   |   X   |    NR SGC    |
 |   NR  |    Negotiation Response    |   X   |   X   |      NO      |
 |   PQ  |       Progress Query       |   X   |   X   |      PA      |
 |   PA  |       Progress Answer      |   X   |   X   |     PQ PR    |
 |   PR  |       Progress Report      |   X   |   X   |      PA      |
 |   AQ  |        Ability Query       |   X   |   X   |      AA      |
 |   AA  |       Ability Answer       |   X   |   X   |      AQ      |
 +-------+----------------------------+-------+-------+--------------+

Rousskov Standards Track [Page 52] RFC 4037 OPES Callout Protocol Core March 2005

Appendix B. State Summary

 This appendix is not normative.  The table below summarizes OCP
 states.  Some states are maintained across multiple transactions and
 application messages.  Some correspond to a single request/response
 dialog; the asynchronous nature of most OCP message exchanges
 requires OCP agents to process other messages while waiting for a
 response to a request and, hence, while maintaining the state of the
 dialog.
 For each state, the table provides the following information:
 state: Short state label.
 birth: Messages creating this state.
 death: Messages destroying this state.
 ID: Associated identifier, if any.
 +-------------------------------+-------------+-------------+-------+
 |             state             | birth       | death       |   ID  |
 +-------------------------------+-------------+-------------+-------+
 |           connection          | CS          | CE          |       |
 |         service group         | SGC         | SGD         | sg-id |
 |          transaction          | TS          | TE          |  xid  |
 |    application message and    | AMS         | AME         |       |
 |            dataflow           |             |             |       |
 |     premature org-dataflow    | DWSR        | AME         |       |
 |          termination          |             |             |       |
 |     premature adp-dataflow    | DWSS        | DSS AME     |       |
 |          termination          |             |             |       |
 |        paused dataflow        | DPM         | DWM         |       |
 |    preservation commitment    | DUM         | DPI AME     |       |
 |          negotiation          | NO          | NR          |       |
 |        progress inquiry       | PQ          | PA          |       |
 |        ability inquiry        | PQ          | PA          |       |
 +-------------------------------+-------------+-------------+-------+

Rousskov Standards Track [Page 53] RFC 4037 OPES Callout Protocol Core March 2005

Appendix C. Acknowledgements

 The author gratefully acknowledges the contributions of Abbie Barbir
 (Nortel Networks), Oskar Batuner (Independent Consultant), Larry
 Masinter (Adobe), Karel Mittig (France Telecom R&D), Markus Hofmann
 (Bell Labs), Hilarie Orman (The Purple Streak), Reinaldo Penno
 (Nortel Networks), and Martin Stecher (Webwasher), as well as an
 anonymous OPES working group participant.
 Special thanks to Marshall Rose for his xml2rfc tool.

16. References

16.1. Normative References

 [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2234]    Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.
 [RFC2396]    Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifiers (URI): Generic Syntax", RFC 2396,
              August 1998.
 [RFC3835]    Barbir, A., Penno, R., Chen, R., Hofmann, M., and H.
              Orman, "An Architecture for Open Pluggable Edge Services
              (OPES)", RFC 3835, August 2004.

16.2. Informative References

 [RFC3836]    Beck, A., Hofmann, M., Orman, H., Penno, R., and A.
              Terzis, "Requirements for Open Pluggable Edge Services
              (OPES) Callout Protocols", RFC 3836, August 2004.
 [RFC3837]    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.
 [RFC3752]    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.
 [RFC3838]    Barbir, A., Batuner, O., Beck, A., Chan, T., and H.
              Orman, "Policy, Authorization, and Enforcement
              Requirements of the Open Pluggable Edge Services
              (OPES)", RFC 3838, August 2004.

Rousskov Standards Track [Page 54] RFC 4037 OPES Callout Protocol Core March 2005

 [RFC3897]    Barbir, A., "Open Pluggable Edge Services (OPES)
              Entities and End Points Communication", RFC 3897,
              September 2004.
 [OPES-RULES] Beck, A. and A. Rousskov, "P: Message Processing
              Language", Work in Progress, October 2003.
 [RFC3914]    Barbir, A. and A. Rousskov, "Open Pluggable Edge
              Services (OPES) Treatment of IAB Considerations", RFC
              3914, October 2004.
 [OPES-HTTP]  Rousskov, A. and M. Stecher, "HTTP adaptation with
              OPES", Work in Progress, January 2004.
 [RFC2616]    Fielding,  R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 [RFC3080]    Rose, M., "The Blocks Extensible Exchange Protocol
              Core", RFC 3080, March 2001.
 [RFC3238]    Floyd, S. and L. Daigle, "IAB Architectural and Policy
              Considerations for Open Pluggable Edge Services", RFC
              3238, January 2002.

Author's Address

 Alex Rousskov
 The Measurement Factory
 EMail: rousskov@measurement-factory.com
 URI:   http://www.measurement-factory.com/

Rousskov Standards Track [Page 55] RFC 4037 OPES Callout Protocol Core March 2005

Full Copyright Statement

 Copyright (C) The Internet Society (2005).
 This document is subject to the rights, licenses and restrictions
 contained in BCP 78, and except as set forth therein, the authors
 retain all their rights.
 This document and the information contained herein are provided on an
 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

 The IETF takes no position regarding the validity or scope of any
 Intellectual Property Rights or other rights that might be claimed to
 pertain to the implementation or use of the technology described in
 this document or the extent to which any license under such rights
 might or might not be available; nor does it represent that it has
 made any independent effort to identify any such rights.  Information
 on the procedures with respect to rights in RFC documents can be
 found in BCP 78 and BCP 79.
 Copies of IPR disclosures made to the IETF Secretariat and any
 assurances of licenses to be made available, or the result of an
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

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

Rousskov Standards Track [Page 56]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4037.txt · Last modified: 2005/03/04 23:54 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki