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

   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.

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.

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

   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.

   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.

   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)

   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.

   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

   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.

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.

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

   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.

   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;
   };

   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.

   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]

   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.

   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

   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.

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      |
   +-------+----------------------------+-------+-------+--------------+

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          |       |
   +-------------------------------+-------------+-------------+-------+

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.

   [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/

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.