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. RFC3080] channel may be designated as a single OCP connection.
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).
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. 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. section 7) in reaction to receiving a Data Use Yours (DUY) message.
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. 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. 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. 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.
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.
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. section 6).
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.
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. RFC3238] are documented in [RFC3914]. 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. 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.
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. 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.
[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. [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. 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- email@example.com. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.