idnits 2.17.1 draft-ietf-opes-ocp-core-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3098. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 3114), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 56 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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 the 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 2004) is 7289 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1364 -- Looks like a reference, but probably isn't: '2147483647' on line 1312 -- Looks like a reference, but probably isn't: '100' on line 1364 -- Looks like a reference, but probably isn't: '1' on line 1371 -- Looks like a reference, but probably isn't: '99' on line 1371 == Unused Reference: 'I-D.ietf-fax-esmtp-conneg' is defined on line 3052, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2396 (Obsoleted by RFC 3986) ** Downref: Normative reference to an Informational draft: draft-ietf-opes-architecture (ref. 'I-D.ietf-opes-architecture') == Outdated reference: A later version (-08) exists of draft-ietf-opes-end-comm-06 == Outdated reference: A later version (-03) exists of draft-ietf-opes-http-02 == Outdated reference: A later version (-13) exists of draft-ietf-fax-esmtp-conneg-09 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Pluggable Edge Services A. Rousskov 3 Internet-Draft The Measurement Factory 4 Expires: November 3, 2004 May 5, 2004 6 OPES Callout Protocol Core 7 draft-ietf-opes-ocp-core-05 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on November 3, 2004. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This document specifies the core of the Open Pluggable Edge Services 40 (OPES) Callout Protocol (OCP). OCP marshals application messages from 41 other communication protocols: an OPES intermediary sends original 42 application messages to a callout server; the callout server sends 43 adapted application messages back to the processor. OCP is designed 44 with typical adaptation tasks in mind (e.g., virus and spam 45 management, language and format translation, message anonymization, 46 or advertisement manipulation). OCP Core defined in this document 47 consists of application-agnostic mechanisms essential for efficient 48 support of typical adaptations. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2 OPES Document Map . . . . . . . . . . . . . . . . . . . . 5 55 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 56 2. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 8 57 2.1 Initialization . . . . . . . . . . . . . . . . . . . . . . 8 58 2.2 Original Dataflow . . . . . . . . . . . . . . . . . . . . 9 59 2.3 Adapted Dataflow . . . . . . . . . . . . . . . . . . . . . 9 60 2.4 Multiple Application Messages . . . . . . . . . . . . . . 9 61 2.5 Termination . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.6 Message Exchange Patterns . . . . . . . . . . . . . . . . 10 63 2.7 Timeouts . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 2.8 Environment . . . . . . . . . . . . . . . . . . . . . . . 11 65 3. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 3.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 12 67 3.2 Message Rendering . . . . . . . . . . . . . . . . . . . . 14 68 3.3 Message Examples . . . . . . . . . . . . . . . . . . . . . 14 69 3.4 Message Names . . . . . . . . . . . . . . . . . . . . . . 15 70 4. Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 5. Invalid Input . . . . . . . . . . . . . . . . . . . . . . . . 16 72 6. Negotiation . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 6.1 Negotiation Phase . . . . . . . . . . . . . . . . . . . . 18 74 6.2 Negotiation Examples . . . . . . . . . . . . . . . . . . . 19 75 7. 'Data Preservation' Optimization . . . . . . . . . . . . . . . 21 76 8. 'Premature Dataflow Termination' Optimizations . . . . . . . . 22 77 8.1 Original Dataflow . . . . . . . . . . . . . . . . . . . . 22 78 8.2 Adapted Dataflow . . . . . . . . . . . . . . . . . . . . . 23 79 8.3 Getting Out Of The Loop . . . . . . . . . . . . . . . . . 25 80 9. Protocol Element Type Declaration Mnemonic (PETDM) . . . . . . 25 81 9.1 Optional Parameters . . . . . . . . . . . . . . . . . . . 28 82 10. Message Parameter Types . . . . . . . . . . . . . . . . . . 28 83 10.1 uri . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 10.2 uni . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 10.3 size . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 86 10.4 offset . . . . . . . . . . . . . . . . . . . . . . . . . . 29 87 10.5 percent . . . . . . . . . . . . . . . . . . . . . . . . . 30 88 10.6 boolean . . . . . . . . . . . . . . . . . . . . . . . . . 30 89 10.7 xid . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 90 10.8 sg-id . . . . . . . . . . . . . . . . . . . . . . . . . . 30 91 10.9 modp . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 92 10.10 result . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 10.11 feature . . . . . . . . . . . . . . . . . . . . . . . . 32 94 10.12 features . . . . . . . . . . . . . . . . . . . . . . . . 32 95 10.13 service . . . . . . . . . . . . . . . . . . . . . . . . 33 96 10.14 services . . . . . . . . . . . . . . . . . . . . . . . . 33 97 10.15 Dataflow Specializations . . . . . . . . . . . . . . . . 33 99 11. Message Definitions . . . . . . . . . . . . . . . . . . . . 34 100 11.1 Connection Start (CS) . . . . . . . . . . . . . . . . . . 34 101 11.2 Connection End (CE) . . . . . . . . . . . . . . . . . . . 35 102 11.3 Service Group Created (SGC) . . . . . . . . . . . . . . . 35 103 11.4 Service Group Destroyed (SGD) . . . . . . . . . . . . . . 36 104 11.5 Transaction Start (TS) . . . . . . . . . . . . . . . . . . 36 105 11.6 Transaction End (TE) . . . . . . . . . . . . . . . . . . . 36 106 11.7 Application Message Start (AMS) . . . . . . . . . . . . . 37 107 11.8 Application Message End (AME) . . . . . . . . . . . . . . 37 108 11.9 Data Use Mine (DUM) . . . . . . . . . . . . . . . . . . . 38 109 11.10 Data Use Yours (DUY) . . . . . . . . . . . . . . . . . . 39 110 11.11 Data Preservation Interest (DPI) . . . . . . . . . . . . 39 111 11.12 Want Stop Receiving Data (DWSR) . . . . . . . . . . . . 40 112 11.13 Want Stop Sending Data (DWSS) . . . . . . . . . . . . . 41 113 11.14 Stop Sending Data (DSS) . . . . . . . . . . . . . . . . 41 114 11.15 Want Data Paused (DWP) . . . . . . . . . . . . . . . . . 42 115 11.16 Paused My Data (DPM) . . . . . . . . . . . . . . . . . . 43 116 11.17 Want More Data (DWM) . . . . . . . . . . . . . . . . . . 43 117 11.18 Negotiation Offer (NO) . . . . . . . . . . . . . . . . . 43 118 11.19 Negotiation Response (NR) . . . . . . . . . . . . . . . 45 119 11.20 Ability Query (AQ) . . . . . . . . . . . . . . . . . . . 46 120 11.21 Ability Answer (AA) . . . . . . . . . . . . . . . . . . 46 121 11.22 Progress Query (PQ) . . . . . . . . . . . . . . . . . . 47 122 11.23 Progress Answer (PA) . . . . . . . . . . . . . . . . . . 47 123 11.24 Progress Report (PR) . . . . . . . . . . . . . . . . . . 48 124 12. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 48 125 13. Security Considerations . . . . . . . . . . . . . . . . . . 48 126 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 127 15. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . 50 128 15.1 Extending OCP Core . . . . . . . . . . . . . . . . . . . . 51 129 A. Message Summary . . . . . . . . . . . . . . . . . . . . . . . 51 130 B. State Summary . . . . . . . . . . . . . . . . . . . . . . . . 52 131 C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 132 D. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 53 133 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 134 16.1 Normative References . . . . . . . . . . . . . . . . . . . . 64 135 16.2 Informative References . . . . . . . . . . . . . . . . . . . 64 136 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 66 137 Intellectual Property and Copyright Statements . . . . . . . . 67 139 1. Introduction 141 The Open Pluggable Edge Services (OPES) architecture 142 [I-D.ietf-opes-architecture], enables cooperative application 143 services (OPES services) between a data provider, a data consumer, 144 and zero or more OPES processors. The application services under 145 consideration analyze and possibly transform application-level 146 messages exchanged between the data provider and the data consumer. 148 The OPES processor can delegate the responsibility of service 149 execution by communicating with callout servers. As described in 150 [I-D.ietf-opes-protocol-reqs], an OPES processor invokes and 151 communicates with services on a callout server by using an OPES 152 callout protocol (OCP). This document specifies the core of that 153 protocol. 155 OCP Core specification documents general, application-independent 156 protocol mechanisms. A separate series of documents describe 157 application-specific aspects of OCP. For example, "HTTP adaptation 158 with OPES" [I-D.ietf-opes-http] describes, in part, how HTTP messages 159 and HTTP meta-information can be communicated over OCP. 161 Section 1.2 provides a brief overview of the entire OPES document 162 collection, including documents describing OPES use cases and 163 security threats. 165 1.1 Scope 167 OCP Core specification documents behavior of OCP agents and 168 requirements for OCP extensions. OCP Core does not contain 169 requirements or mechanisms specific for application protocols being 170 adapted. 172 As an application proxy, OPES processor proxies a single application 173 protocol or converts from one application protocol to another. At the 174 same time, OPES processor may be an OCP client, using OCP to 175 facilitate adaptation of proxied messages at callout servers. It is 176 therefore natural to assume that an OPES processor takes application 177 messages being proxied, marshals them over OCP to callout servers, 178 and then puts the adaptation results back on the wire. However, such 179 an assumption implies that OCP is applied directly to application 180 messages that OPES processor is proxing, which may not be the case. 182 OPES processor scope callout server scope 183 +-----------------+ +-----------------+ 184 | pre-processing | OCP scope | | 185 | +- - - - - - - - - - - - - - - - - - -+ | 186 | iteration | <== ( application data ) ==> | adaptation | 187 | +- - - - - - - - - - - - - - - - - - -+ | 188 | post-processing | | | 189 +-----------------+ +-----------------+ 191 An OPES processor may preprocess (or postprocess) proxied application 192 messages before (or after) they are adapted at callout servers. For 193 example, a processor may take an HTTP response being proxied and pass 194 it as is, along with metadata about the corresponding HTTP 195 connection. Another processor may take an HTTP response, extract its 196 body, and pass that body, along with the content-encoding metadata. 197 Moreover, to perform adaptation, OPES processor may execute several 198 callout services, iterating over several callout servers. Such 199 preprocessing, postprocessing, and iterations make it impossible to 200 rely on any specific relationship between application messages being 201 proxied and application messages being sent to a callout service. 202 Similarly, specific adaptation actions at the callout server are 203 outside of OCP Core scope. 205 This specification does not define or require any specific 206 relationship among application messages being proxied by an OPES 207 processor and application messages being exchanged between an OPES 208 processor and a callout server via OCP. OPES processor usually 209 provides some mapping among these application messages, but 210 processor's specific actions are beyond OCP scope. In other words, 211 this specification is not concerned with the OPES processor role as 212 an application proxy, or as an iterator of callout services. The 213 scope of OCP Core is communication between a single OPES processor 214 and a single callout server. 216 Furthermore, an OPES processor is at liberty to choose which proxied 217 application messages or information about them to send over OCP. All 218 proxied messages on all proxied connections (if connections are 219 defined for a given application protocol), everything on some 220 connections, selected proxied messages, or nothing might be sent over 221 OCP to callout servers. OPES processor and callout server state 222 related to proxied protocols can be relayed over OCP as application 223 message metadata. 225 1.2 OPES Document Map 227 This document belongs to a large set of OPES specifications produced 228 by the IETF OPES Working Group. Familiarity with the overall OPES 229 approach and typical scenarios is often essential when trying to 230 comprehend isolated OPES documents. This section provides an index of 231 OPES documents to assist the reader with finding "missing" 232 information. 234 o The document on "OPES Use Cases and Deployment Scenarios" 235 [I-D.ietf-opes-scenarios] describes a set of services and 236 applications that are considered in scope for OPES and have been 237 used as a motivation and guidance in designing the OPES 238 architecture. 240 o The OPES architecture and common terminology are described in "An 241 Architecture for Open Pluggable Edge Services (OPES)" 242 [I-D.ietf-opes-architecture]. 244 o "Policy, Authorization and Enforcement Requirements of OPES" 245 [I-D.ietf-opes-authorization] outlines requirements and 246 assumptions on the policy framework, without specifying concrete 247 authorization and enforcement methods. 249 o "Security Threats and Risks for OPES" [I-D.ietf-opes-threats] 250 provides OPES risk analysis, without recommending specific 251 solutions. 253 o "OPES Treatment of IAB Considerations" [I-D.ietf-opes-iab] 254 addresses all architecture-level considerations expressed by the 255 IETF Internet Architecture Board (IAB) when the OPES WG was 256 chartered. 258 o At the core of the OPES architecture are the OPES processor and 259 the callout server, two network elements that communicate with 260 each other via an OPES Callout Protocol (OCP). The requirements 261 for such protocol are discussed in "Requirements for OPES Callout 262 Protocols" [I-D.ietf-opes-protocol-reqs]. 264 o This document, OPES Callout Protocol Core, specifies an 265 application agnostic protocol core to be used for the 266 communication between OPES processor and callout server. 268 o "OPES entities and end points communications" 269 [I-D.ietf-opes-end-comm] specifies generic tracing and bypass 270 mechanisms for OPES. 272 o The OCP Core and Communications documents are independent from the 273 application protocol being adapted by OPES entities. Their generic 274 mechanisms have to be complemented by application-specific 275 profiles. "HTTP adaptation with OPES" [I-D.ietf-opes-http] is such 276 an application profile for HTTP. It specifies how 277 application-agnostic OPES mechanisms are to be used and augmented 278 in order to support adaptation of HTTP messages. 280 o Finally, "P: Message Processing Language" [I-D.ietf-opes-rules-p] 281 defines a language for specifying what OPES adaptations (e.g, 282 translation) must be applied to what application messages (e.g., 283 e-mail from bob@example.com). P language is meant for configuring 284 application proxies (OPES processors). 286 1.3 Terminology 288 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 289 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 290 document are to be interpreted as described in [RFC2119]. When used 291 with the normative meanings, these keywords will be all uppercase. 292 Occurrences of these words in lowercase comprise normal prose usage, 293 with no normative implications. 295 OPES processor works with messages from application protocols and may 296 relay information about those application messages to a callout 297 server. OCP is also an application protocol. Thus, protocol elements 298 like "message", "connection", or "transaction" exist in OCP and other 299 application protocols. In this specification, all references to 300 elements from application protocols other than OCP are used with an 301 explicit "application" qualifier. References without the 302 "application" qualifier refer to OCP elements. 304 OCP message: OCP message is a basic unit of communication between an 305 OPES processor and a callout server. Message is a sequence of 306 octets formatted according to syntax rules (Section 3.1). Message 307 semantics is defined in Section 11. 309 application message: An entity defined by OPES processor and callout 310 server negotiation. Usually, the negotiated definition would match 311 the definition from an application protocol (e.g., [RFC2616] 312 definition of an HTTP message). 314 application message data: An opaque sequence of octets representing 315 complete or partial application message. OCP Core does not 316 distinguish application message structure (if any). Application 317 message data may be empty. 319 data: Same as application message data. 321 original Referring to application message flowing from the OPES 322 processor to a callout server. 324 adapted Referring to application message flowing from an OPES callout 325 server to the OPES processor. 327 adaptation: Any kind of access by a callout server, including 328 modification, generation, and copying. For example, translating or 329 logging an SMTP message is adaptation of that application message. 331 agent: Actor for a given communication protocol. OPES processor and 332 callout server are OCP agents. An agent can be referred to as a 333 sender or receiver, depending on its actions in a particular 334 context. 336 immediate: Performing the specified action before reacting to new 337 incoming messages or sending any new messages unrelated to the 338 specified action. 340 OCP extension: A specification extending or adjusting this document 341 for adaptation of an application protocol (a.k.a., application 342 profile, e.g., [I-D.ietf-opes-http]), new OCP functionality (e.g., 343 transport encryption and authentication), and/or new OCP Core 344 version. 346 2. Overall Operation 348 OPES processor may use OPES callout protocol (OCP) to communicate 349 with callout servers. Adaptation using callout services is sometimes 350 called a "bump in the wire" architecture. 352 2.1 Initialization 354 OPES processor establishes transport connections with callout servers 355 for the purpose of exchanging application messages with the callout 356 server(s) using OCP. After a transport-layer connection (usually TCP/ 357 IP) is established, communicating OCP agents exchange Connection 358 Start (CS) messages. Next, OCP features can be negotiated between the 359 processor and the callout server (see Section 6). For example, OCP 360 agents may negotiate transport encryption and application message 361 definition. When enough settings are negotiated, OCP agents may 362 start exchanging application messages. 364 OCP Core provides negotiation and other mechanisms for agents to 365 encrypt OCP connections and authenticate each other. OCP Core does 366 not require OCP connection encryption or agent authentication. 367 Application profiles and other OCP extensions may document and/or 368 require these and other security mechanisms. OCP is expected to be 369 used, in part, in closed environments where trust and privacy are 370 established by means external to OCP. Implementations are expected to 371 demand necessary security features via the OCP Core negotiation 372 mechanism, depending on agent configuration and environment. 374 2.2 Original Dataflow 376 When OPES processor wants to adapt an application message, the OPES 377 processor sends a Transaction Start (TS) message to initiate an OCP 378 transaction dedicated to that application message. The processor then 379 sends an Application Message Start (AMS) message to prepare the 380 callout server for application data that will follow. Once 381 application message scope is established, application data can be 382 sent to the callout server, using Data Use Mine (DUM) and related OCP 383 message(s). All these messages correspond to the original dataflow. 385 2.3 Adapted Dataflow 387 The callout server receives data and metadata sent by the OPES 388 processor (original dataflow). The callout server analyses metadata 389 and adapts data as it comes in. The server usually builds its version 390 of metadata and responds to OPES processor with an Application 391 Message Start (AMS) message. Adapted application message data can be 392 sent next, using Data Use Mine (DUM) OCP message(s). The application 393 message is then announced to be "completed" or "closed" using an 394 Application Message End (AME) message. The transaction may be closed 395 using a Transaction End (TE) message as well. All these messages 396 correspond to adapted data flow. 398 +---------------+ +-------+ 399 | OPES | == (original data flow) ==> |callout| 400 | processor | <== (adapted data flow) === |server | 401 +---------------+ +-------+ 403 The OPES processor receives the adapted application message sent by 404 the callout server. Other OPES processor actions specific to the 405 application message received are out of this specification scope. 407 2.4 Multiple Application Messages 409 OCP Core specifies transactions interface dedicated to exchanging a 410 single original application message and a single adapted application 411 message. Some application protocols may require multiple adapted 412 versions for a single original application message or even multiple 413 original messages to be exchanged as a part of a single OCP 414 transaction. For example, a single original e-mail message may need 415 to be transformed into several e-mail messages, one custom message 416 for each recipient. 418 OCP extensions MAY document mechanisms for exchanging multiple 419 original and/or multiple adapted application messages within a single 420 OCP transaction. 422 2.5 Termination 424 Either OCP agent can terminate application message delivery, 425 transaction, or connection by sending an appropriate OCP message. 426 Usually, the callout server terminates adapted application message 427 delivery and the transaction. Premature and abnormal terminations at 428 arbitrary times are supported. The termination message includes a 429 result description. 431 2.6 Message Exchange Patterns 433 In addition to messages carrying application data, OCP agents may 434 also exchange messages related to their configuration, state, 435 transport connections, application connections, etc. A callout server 436 may remove itself from the application message processing loop. A 437 single OPES processor can communicate with many callout servers and 438 vice versa. Though many OCP exchange patterns do not follow a classic 439 client-server model, it is possible to think of an OPES processor as 440 an "OCP client" and of a callout server as an "OCP server". The OPES 441 architecture document [I-D.ietf-opes-architecture] describes 442 configuration possibilities. 444 The following informal rules illustrate relationships between 445 connections, transactions, OCP messages, and application messages: 447 o An OCP agent may communicate with multiple OCP agents. 448 Communication with multiple OCP agents is outside of this 449 specification scope. 451 o An OPES processor may have multiple concurrent OCP connections to 452 a callout server. Communication over multiple OCP connections is 453 outside of this specification scope. 455 o A connection may carry multiple concurrent transactions. A 456 transaction is always associated with a single connection (i.e., a 457 transaction cannot span multiple concurrent connections). 459 o A connection may carry at most one message at a time, including 460 control messages and transaction-related messages. A message is 461 always associated with a single connection (i.e., a message cannot 462 span multiple concurrent connections). 464 o A transaction is a sequence of messages related to application of 465 a given set of callout services to a single application message. 467 A sequence of transaction messages from an OPES processor to a 468 callout server is called original flow. A sequence of transaction 469 messages from a callout server to an OPES processor is called 470 adapted flow. The two flows may overlap in time. 472 o In OCP Core, a transaction is associated with a single (original) 473 and a single (adapted) application message. OCP Core extensions 474 may extend transaction scope to more application messages. 476 o An application message (adapted or original) is transferred using 477 a sequence of OCP messages. 479 2.7 Timeouts 481 OCP violations, resource limits, external dependencies, and other 482 factors may lead to states when an OCP agent is not receiving 483 required messages from the other OCP agent. OCP Core defines no 484 messages to address such situations. In the absence of any extension 485 mechanism, OCP agents must implement timeouts for OCP operations: an 486 OCP agent MUST forcefully terminate any OCP connection, negotiation, 487 transaction, etc. that is not making progress. This rule covers both 488 dead- and livelock situations. 490 In their implementation, OCP agents MAY rely on transport-level or 491 other external timeouts if such external timeouts are guaranteed to 492 happen for a given OCP operation. Depending on the OCP operation, an 493 agent may benefit from "pinging" the other side using a Progress 494 Query (PQ) message before terminating an OCP transaction or 495 connection. The latter is especially useful for adaptations that may 496 take a long time at the callout server before producing any adapted 497 data. 499 2.8 Environment 501 OCP communication is assumed to usually take place over TCP/IP 502 connections on the Internet (though no default TCP port is assigned 503 to OCP in this specification). This does not preclude OCP from being 504 implemented on top of other transport protocols, or on other 505 networks. High-level transport protocols such as BEEP [RFC3080] may 506 be used. OCP Core requires a reliable and message-order-preserving 507 transport; any protocol that provides such guarantees can be used; 508 the mapping of OCP message structures onto the transport data units 509 of the protocol in question is outside the scope of this 510 specification. 512 OCP Core is application-agnostic. OCP messages can carry 513 application-specific information as payload or as 514 application-specific message parameters. 516 OCP Core overhead in terms of extra traffic on the wire is about 517 100-200 octets per small application message. Pipelining, preview, 518 data preservation, and early termination optimizations as well as 519 as-is encapsulation of application data make fast exchange of 520 application messages possible. 522 3. Messages 524 As defined in Section 1.3, an OCP message is a basic unit of 525 communication between an OPES processor and a callout server. A 526 message is a sequence of octets formatted according to syntax rules 527 (Section 3.1). Message semantics is defined in Section 11. Messages 528 are transmitted on top of OCP transport. 530 OCP messages deal with transport and transaction management as well 531 as application data exchange between a single OPES processor and a 532 single callout server. Some messages can only be emitted by an OPES 533 processor; some only by a callout server; some can be emitted by both 534 OPES processor and callout server. Some messages require responses 535 (one could call such messages "requests"); some can only be used in 536 response to other messages ("responses"); some may be sent without 537 solicitation and/or may not require a response. 539 3.1 Message Format 541 An OCP message consists of a message name followed by optional 542 parameters and payload. The exact message syntax is defined by the 543 following Augmented Backus-Naur Form (ABNF) [RFC2234]: 545 message = name [SP anonym-parameters] 546 [CRLF named-parameters CRLF] 547 [CRLF payload CRLF] 548 ";" CRLF 550 anonym-parameters = value *(SP value) ; space-separated 551 named-parameters = named-value *(CRLF named-value) ; CRLF-separated 552 list-items = value *("," value) ; comma-separated 554 payload = data 556 named-value = name ":" SP value 558 value = structure / list / atom 559 structure = "{" [anonym-parameters] [CRLF named-parameters CRLF] "}" 560 list = "(" [ list-items ] ")" 561 atom = bare-value / quoted-value 563 name = ALPHA *safe-OCTET 564 bare-value = 1*safe-OCTET 565 quoted-value = DQUOTE data DQUOTE 566 data = size ":" OCTET ; n == size 568 safe-OCTET = ALPHA / DIGIT / "-" / "_" 569 size = dec-number ; 0-2147483647 570 dec-number = 1*DIGIT ; no leading zeros or signs 572 Several normative rules accompany the above ABNF: 574 o There is no "implied linear space" (LWS) rule. LWS rules are 575 common to MIME-based grammars, but are not used here. The 576 whitespace syntax is restricted to what is explicitly allowed by 577 the above ABNF. 579 o All protocol elements are case sensitive unless specified 580 otherwise. In particular, message names and parameter names are 581 case sensitive. 583 o Sizes are interpreted as decimal values and cannot have leading 584 zeros. 586 o Sizes do not exceed 2147483647. 588 o The size attribute in a quoted-value encoding specifies the exact 589 number of OCTETs following the column (':') separator. If size 590 OCTETs are not followed by a quote ('"') character, the encoding 591 is syntactically invalid. 593 o Empty quoted-values are encoded as a 4-OCTET sequence "0:". 595 o Any bare-value can be encoded as a quoted-value. A quoted-value is 596 interpreted after the encoding is removed. For example, number 597 1234 can be encoded as four OCTETs 1234 or as eight OCTETs 598 "4:1234", yielding exactly the same meaning. 600 o Unicode UTF-8 is the default encoding. Note that ASCII is a UTF-8 601 subset, and that the syntax prohibits non-ASCII characters outside 602 of the "data" element. 604 Messages violating formatting rules are, by definition, invalid. See 605 Section 5 for rules governing processing of invalid messages. 607 3.2 Message Rendering 609 OCP message samples in this specification and its extensions may not 610 be typeset to depict minor syntactical details of OCP message format. 611 Specifically, SP and CRLF characters are not shown explicitly. No 612 rendering of an OCP message can be used to infer message format. The 613 message format definition above is the only normative source for all 614 implementations. 616 On occasion, an OCP message line exceeds text width allowed by this 617 specification format. A backslash ("\"), a "soft linebreak" 618 character, is used to emphasize a protocol-violating 619 presentation-only linebreak. Bare backslashes are prohibited by OCP 620 syntax. Similarly, a "\r\n" string is sometimes used to emphasize the 621 presence of a CRLF sequence, usually before OCP message payload. 622 Normally, visible end of line corresponds to the CRLF sequence on the 623 wire. 625 The next section (Section 3.3) contains specific OCP message 626 examples, some of which illustrate the above rendering techniques. 628 3.3 Message Examples 630 OCP syntax provides for compact representation of short control 631 messages and required parameters while allowing for parameter 632 extensions. Below are examples of short control messages. The 633 required CRLF sequence at the end of each line is not shown 634 explicitly (see Section 3.2). 636 PQ; 637 TS 1 2; 638 DWM 22; 639 DWP 22 16; 640 x-doit "5:xyzzy"; 641 The above examples contain atomic anonymous parameter values such as 642 number and string constants. OCP messages sometimes use more 643 complicated parameters such as item lists or structures with named 644 values. As both messages below illustrate, structures and lists can 645 be nested: 647 NO ({"28:http://iana.org/assignments/opes/ocp/tls"}); 648 NO ({\ 649 "50:http://iana.org/assignments/opes/ocp/http/response" 650 Optional-Parts: (request-header) 651 },{\ 652 "50:http://iana.org/assignments/opes/ocp/http/response" 653 Optional-Parts: (request-header,request-body) 654 Transfer-Encodings: (chunked) 655 }); 657 Optional parameters and extensions are possible using named 658 parameters approach as illustrated by the following example. The DWM 659 (Section 11.17) message in the example has two anonymous parameters 660 (the last one being an extension) and two named parameters (the last 661 one being an extension). 663 DWM 1 3 664 Size-Request: 16384 665 X-Need-Info: "26:twenty six octet extension"; 667 Finally, any message may have a payload part. For example, the Data 668 Use Mine (DUM) message below carries 8865 octets of raw data. 670 DUM 1 13 671 Modp: 75 672 \r\n 673 8865:... 8865 octets of raw data ...; 675 3.4 Message Names 677 Most OCP messages defined in this specification have short names, 678 formed by abbreviating or compressing a longer but human-friendlier 679 message title. Short names without a central registration system 680 (like this specification or IANA registry) are likely to cause 681 conflicts. Informal protocol extensions should avoid short names. To 682 emphasize what is already defined by message syntax, implementations 683 cannot assume that all message names are very short. 685 4. Transactions 687 An OCP transaction is a logical sequence of OCP messages processing a 688 single original application message. The result of the processing may 689 be zero or more application messages, adapted from the original. A 690 typical transaction consists of two message flows: a flow from the 691 OPES processor to the callout server (sending original application 692 message) and a flow from the callout server to the OPES processor 693 (sending adapted application messages). The number of application 694 messages produced by the callout server and whether the callout 695 server actually modifies original application message may depend on 696 the requested callout service and other factors. The OPES processor 697 or the callout server can terminate the transaction by sending a 698 corresponding message to the other side. 700 An OCP transaction starts with a Transaction Start (TS) message sent 701 by the OPES processor. A transaction ends with the first Transaction 702 End (TE) message sent or received, explicit or implied. a TE message 703 can be sent by either side. Zero or more OCP messages associated with 704 the transaction can be exchanged in between. The figure below 705 illustrates possible message sequence (prefix "P" stands for the OPES 706 processor; prefix "S" stands for the callout server). Some message 707 details are omitted. 709 P: TS 10; 710 P: AMS 10 1; 711 ... processor sending application data to the callout server 712 S: AMS 10 2; 713 ... callout server sending application data to the processor 714 ... processor sending application data to the callout server 715 P: AME 10 1 result; 716 S: AME 10 2 result; 717 P: TE 10 result; 719 5. Invalid Input 721 This specification contains many criteria for valid OCP messages and 722 their parts, including syntax rules, semantics requirements, and 723 relationship to agents state. "Invalid input" in this context means 724 messages or message parts that violate at least one of the normative 725 rules. A message with an invalid part is, by definition, invalid. If 726 an OCP agent resources are exhausted while parsing or interpreting a 727 message, the agent MUST treat the corresponding OCP message as 728 invalid. 730 Unless explicitly allowed otherwise, an OCP agent MUST terminate the 731 transaction if it receives an invalid message with transaction scope 732 and MUST terminate the connection if it receives an invalid message 733 with a connection scope. A terminating agent MUST use the result 734 status code of 400 and MAY specify termination cause information in 735 the result status reason parameter (see Section 10.10). If an OCP 736 agent is unable to determine the scope of an invalid message it 737 received, the agent MUST treat the message as having connection 738 scope. 740 OCP usually deals with optional but invasive application message 741 manipulations where correctness ought to be valued above robustness. 742 For example, a failure to insert or remove certain optional web page 743 content is usually far less disturbing than corrupting (making 744 unusable) the host page while performing that insertion or removal. 745 Most OPES adaptations are high-level in nature, which makes it 746 impossible to automatically assess correctness of adaptations, 747 especially if "robustness guesses" are involved. 749 6. Negotiation 751 The negotiation mechanism allows OCP agents to agree on mutually 752 acceptable set of features, including optional and 753 application-specific behavior as well as OCP extensions. For example, 754 transport encryption, data format, and support for a new message can 755 be negotiated. Negotiation implies intent for a behavioral change. 756 For a related mechanism allowing an agent to query capabilities of 757 its counterpart without changing counterpart's behavior, see Ability 758 Query (AQ) and Ability Answer (AA) message definitions. 760 Most negotiations require at least one round trip time delay. In 761 rare cases when other side's response is not required immediately, 762 negotiation delay can be eliminated, with an inherent risk of an 763 overly optimistic assumption about the negotiation response. 765 A detected violation of negotiation rules leads to OCP connection 766 termination. This design reduces the number of negotiation scenarios 767 resulting in a deadlock when one of the agents is not compliant. 769 Two core negotiation primitives are supported: negotiation offer and 770 negotiation response. A Negotiation Offer (NO) message allows an 771 agent to specify a set of features from which the responder has to 772 select at most one feature it prefers. The selection is sent using a 773 Negotiation Response (NR) message. If the response is positive, both 774 sides assume that the selected feature is in effect immediately (see 775 Section 11.19 for details). If the response is negative, no 776 behavioral changes are assumed. In either case, further offers may 777 follow. 779 Negotiating OCP agents have to take into account prior negotiated 780 (i.e., already enabled) features. OCP agents MUST NOT make and MUST 781 reject offers that would lead to a conflict with already negotiated 782 features. For example, an agent cannot offer an HTTP application 783 profile for a connection that already has SMTP application profile 784 enabled because there would be no way to resolve the conflict for a 785 given transaction. Similarly, once TLSv1 connection encryption is 786 negotiated, an agent must not offer and must reject offers for SSLv2 787 connection encryption (unless a negotiated feature explicitly allows 788 for changing encryption scheme on the fly). 790 Negotiation Offer (NO) messages may be sent by either agent. OCP 791 extensions documenting negotiation MAY assign initiator role to one 792 of the agents, depending on the feature being negotiated. For 793 example, negotiation of transport security feature should be 794 initiated by OPES processors to avoid situations where both agents 795 wait for each other to make an offer. 797 Since either agent may make an offer, two "concurrent" offers may be 798 made at the same time, by the two communicating agents. Unmanaged 799 concurrent offers may lead to a negotiation deadlock. By giving OPES 800 processor a priority, offer handling rules (Section 11.18) ensure 801 that only one offer per OCP connection is honored at a time, and the 802 other concurrent offers are ignored by both agents. 804 6.1 Negotiation Phase 806 A Negotiation Phase is a mechanism to ensure that both agents have a 807 chance to negotiate all features they require before proceeding 808 further. Negotiation Phases have OCP connection scope and do not 809 overlap. For each OCP agent, Negotiation Phase starts with the first 810 Negotiation Offer (NO) message received or the first Negotiation 811 Response (NR) message sent, provided the message is not a part of an 812 already existing Phase. For each OCP agent, Negotiation Phase ends 813 with the first Negotiation Response (NR) message (sent or received) 814 after which the agent expects no more negotiations. Agent 815 expectation rules are defined later in this section. 817 During a Negotiation Phase, an OCP agent MUST NOT send messages other 818 than the following "Negotiation Phase messages": Negotiation Offer 819 (NO), Negotiation Response (NR), Ability Query (AQ), Ability Answer 820 (AA), Progress Query (PQ), Progress Answer (PA), Progress Report 821 (PR), and Connection End (CE). 823 Multiple Negotiation Phases may happen during the lifespan of a 824 single OCP connection. An agent may attempt to start a new 825 Negotiation Phase immediately after the old Phase is over, but it is 826 possible that the other agent will send messages other than 827 "Negotiation Phase messages" before receiving the new Negotiation 828 Offer (NO). The agent that starts a Phase has to be prepared to 829 handle those messages while its offer is reaching the recipient. 831 An OPES processor MUST make a negotiation offer immediately after 832 sending a Connection Start (CS) message. If the OPES processor has 833 nothing to negotiate, the processor MUST send a Negotiation Offer 834 (NO) message with an empty features list. These two rules bootstrap 835 the first Negotiation Phase. Agents are expected to negotiate at 836 least the application profile for OCP Core. Thus, these bootstrapping 837 requirements are unlikely to result in any extra work. 839 Once a Negotiation Phase starts, an agent MUST expect further 840 negotiations if and only if the last NO sent or the last NR received 841 contained a true "Offer-Pending" parameter value. Informally, an 842 agent can keep the phase open by sending true "Offer-Pending" 843 parameters with negotiation offers or responses. Moreover, if there 844 exist a possibility that the agent may need to continue the 845 Negotiation Phase, the agent must send a true "Offer-Pending" 846 parameter. 848 6.2 Negotiation Examples 850 Below is an example of the simplest negotiation possible. The OPES 851 processor is offering nothing and is predictably receiving a 852 rejection. Note that the NR message terminates the Negotiation Phase 853 in this case because neither of the messages contains a true 854 "Offer-Pending" value: 856 P: NO (); 857 S: NR; 859 The next example illustrates how a callout server can force 860 negotiation of a feature that an OPES processor has not negotiated. 861 Note that the server sets the "Offer-Pending" parameter to true when 862 responding to the processor Negotiation Offer (NO) message. The 863 processor chooses to accept the feature: 865 P: NO (); 866 S: NR 867 Offer-Pending: true 868 ; 869 S: NO ({"22:ocp://feature/example/"}) 870 Offer-Pending: false 871 ; 872 P: NR {"22:ocp://feature/example/"}; 874 If the server changes its mind to continue the above negotiations 875 after sending a true "Offer-Pending" value, the server's only option 876 would be send an empty negotiation offer (see the first example 877 above). If the server does nothing instead, the OPES processor would 878 wait for the server and would eventually timeout the connection. 880 The following example shows a dialog with a callout server that 881 insists on two imaginary features to be used: strong transport 882 encryption and use of volatile storage for responses. The server is 883 designed to exchange no sensitive messages until both features are 884 enabled. Naturally, the volatile storage feature has to be negotiated 885 securely. The OPES processor supports one of the strong encryption 886 mechanisms but prefers not to offer (volunteer support for) strong 887 encryption, perhaps for performance reasons. The server has to send a 888 true "Offer-Pending" parameter to get a chance to offer strong 889 encryption (which is successfully negotiated in this case). Any 890 messages sent by either agent after the (only) successful NR response 891 are encrypted with "strongB" encryption scheme. The OPES processor 892 does not understand the volatile storage feature, and the last 893 negotiation fails (over an strongly encrypted transport connection). 895 P: NO ({"29:ocp://example/encryption/weak"}) 896 ; 897 S: NR 898 Offer-Pending: true 899 ; 900 S: NO ({"32:ocp://example/encryption/strongA"},\ 901 {"32:ocp://example/encryption/strongB"}) 902 Offer-Pending: true 903 ; 904 P: NR {"32:ocp://example/encryption/strongB"} 905 ; 906 ... all traffic below is encrypted using strongB ... 907 S: NO ({"31:ocp://example/storage/volatile"}) 908 Offer-Pending: false 909 ; 910 P: NR 911 Unknowns: ({"31:ocp://example/storage/volatile"}) 912 ; 913 S: CSE { 400 "33:lack of VolStore protocol support" } 914 ; 916 The following example from [I-D.ietf-opes-http] illustrates 917 successful HTTP application profile negotiation: 919 P: NO ({"50:http://iana.org/assignments/opes/ocp/http/response" 920 Aux-Parts: (request-header,request-body) 921 }) 922 SG: 5; 923 S: NR {"50:http://iana.org/assignments/opes/ocp/http/response" 924 Aux-Parts: (request-header) 925 Pause-At-Body: 30 926 Wont-Send-Body: 2147483647 927 Content-Encodings: (gzip) 928 } 929 SG: 5; 931 7. 'Data Preservation' Optimization 933 Many adaptations do not require any data modifications (e.g., message 934 logging or blocking). Some adaptations modify only a small portion of 935 application message content (e.g., HTTP cookies filtering or ad 936 insertion). Yet, in many cases, the callout service needs to see 937 complete data. By default, unmodified data would first travel from 938 the OPES processor to the callout server and then back. The "data 939 preservation" optimization in OCP helps to eliminate the return trip 940 if both OCP agents cooperate. Such cooperation is optional: OCP 941 agents MAY support data preservation optimization. 943 To avoid sending unmodified data back, a callout service has to know 944 that the OPES processor has a copy of the data. Since data sizes can 945 be very large and the callout service may not know in advance whether 946 it will be able to utilize the processor copy, it is not possible to 947 require the processor to keep a copy of the entire original data. 948 Instead, it is expected that a processor may keep some portion of the 949 data, depending on processor settings and state. 951 When an OPES processor commits to keeping a data chunk, it announces 952 its decision and the chunk parameters via a Kept parameter of a Data 953 Use Mine (DUM) message. The callout server MAY "use" the chunk by 954 sending a Data Use Yours (DUY) message referring to the preserved 955 chunk. That OCP message does not have payload and, hence, the return 956 trip is eliminated. 958 Since the mapping between original and adapted data is not known to 959 the processor, the processor MUST keep the announced-as-preserved 960 chunk until the end of the corresponding transaction, unless the 961 callout server explicitly tells the processor that the chunk is not 962 needed. As implied by the above requirement, the processor cannot 963 assume that a data chunk is no longer needed just because the callout 964 server sent a Data Use Yours (DUY) message or adapted data with, say, 965 the same offset as the preserved chunk. 967 For simplicity, preserved data is always a contiguous chunk of 968 original data, described by an (offset, size) pair using a "Kept" 969 parameter of a Data Use Mine (DUM) message. An OPES processor may 970 volunteer to increase the size of the kept data. An OPES processor 971 may increase the offset if the callout server indicated that the kept 972 data is no longer needed. 974 Both agents may benefit from data reuse. An OPES processor has to 975 allocate storage to support this optimization while a callout server 976 does not. On the other hand, it is the callout server that is 977 responsible for relieving the processor from data preservation 978 commitments. There is no simple way to resolve this conflict of 979 interest on a protocol level. Some OPES processors may allocate a 980 relatively small buffer for data preservation purposes and stop 981 preserving data when the buffer gets full. Such technique would 982 benefit callout services that can quickly reuse or discard kept data. 983 Another processor strategy would be to size the buffer based on 984 historical data reuse statistics. To improve chances of beneficial 985 cooperation, callout servers are strongly encouraged to immediately 986 notify OPES processors of unwanted data. The callout server that made 987 a decision not to send Data Use Yours (DUY) messages (for a specific 988 data ranges or at all), SHOULD immediately inform the OPES processor 989 of that decision with the corresponding Data Preservation Interest 990 (DPI) message(s) or other mechanisms. 992 8. 'Premature Dataflow Termination' Optimizations 994 Many callout services adapt small portions of large messages and 995 would prefer not to be in the loop when that adaptation is over. Some 996 callout services may not be interested in data modification and would 997 prefer not to send data back to the OPES processor, even if the OPES 998 processor is not supporting the data preservation optimization 999 (Section 7). By OCP design, unilateral premature dataflow termination 1000 by a callout server would lead to termination of an OCP transaction 1001 with an error. Thus, the two agents must cooperate to allow for 1002 error-free premature termination. 1004 This section documents two mechanisms for premature termination of 1005 original or adapted dataflow. In combination, the mechanisms allow 1006 the callout server to get completely out of the processing loop. 1008 8.1 Original Dataflow 1010 There are scenarios when a callout server is not interested in the 1011 remaining original dataflow. For example, a simple access blocking or 1012 "this site is temporary down" callout service needs to send an 1013 adapted (generated) application message, but would prefer not to 1014 receive original data from the OPES processor. 1016 OCP Core supports premature original dataflow termination via the 1017 Want Stop Receiving Data (DWSR) message. A callout server that does 1018 not want to receive additional original data (beyond a certain size) 1019 sends a DWSR message. The OPES processor receiving a DWSR message 1020 terminates original dataflow by sending an Application Message End 1021 (AME) message with a 206 (partial) status code. 1023 The following figure illustrates a typical sequence of events. The 1024 downward lines connecting the two dataflows illustrate the 1025 transmission delay that allows for more OCP messages to be sent while 1026 waiting for the opposing agent reaction. 1028 OPES Callout 1029 Processor Server 1030 DUM> ______/ ... <-- processor stops sending original data 1035 \_____ ______/ ... 1090 \_____ <-- processor resumes original dataflow 1096 DUM> to the server and starts using 1097 ... original data without adapting it 1098 AME> 1100 Premature adapted dataflow preservation is not trivial because the 1101 OPES processor is relying on the callout server to provide adapted 1102 data (modified or not) to construct the adapted application message. 1103 If the callout server wants to quit its job, special care must be 1104 taken to ensure that the OPES processor is capable of constructing 1105 the complete application message. On a logical level, this mechanism 1106 is equivalent to switching from one callout server to another 1107 (non-modifying) callout server in the middle of an OCP transaction. 1109 Other than a possible pause in the original dataflow, the mechanism 1110 described in this section has no effect on the original dataflow. 1111 Receiving an Application Message End (AME) message with 206 (partial) 1112 result status code from the callout server does not introduce any 1113 special requirements for the original dataflow termination. 1115 8.3 Getting Out Of The Loop 1117 Some adaptation services work on application message prefixes and are 1118 not interested in being in the adaptation loop once their work is 1119 done. For example, an ad insertion service that did its job by 1120 modifying the first fragment of a web "page" would not be interested 1121 in receiving more original data or performing further adaptations. 1122 The 'Getting Out Of The Loop' optimization allows a callout server to 1123 get completely out of application message processing loop. 1125 The "Getting Out Of The Loop" optimization is possible by terminating 1126 the adapted dataflow (Section 8.2) and then terminating the original 1127 dataflow (Section 8.1). The order of termination is very important. 1129 If the original dataflow is terminated first, the OPES processor 1130 would not allow the adapted dataflow to be terminated prematurely 1131 because the processor would not be able to reconstruct the remaining 1132 portion of the adapted application message; the processor would not 1133 know which suffix of the remaining original data needs to follow the 1134 adapted parts. The mapping between original and adapted octets is 1135 known only to the callout service. 1137 An OPES processor that received a DWSS message followed by a DWSR 1138 message MUST NOT send an AME message with a 206 (partial) status code 1139 before sending a DSS message. Informally, this rule means that the 1140 callout server that wants to get out of the loop fast should send a 1141 DWSS message immediately followed by a DWSR message; the server does 1142 not need to wait for the OPES processor's permission to terminate 1143 adapted dataflow before requesting the OPES processor to terminate 1144 original dataflow. 1146 9. Protocol Element Type Declaration Mnemonic (PETDM) 1148 A protocol element type is a named set of syntax and semantics rules. 1149 This section defines a simple, formal declaration mnemonic for 1150 protocol element types, labeled PETDM. PETDM simplicity is meant to 1151 ease type declarations in this specification. PETDM formality is 1152 meant to improve interoperability among implementations. Two protocol 1153 elements are supported by PETDM: message parameter values and 1154 messages. 1156 All OCP Core parameter and message types are declared using PETDM. 1157 OCP extensions SHOULD use PETDM when declaring new types. 1159 Atom, list, structure, and message constructs are four available base 1160 types. Their syntax and semantics rules are defined in Section 3.1. 1161 New types can be declared in PETDM to extend base types semantics, 1162 using the following declaration templates. The new semantics rules 1163 are meant to be attached to each declaration using prose text. 1165 Things in angle brackets are template placeholders, to be substituted 1166 with actual type names or parameter name tokens. Square brackets 1167 surround optional elements such as structure members or message 1168 payload. 1170 o Declaring a new atomic type: 1171 : extends atom; 1173 o Declaring a new list with old-type-name items: 1174 : extends list of ; 1175 Unless explicitly noted otherwise, empty lists are valid and have 1176 semantics of a absent parameter value. 1178 o Declaring a new structure with members: 1179 : extends structure with { 1180 [] ...; 1181 : ; 1182 : ; 1183 [: ]; 1184 ... 1185 }; 1186 The new structure may have anonymous members and named members. 1187 Neither group have to exist. Note that it is always possible for 1188 extensions to add more members to old structures without affecting 1189 type semantics because unrecognized members are ignored by 1190 compliant agents. 1192 o Declaring a new message with parameters: 1193 : extends message with { 1194 [] ...; 1195 : ; 1196 : ; 1197 [: ]; 1198 ... 1199 }; 1200 The new type name becomes the message name. Just like when 1201 extending a structure, the new message may have anonymous 1202 parameters and named parameters. Neither group have to exist. 1203 Note that it is always possible for extensions to add more 1204 parameters to old messages without affecting type semantics 1205 because unrecognized parameters are ignored by compliant agents. 1207 o Extending a type with more semantics details: 1209 : extends ; 1211 o Extending a structure- or message-base type: 1212 : extends with { 1213 [] ...; 1214 : ; 1215 : ; 1216 [: ]; 1217 ... 1218 }; 1219 New anonymous members are appended to the anonymous members of 1220 the old type, and new named members are merged with named members 1221 of the old type. 1223 o Extending a message-base type with payload semantics: 1224 : extends with { 1225 ... 1226 } and payload; 1227 Any any OCP message can have payload, but only some message types 1228 have known payload semantics. Like any parameter, payload may be 1229 required or optional. 1231 o Extending type semantics without renaming the type: 1232 : extends ::; 1233 The above template can be used by OCP Core extensions that want 1234 to change the semantics of OCP Core types without renaming them. 1235 This technique is essential for extending OCP messages because 1236 message name is the same as the message type name. For example, an 1237 SMTP profile for OCP might use the following declaration to extend 1238 an Application Message Start (AMS) message with Am-Id, a parameter 1239 defined in that profile: 1241 AMS: extends Core::AMS with { 1242 Am-Id: am-id; 1243 }; 1245 All extended types may be used as a replacement of the types they 1246 extend. For example, a Negotiation Offer (NO) message uses a 1247 parameter of type Features. Features (Section 10.12) is a list of 1248 feature (Section 10.11) items. A Feature is a structure-based type. 1249 An OCP extension (e.g., an HTTP application profile) may extend the 1250 feature type and use a value of that extended type in a negotiation 1251 offer. Recipients that are aware of the extension will recognize 1252 added members in feature items and negotiate accordingly. Other 1253 recipients will ignore them. 1255 OCP Core namespace tag is "Core". OCP extensions that declare types 1256 MUST define their namespace tags (so that other extensions and 1257 documentation can use them in their PETDM declarations). 1259 9.1 Optional Parameters 1261 Anonymous parameters are positional: parameter's position (i.e., the 1262 number of anonymous parameters to the left) is its "name". Thus, when 1263 a structure or message have multiple optional anonymous parameters, 1264 parameters to the right can be used only if all parameters to the 1265 left are present. The following notation: 1267 [name1] [name2] [name3] ... [nameN] 1269 is interpreted as: 1271 [name1 [ name2 [ name3 ... [nameN] ... ]]] 1273 When adding an anonymous parameter to a structure or message that 1274 have optional anonymous parameters, the new parameter has to be 1275 optional, and the new parameter can only be used if all old optional 1276 parameters are in use. Named parameters do not have such limitations 1277 because they are not positional but associative; they are identified 1278 by their explicit and unique names. 1280 10. Message Parameter Types 1282 This section defines parameter value types that are used for message 1283 definitions (Section 11). Before using a parameter value, an OCP 1284 agent MUST check whether the value has the expected type (i.e., 1285 whether it complies with all rules from the type definition). A 1286 single rule violation means that the parameter is invalid. See 1287 Section 5 for rules on processing invalid input. 1289 OCP extensions MAY define their own types. If they do, OCP extensions 1290 MUST define types with exactly one base format and MUST specify type 1291 of every new protocol element they introduce. 1293 10.1 uri 1295 uri: extends atom; 1297 Uri (universal resource identifier) is an atom formatted according to 1298 URI rules in [RFC2396]. 1300 Often, a uri parameter is used as a unique (within a given scope) 1301 identifier. Uni semantics is incomplete without the scope 1302 specification. Many uri parameters are URLs. Unless noted otherwise, 1303 URL identifiers do not imply existence of a serviceable resource at 1304 the location they specify. For example, an HTTP request for an 1305 HTTP-based URI identifier may result in a 404 (Not Found) response. 1307 10.2 uni 1309 uni: extends atom; 1311 Uni (unique numeric identifier) is an atom formatted as dec-number 1312 and with a value in the [0, 2147483647] inclusive range. 1314 A uni parameter is used as a unique (within a given scope) 1315 identifier. Uni semantics is incomplete without the scope 1316 specification. Some OCP messages create identifiers (i.e., bring them 1317 into scope). Some OCP messages destroy them (i.e, remove them from 1318 scope). An OCP agent MUST NOT create the same uni value more than 1319 once within the same scope. When creating a new identifier of the 1320 same type and within the same scope as some old identifier, an OCP 1321 agent MUST use a higher numerical value for the new identifier. The 1322 first rule makes uni identifiers suitable for cross-referencing logs 1323 and other artifacts. The second rule makes efficient checks of the 1324 first rule possible. 1326 For example, a previously used transaction identifier "xid" must not 1327 be used for a new Transaction Start (TS) message within the same OCP 1328 transaction, even if a prior Transaction End (TE) message was sent 1329 for the same transaction. 1331 An OCP agent MUST terminate the state associated with uni uniqueness 1332 scope if all unique values have been used up. 1334 10.3 size 1336 size: extends atom; 1338 Size is an atom formatted as dec-number and with a value in the [0, 1339 2147483647] inclusive range. 1341 Size value is the number of octets in the associated data chunk. 1343 OCP Core cannot handle application messages that exceed 2147483647 1344 octets in size, require larger sizes as a part of OCP marshaling 1345 process, or use sizes with granularity other than 8 bits. This 1346 limitation can be addressed by OCP extensions as hinted in Section 1347 15.1. 1349 10.4 offset 1351 offset: extends atom; 1352 Offset is an atom formatted as dec-number and with a value in the [0, 1353 2147483647] inclusive range. 1355 Offset is an octet position expressed in the number of octets 1356 relative to the first octet of the associated dataflow. The offset of 1357 the first data octet has a value of zero. 1359 10.5 percent 1361 percent: extends atom; 1363 Percent is an atom formatted as dec-number and with a value in the 1364 [0, 100] inclusive range. 1366 Percent semantics is incomplete without associating its value with a 1367 boolean statement or assertion. The value of 0 indicates absolute 1368 impossibility. The value of 100 indicates an absolute certainty. In 1369 either case, the associated statement can be relied upon as if it was 1370 expressed in boolean rather than probabilistic terms. Values in the 1371 [1,99] inclusive range indicate corresponding levels of certainty 1372 that the associated statement is true. 1374 10.6 boolean 1376 boolean: extends atom; 1378 Boolean type is an atom with two valid values: true and false. A 1379 boolean parameter expresses truthfulness of the associated statement. 1381 10.7 xid 1383 xid: extends uni; 1385 "Xid", an OCP transaction identifier, uniquely identifies an OCP 1386 transaction within an OCP connection. 1388 10.8 sg-id 1390 sg-id: extends uni; 1392 "Sg-id", a service group identifier, uniquely identifies a group of 1393 services on an OCP connection. 1395 10.9 modp 1397 modp: extends percent; 1399 Modp extends the percent type to express senders confidence that 1400 application data will be modified. The boolean statement associated 1401 with the percentage value is "data will be modified". Modification is 1402 defined as adaptation that changes numerical value of at least one 1403 data octet. 1405 10.10 result 1407 result: extends structure with { 1408 atom [atom]; 1409 }; 1411 OCP processing result is expressed as a structure with two documented 1412 members: a required Uni status code and an optional reason. The 1413 reason member contains informative textual information not intended 1414 for automated processing. For example, 1416 { 200 OK } 1417 { 200 "6:got it" } 1418 { 200 "27:27 octets in UTF-8 encoding" } 1420 This specification defines the following status codes: 1422 Result Status Codes 1424 +--------+--------------+-------------------------------------------+ 1425 | code | text | semantics | 1426 +--------+--------------+-------------------------------------------+ 1427 | 200 | OK | Overall success. This specification does | 1428 | | | not contain any general actions for 200 | 1429 | | | status code recipients. | 1430 | 206 | partial | Partial success. This status code is | 1431 | | | documented for Application Message End | 1432 | | | (AME) messages only. The code indicates | 1433 | | | that the agent terminated the | 1434 | | | corresponding dataflow prematurely (i.e., | 1435 | | | more data would be needed to reconstruct | 1436 | | | a complete application message). | 1437 | | | Premature termination of one dataflow | 1438 | | | does not introduce any special | 1439 | | | requirements for the other dataflow | 1440 | | | termination. See dataflow termination | 1441 | | | optimizations (Section 8) for use cases. | 1442 | 400 | failure | An error, exception, or trouble. A | 1443 | | | recipient of a 400 (failure) result of an | 1444 | | | AME, TE, or CE message MUST destroy any | 1445 | | | state or data associated with the | 1446 | | | corresponding dataflow, transaction, or | 1447 | | | connection. For example, adapted version | 1448 | | | of the application message data must be | 1449 | | | purged from the processor cache if the | 1450 | | | OPES processor receives an Application | 1451 | | | Message End (AME) message with result | 1452 | | | code of 400. | 1453 +--------+--------------+-------------------------------------------+ 1455 Specific OCP messages may require code-specific actions. 1457 Extending result semantics is possible by adding new "result" 1458 structure members or negotiating additional result codes (e.g., as a 1459 part of a negotiated profile). A recipient of an unknown (in 1460 then-current context) result code MUST act as if code 400 (failure) 1461 was received. 1463 The recipient of a message without the actual result parameter, but 1464 with an optional formal result parameter MUST act as if code 200 (OK) 1465 was received. 1467 Textual information (the second anonymous parameter of the result 1468 structure) is often referred to as "reason" or "reason phrase". To 1469 assist manual troubleshooting efforts, OCP agents are encouraged to 1470 include descriptive reasons with all results indicating a failure. 1472 An OCP message with result status code of 400 (failure) is called "a 1473 message indicating a failure" in this specification. 1475 10.11 feature 1477 feature: extends structure with { 1478 uri; 1479 }; 1481 Feature extends structure to relay an OCP feature identifier and to 1482 reserve a "place" for optional feature-specific parameters (sometimes 1483 called feature attributes). Feature values are used to declare 1484 support for and negotiate use of OCP features. 1486 This specification does not define any features. 1488 10.12 features 1490 features: extends list of feature; 1492 "Features" is a list of "feature" values. Unless noted otherwise, the 1493 list can be empty and features are listed in decreasing preference 1494 order. 1496 10.13 service 1498 service: extends structure with { 1499 uri; 1500 }; 1502 "Service" structure has one anonymous member, an OPES service 1503 identifier of type "uri". Services may have service-dependent 1504 parameters. An OCP extension defining a service for use with OCP MUST 1505 define service identifier and service-dependent parameters as 1506 additional "service" structure members, if any. For example, a 1507 service value may look like this: 1509 {"37:http://iana.org/assignments/opes/ocp/tls" "8:blowfish"} 1511 10.14 services 1513 services: extends list of service; 1515 "Services" is a list of "service" values. Unless noted otherwise, the 1516 list can be empty and the order of the values is the requested or 1517 actual service application order. 1519 10.15 Dataflow Specializations 1521 Several parameter types such as "offset" apply to both original and 1522 adapted dataflow. It is relatively easy to misidentify type's 1523 dataflow affiliation, especially when parameters with different 1524 affiliation are mixed together in one message declaration. The 1525 following statements declare new dataflow-specific types using their 1526 dataflow-agnostic versions (denoted by a placeholder). 1528 The following new types refer to original data only: 1530 org-: extends ; 1532 The following new types refer to adapted data only: 1534 adp-: extends ; 1536 The following new types refer to sender's dataflow only: 1538 my-: extends ; 1540 The following new types refer to recipient's dataflow only: 1542 your-: extends ; 1543 OCP Core specification uses the above type naming scheme to implement 1544 dataflow specialization for the following types: offset, size, and 1545 sg-id. OCP extensions SHOULD use the same scheme. 1547 11. Message Definitions 1549 This section describes specific OCP messages. Each message is given a 1550 unique name and usually has a set of anonymous and/or named 1551 parameters. The order of anonymous parameters is specified in the 1552 message definitions below. No particular order for named parameters 1553 is implied by this specification. OCP extensions MUST NOT introduce 1554 order-dependent named parameters. No more than one named-parameter 1555 with a given name can appear in the message; messages with multiple 1556 equally-named parameters are semantically invalid. 1558 A recipient MUST be able to parse any message in valid format (see 1559 Section 3.1), subject to recipient resources limitations. 1561 Unknown or unexpected message names, parameters, and payloads may be 1562 valid extensions. For example, an "extra" named parameter may be used 1563 for a given message, in addition to what is documented in the message 1564 definition below. A recipient MUST ignore any valid but unknown or 1565 unexpected name, parameter, member, or payload. 1567 Some message parameter values use uni identifiers to refer to various 1568 OCP states (see Section 10.2 and Appendix B). These identifiers are 1569 created, used, and destroyed by OCP agents via corresponding 1570 messages. Except when creating a new identifier, an OCP agent MUST 1571 NOT send a uni identifier that corresponds to an inactive state 1572 (i.e., that was either never created or was already destroyed). Such 1573 identifiers invalidate the host OCP message (see Section 5). For 1574 example, the recipient must terminate the transaction when the xid 1575 parameter in a Data Use Mine (DUM) message refers to an unknown or 1576 already terminated OCP transaction. 1578 11.1 Connection Start (CS) 1580 CS: extends message; 1582 A Connection Start (CS) message indicates the start of an OCP 1583 connection. An OCP agent MUST send this message before any other 1584 message on the connection. If the first message an OCP agent receives 1585 is not Connection Start (CS), the agent MUST terminate the connection 1586 with a Connection End (CE) message having 400 (failure) result status 1587 code. An OCP agent MUST send Connection Start (CS) message exactly 1588 once. An OCP agent MUST ignore repeated Connection Start (CS) 1589 messages. 1591 At any time, a callout server MAY refuse further processing on an OCP 1592 connection by sending a Connection End (CE) message with status code 1593 400 (failure). Note that the above requirement to send a CS message 1594 first still applies. 1596 With TCP/IP as transport, raw TCP connections (local and remote peer 1597 IP addresses with port numbers) identify an OCP connection. Other 1598 transports may provide OCP connection identifiers to distinguish 1599 logical connections that share the same transport. For example, a 1600 single BEEP [RFC3080] channel may be designated as a single OCP 1601 connection. 1603 11.2 Connection End (CE) 1605 CE: extends message with { 1606 [result]; 1607 }; 1609 Connection End (CE) Indicates an end of an OCP connection. The agent 1610 initiating closing or termination of a connection MUST send this 1611 message immediately prior to closing or termination. The recipient 1612 MUST free associated state, including transport state. 1614 Connection termination without a Connection End (CE) message 1615 indicates that the connection was prematurely closed, possibly 1616 without the closing-side agent prior knowledge or intent. When an OCP 1617 agent detects a prematurely closed connection, the agent MUST act as 1618 if a Connection End (CE) message indicating a failure was received. 1620 A Connection End (CE) message implies the end of all transactions, 1621 negotiations, and service groups opened or active on the connection 1622 being ended. 1624 11.3 Service Group Created (SGC) 1626 SGC: extends message with { 1627 my-sg-id services; 1628 }; 1630 An Service Group Created (SGC) message informs the recipient that a 1631 list of adaptation services has been associated with the given 1632 service group identifier ("my-sg-id"). Following this message, the 1633 sender can refer to the group using the identifier. The recipient 1634 MUST maintain the association until a matching Service Group 1635 Destroyed (SGD) message is received or the corresponding OCP 1636 connection is closed. 1638 Service groups have a connection scope. Transaction management 1639 messages do not affect existing service groups. 1641 Maintaining service group associations requires resources (e.g., 1642 storage to keep the group identifier and a list of service IDs). 1643 Thus, there is a finite number of associations an implementation can 1644 maintain. Callout servers MUST be able to maintain at least one 1645 association for each OCP connection they accept. If a recipient of a 1646 Service Group Created (SGC) message does not create the requested 1647 association, it MUST immediately terminate the connection with a 1648 Connection End (CE) message indicating a failure. 1650 11.4 Service Group Destroyed (SGD) 1652 SGD: extends message with { 1653 my-sg-id; 1654 }; 1656 A Service Group Destroyed (SGD) message instructs the recipient to 1657 forget about the service group associated with the specified 1658 identifier. The recipient MUST destroy the identified service group 1659 association. 1661 11.5 Transaction Start (TS) 1663 TS: extends message with { 1664 xid my-sg-id; 1665 }; 1667 Sent by an OPES processor, a TS message indicates the start of an OCP 1668 transaction. Upon receiving of this message, the callout server MAY 1669 refuse further transaction processing by responding with a 1670 corresponding Transaction End (TE) message. A callout server MUST 1671 maintain the state until it receives a message indicating the end of 1672 the transaction or until it terminates the transaction itself. 1674 The required "my-sg-id" identifier refers to a service group created 1675 with a Service Group Created (SGC) message. The callout server MUST 1676 apply the list of services associated with "my-sg-id", in the 1677 specified order. 1679 This message introduces transaction identifier (xid). 1681 11.6 Transaction End (TE) 1683 TE: extends message with { 1684 xid [result]; 1685 }; 1686 Indicates the end of the identified OCP transaction. 1688 An OCP agent MUST send a Transaction End (TE) message immediately 1689 after it makes a decision to send no more messages related to the 1690 corresponding transaction. Violating this requirement may cause, for 1691 example, unnecessary delays, rejection of new transactions, and even 1692 timeouts for agents that rely on this end-of-file condition to 1693 proceed. 1695 This message terminates the life of the transaction identifier (xid). 1697 11.7 Application Message Start (AMS) 1699 AMS: extends message with { 1700 xid; 1701 [Services: services]; 1702 }; 1704 An AMS message indicates the start of the original or adapted 1705 application message processing and dataflow. The recipient MAY refuse 1706 further processing by sending an Application Message End (AME) 1707 message indicating a failure. 1709 When an AMS message is sent by the OPES processor, the callout server 1710 usually sends an AMS message back, announcing the creation of an 1711 adapted version of the original application message. Such 1712 announcement may be delayed. For example, the callout server may wait 1713 for more information to come from the OPES processor. 1715 When an AMS message is sent by the callout server, an optional 1716 "Services" parameter describes OPES services that the server MAY 1717 apply to the original application message. Usually, the "services" 1718 value matches what was asked by the OPES processor. The callout 1719 server SHOULD send a "Services" parameter the parameter value would 1720 differ from the list of services requested by the OPES processor. 1721 Since the same service may be known under many names, the mismatch 1722 does not necessarily imply an error). 1724 11.8 Application Message End (AME) 1726 AME: extends message with { 1727 xid [result]; 1728 }; 1730 An AME message indicates the end of the original or adapted 1731 application message processing and dataflow. The recipient should 1732 expect no more data for the corresponding application message. 1734 An Application Message End (AME) message ends any data preservation 1735 commitments and any other state associated with the corresponding 1736 application message. 1738 An OCP agent MUST send an Application Message End (AME) message 1739 immediately after it makes a decision to stop processing of its 1740 application message. Violating this requirement may cause, for 1741 example, unnecessary delays, rejection of new transactions, and even 1742 timeouts for agents that rely on this end-of-file condition to 1743 proceed. 1745 11.9 Data Use Mine (DUM) 1747 DUM: extends message with { 1748 xid my-offset; 1749 [As-is: org-offset]; 1750 [Kept: org-offset org-size ]; 1751 [Modp: modp]; 1752 } and payload; 1754 A DUM message carries application data. It is the only OCP Core 1755 message with documented payload. The sender MUST NOT make any gaps in 1756 data supplied by Data Use Mine (DUM) and Data Use Yours (DUY) 1757 messages (i.e., the my-offset of the next data message must be equal 1758 to my-offset plus the payload size of the previous data message). 1759 Messages with gaps are invalid. The sender MUST send payload and MAY 1760 use empty payload (i.e., payload with zero size). A DUM message 1761 without payload is invalid. Empty payloads are useful for 1762 communicating meta-information about the data (e.g., modification 1763 predictions or preservation commitments) without sending data. 1765 An OPES processor MAY send a "Kept" parameter to indicate its current 1766 data preservation commitment (Section 7) for original data. When an 1767 OPES processor sends a "Kept" parameter, the processor MUST keep a 1768 copy of the specified data (the preservation commitment starts or 1769 continues). The Kept offset parameter specifies the offset of the 1770 first octet of the preserved data. The Kept size parameter is the 1771 size of preserved data. Note that data preservation rules allow 1772 (i.e., do not prohibit) OPES processor to decrease offset and to 1773 specify a data range not yet fully delivered to the callout server. 1774 OCP Core does not require any relationship between DUM payload and 1775 the "Kept" parameter. 1777 If the "Kept" parameter value violates data preservation rules, but 1778 the recipient has not sent any Data Use Yours (DUY) messages for the 1779 given OCP transaction yet, then the recipient MUST NOT use any 1780 preserved data for the given transaction (i.e., must not sent any 1781 Data Use Yours (DUY) messages). If the "Kept" parameter value 1782 violates data preservation rules, and the recipient has already sent 1783 Data Use Yours (DUY) messages, the DUM message is invalid and the 1784 rules of Section 5 apply. These requirements help preserve data 1785 integrity when "Kept" optimization is used by the OPES processor. 1787 A callout server MUST send a "Modp" parameter if the server can 1788 provide a reliable value and has not already sent the same parameter 1789 value for the corresponding application message. The definition of 1790 "reliable" is entirely up to the callout server. The data 1791 modification prediction includes DUM payload. That is, if attached 1792 payload has been modified, the modp value cannot be 0%. 1794 A callout server SHOULD send an "As-is" parameter if the attached 1795 data is identical to a fragment at the specified offset in the 1796 original dataflow. An "As-is" parameter specifying a data fragment 1797 that have not been sent to the callout server is invalid. The 1798 recipient MUST ignore invalid "As-is" parameters. Identical means 1799 that all adapted octets have the same numeric value as the 1800 corresponding original octets. This parameter is meant to allow for 1801 partial data preservation optimizations without a preservation 1802 commitment. The preserved data still crosses the connection with the 1803 callout server twice, but OPES processor may be able to optimize its 1804 handling of the data. 1806 The OPES processor MUST NOT terminate its data preservation 1807 commitment (Section 7) in reaction to receiving a Data Use Mine (DUM) 1808 message. 1810 11.10 Data Use Yours (DUY) 1812 DUY: extends message with { 1813 xid org-offset org-size; 1814 }; 1816 The callout server tells the OPES processor to use the "size" bytes 1817 of preserved original data starting at the specified offset, as if 1818 that data chunk came from the callout server in a Data Use Mine (DUM) 1819 message. 1821 The OPES processor MUST NOT terminate its data preservation 1822 commitment (Section 7) in reaction to receiving a Data Use Yours 1823 (DUY) message. 1825 11.11 Data Preservation Interest (DPI) 1827 DPI: extends message with { 1828 xid org-offset org-size; 1829 }; 1830 The Data Preservation Interest (DPI) message describes an original 1831 data chunk using the first octet offset and size as parameters. The 1832 chunk is the only area of original data that callout server may be 1833 interested in referring to in future Data Use Yours (DUY) messages. 1834 This data chunk is referred to as "reusable data". The rest of the 1835 original data is referred to as "disposable data". Thus, disposable 1836 data consists of octets below the specified offset and at or above 1837 the (offset+size) offset. 1839 After sending this message, the callout server MUST NOT send Data Use 1840 Yours (DUY) messages referring to disposable data chunk(s). If an 1841 OPES processor is not preserving some reusable data, it MAY start 1842 preserving that data. If the OPES processor preserves some disposable 1843 data, it MAY stop preserving that data. If an OPES processor does not 1844 preserve some disposable data, it MAY NOT start preserving that data. 1846 A callout server MUST NOT indicate reusable data areas that overlap 1847 with disposable data areas indicated in previous Data Preservation 1848 Interest (DPI) messages. In other words, reusable data must not grow 1849 and disposable data must not shrink. If a callout server violates 1850 this rule, the Data Preservation Interest (DPI) message is invalid 1851 (see Section 5). 1853 The Data Preservation Interest (DPI) message cannot force the OPES 1854 processor to preserve data. The term reusable in this context stands 1855 for callout server interest in reusing the data in the future, given 1856 the OPES processor cooperation. 1858 For example, an offset value of zero and the size value of 2147483647 1859 indicates that the server may want to reuse all the original data. 1860 The size value of zero indicates that the server is not going to send 1861 any more Data Use Yours (DUY) messages. 1863 11.12 Want Stop Receiving Data (DWSR) 1865 DWSR: extends message with { 1866 xid org-size; 1867 }; 1869 The Want Stop Receiving Data (DWSR) message informs OPES processor 1870 that the callout server wants to stop receiving original data any 1871 time after receiving at least org-size worth of application message 1872 prefix. That is, the server is asking the processor to terminate 1873 original dataflow prematurely (see Section 8.1) after sending at 1874 least org-size octets. 1876 An OPES processor receiving a Want Stop Receiving Data (DWSR) message 1877 SHOULD terminate original dataflow by sending an Application Message 1878 End (AME) message with a 206 (partial) status code. 1880 An OPES processor MUST NOT terminate its data preservation commitment 1881 (Section 7) in reaction to receiving a Want Stop Receiving Data 1882 (DWSR) message. Just like with any other message, an OPES processor 1883 may use information supplied by Want Stop Receiving Data (DWSR) to 1884 decide on future preservation commitments. 1886 11.13 Want Stop Sending Data (DWSS) 1888 DWSS: extends message with { 1889 xid; 1890 }; 1892 The Want Stop Sending Data (DWSS) message informs OPES processor that 1893 the callout server wants to stop sending adapted data as soon as 1894 possible; the server is asking the processor for a permission to 1895 terminate adapted dataflow prematurely (see Section 8.2). The OPES 1896 processor can grant such a permission using a Stop Sending Data (DSS) 1897 message. 1899 Once the DWSS message is sent, the callout server MUST NOT 1900 prematurely terminate adapted dataflow until the server receives a 1901 DSS message from the OPES processor. If the server violates this 1902 rule, the OPES processor MUST act as if no DWSS message was received. 1903 The latter implies that the OCP transaction is terminated by the 1904 processor, with an error. 1906 An OPES processor receiving a DWSS message SHOULD respond with an 1907 Stop Sending Data (DSS) message, provided the processor would not 1908 violate DSS message requirements by doing so. The processor SHOULD 1909 respond immediately once DSS message requirements can be satisfied. 1911 11.14 Stop Sending Data (DSS) 1913 DSS: extends message with { 1914 xid; 1915 }; 1917 The Stop Sending Data (DSS) message instructs the callout server to 1918 terminate adapted dataflow prematurely by sending an Application 1919 Message End (AME) message with a 206 (partial) status code. A callout 1920 server is expected to solicit the Stop Sending Data (DSS) message by 1921 sending a Want Stop Sending Data (DWSS) message (see Section 8.2). 1923 A callout server receiving a solicited Stop Sending Data (DSS) 1924 message for a yet-unterminated adapted dataflow MUST immediately 1925 terminate dataflow by sending an Application Message End (AME) 1926 message with a 206 (partial) status code. If the callout server 1927 already terminated adapted dataflow, the callout server MUST ignore 1928 the Stop Sending Data (DSS) message. A callout server receiving an 1929 unsolicited DSS message for a yet-unterminated adapted dataflow MUST 1930 either treat that message as invalid or as solicited (i.e., the 1931 server cannot simply ignore unsolicited DSS messages). 1933 The OPES processor sending a Stop Sending Data (DSS) message MUST be 1934 able to correctly reconstruct adapted application message after the 1935 callout server terminates dataflow. This requirement implies that the 1936 processor must have access to any original data sent to the callout 1937 after the Stop Sending Data (DSS) message, if any. Consequently, the 1938 OPES processor has to either send no data at all or keep a copy of 1939 it. 1941 If a callout server receives a DSS message and, in violation of the 1942 above rules, waits for more original data before sending an 1943 Application Message End (AME) response, a deadlock may occur: the 1944 OPES processor may wait for the Application Message End (AME) message 1945 to send more original data. 1947 11.15 Want Data Paused (DWP) 1949 DWP: extends message with { 1950 xid your-offset; 1951 }; 1953 The Want Data Paused (DWP) message indicates sender's temporary lack 1954 of interest in receiving data starting with the specified offset. 1955 This disinterest in receiving data is temporary in nature and implies 1956 nothing about sender's intent to send data. 1958 The "your-offset" parameter refers to dataflow originating at the OCP 1959 agent receiving the parameter. 1961 If, at the time the Want Data Paused (DWP) message was received, the 1962 recipient has already sent data at the specified offset, the message 1963 recipient MUST stop sending data immediately. Otherwise, the 1964 recipient MUST stop sending data immediately after it sends the 1965 specified offset. Once the recipient stops sending more data, it MUST 1966 immediately send a Paused My Data (DPM) message and MUST NOT send 1967 more data until it receives a Want More Data (DWM) message. 1969 As most OCP Core mechanisms, data pausing is asynchronous. The sender 1970 of the Want Data Paused (DWP) message MUST NOT rely on the data being 1971 paused exactly at the specified offset or at all. 1973 11.16 Paused My Data (DPM) 1975 DPM: extends message with { 1976 xid; 1977 }; 1979 The Paused My Data (DPM) message indicates sender's commitment to 1980 send no more data until the sender receives a Want More Data (DWM) 1981 message. 1983 The recipient of the Paused My Data (DPM) message MAY expect the data 1984 delivery being paused. If the recipient receives data despite this 1985 expectation, it MAY abort the corresponding transaction with a 1986 Transaction End (TE) message indicating a failure. 1988 11.17 Want More Data (DWM) 1990 DWM: extends message with { 1991 xid; 1992 [Size-request: your-size]; 1993 }; 1995 The Want More Data (DWM) message indicates sender's need for more 1996 data. 1998 Message parameters always refer to dataflow originating at the other 1999 OCP agent: when sent by an OPES processor, your-size is adp-size; 2000 when sent by a callout server, your-size is org-size. 2002 The "Size-request" parameter refers to dataflow originating at the 2003 OCP agent receiving the parameter. If a "Size-request" parameter is 2004 present, its value is the suggested minimum data size. It is meant to 2005 allow the recipient to deliver data in fewer chunks. The recipient 2006 MAY ignore the "Size-request" parameter. An absent "Size-request" 2007 parameter implies "any size". 2009 The message also cancels the Paused My Data (DPM) message effect. If 2010 the recipient was not sending any data because of its DPM message, 2011 the recipient MAY resume sending data. Note, however, that the Want 2012 More Data (DWM) message can be sent regardless of whether the 2013 dataflow in question has been paused. The "Size-request" parameter 2014 makes this message a useful stand-alone optimization. 2016 11.18 Negotiation Offer (NO) 2017 NO: extends message with { 2018 features; 2019 [SG: my-sg-id]; 2020 [Offer-Pending: boolean]; 2021 }; 2023 A Negotiation Offer (NO) message solicits a selection of a single 2024 "best" feature out of a supplied list, using a Negotiation Response 2025 (NR) message. The sender is expected to list preferred features first 2026 when possible. The recipient MAY ignore sender preferences. If the 2027 list of features is empty, the negotiation is bound to fail but 2028 remains valid. 2030 Both OPES processor and callout server are allowed to send 2031 Negotiation Offer (NO) messages. The rules in this section ensure 2032 that only one offer is honored if two offers are submitted 2033 concurrently. An agent MUST NOT send a Negotiation Offer (NO) message 2034 if it still expects a response to its previous offer on the same 2035 connection. 2037 If an OPES processor receives a Negotiation Offer (NO) message while 2038 its own offer is pending, the processor MUST disregard the server 2039 offer. Otherwise, it MUST respond immediately. 2041 If a callout server receives a Negotiation Offer (NO) message when 2042 its own offer is pending, the server MUST disregard its own offer. 2043 In either case, the server MUST respond immediately. 2045 If an agent receives a message sequence that violates any of the 2046 above rules in this section, the agent MUST terminate the connection 2047 with a Connection End (CE) message indicating a failure. 2049 An optional "Offer-Pending" parameter is used for Negotiation Phase 2050 maintenance (Section 6.1). The option's value defaults to "false". 2052 An optional "SG" parameter is used to narrow the scope of 2053 negotiations to the specified service group. If SG is present, the 2054 negotiated features are negotiated and enabled only for transactions 2055 that use the specified service group ID. Connection-scoped features 2056 are negotiated and enabled for all service groups. The presence of 2057 scope does not imply automatic conflict resolution common to 2058 programming languages; no conflicts are allowed. When negotiating 2059 connection-scoped features, an agent MUST check for conflicts within 2060 each existing service group. When negotiating group-scoped features, 2061 an agent MUST check for conflicts with connection-scoped features 2062 already negotiated. For example, it must not be possible to 2063 negotiate a connection-scoped HTTP application profile if one service 2064 group already has an SMTP application profile and vice versa. 2066 OCP agents SHOULD NOT send offers with service groups used by pending 2067 transactions. Unless explicitly noted otherwise in a feature 2068 documentation, OCP agents MUST NOT apply any negotiations to pending 2069 transactions. In other words, negotiated features take effect with 2070 the new OCP transaction. 2072 As with other protocol elements, OCP Core extensions may document 2073 additional negotiation restrictions. For example, specification of a 2074 transport security feature may prohibit the use of SG parameter in 2075 negotiation offers, to avoid situations where encryption is enabled 2076 for only a portion of overlapping transactions on the same transport 2077 connection. 2079 11.19 Negotiation Response (NR) 2081 NR: extends message with { 2082 [feature]; 2083 [SG: my-sg-id]; 2084 [Rejects: features]; 2085 [Unknowns: features]; 2086 [Offer-Pending: boolean]; 2087 }; 2089 A Negotiation Response (NR) message conveys recipient's reaction to a 2090 Negotiation Offer (NO) request. An accepted offer (a.k.a., positive 2091 response) is indicated by the presence of an anonymous "feature" 2092 parameter, containing the selected feature. If the selected feature 2093 does not match any of the offered features, the offering agent MUST 2094 consider negotiation failed and MAY terminate the connection with a 2095 Connection End (CE) message indicating a failure. 2097 A rejected offer (a.k.a., negative response) is indicated by omitting 2098 the anonymous "feature" parameter. 2100 The successfully negotiated feature becomes effective immediately: 2101 The sender of a positive response MUST consider the corresponding 2102 feature enabled immediately after the response is sent; the recipient 2103 of a positive response MUST consider the corresponding feature 2104 enabled immediately after the response is received. Note that the 2105 scope of the negotiated feature application may be limited to a 2106 specified service group. The negotiation phase state does not affect 2107 enabling of the feature. 2109 If negotiation offer contains an SG parameter, the responder MUST 2110 include that parameter in the Negotiation Response (NR) message. The 2111 recipient of a NR message without the expected SG parameter MUST 2112 treat negotiation response as invalid. 2114 If negotiation offer lacks an SG parameter, the responder MUST NOT 2115 include that parameter in the Negotiation Response (NR) message. The 2116 recipient of a NR message with an unexpected SG parameter MUST treat 2117 negotiation response as invalid. 2119 An optional "Offer-Pending" parameter is used for Negotiation Phase 2120 maintenance (Section 6.1). The option's value defaults to "false". 2122 When accepting or rejecting an offer, the sender of the Negotiation 2123 Response (NR) message MAY supply additional details via Rejects and 2124 Unknowns parameters. The Rejects parameter can be used to list 2125 features that were known to the Negotiation Offer (NO) recipient but 2126 could not be supported given negotiated state that existed when NO 2127 message was received. The Unknowns parameter can be used to list 2128 features that were unknown to the NO recipient. 2130 11.20 Ability Query (AQ) 2132 AQ: extends message with { 2133 feature; 2134 }; 2136 A Ability Query (AQ) message solicits an immediate Ability Answer 2137 (AA) response. The recipient MUST respond immediately with a AA 2138 message. This is a read-only, non-modifying interface. The recipient 2139 MUST NOT enable or disable any features due to an AQ request. 2141 OCP extensions documenting a feature MAY extend AQ messages to supply 2142 additional information about the feature or the query itself. 2144 The primary intended purpose of the ability inquiry interface is 2145 debugging and troubleshooting rather than automated fine-tuning of 2146 agent behavior and configuration. The latter may be better achieved 2147 by the OCP negotiation mechanism (Section 6). 2149 11.21 Ability Answer (AA) 2151 AA: extends message with { 2152 boolean; 2153 }; 2155 A Ability Answer (AA) message expresses senders support for a feature 2156 requested via a Ability Query (AQ) message. The sender MUST set the 2157 value of the anonymous boolean parameter to the truthfulness of the 2158 following statement: "at the time of this answer generation, the 2159 sender supports the feature in question". The meaning of "support" 2160 and additional details are feature-specific. OCP extensions 2161 documenting a feature MUST document the definition of "support" in 2162 the scope of the above statement and MAY extend AA messages to supply 2163 additional information about the feature or the answer itself. 2165 11.22 Progress Query (PQ) 2167 PQ: extends message with { 2168 [xid]; 2169 }; 2171 A Progress Query (PQ) message solicits an immediate Progress Answer 2172 (PA) response. The recipient MUST immediately respond to a PQ 2173 request, even if the transaction identifier is invalid from the 2174 recipient point of view. 2176 11.23 Progress Answer (PA) 2178 PA: extends message with { 2179 [xid]; 2180 [Org-Data: org-size]; 2181 }; 2183 A PA message carries sender's state. The "Org-Data" size is the total 2184 original data size received or sent by the agent so far for the 2185 identified application message (an agent can be either sending or 2186 receiving original data so there is no ambiguity). When referring to 2187 received data, progress information does not imply that the data has 2188 been otherwise processed in some way. 2190 The progress inquiry interface is useful for several purposes, 2191 including keeping idle OCP connections "alive", gauging the agent 2192 processing speed, verifying agent's progress, and debugging OCP 2193 communications. Verifying progress, for example, may be essential to 2194 implement timeouts for callout servers that do not send any adapted 2195 data until the entire original application message is received and 2196 processed. 2198 A recipient of a PA message MUST NOT assume that the sender is not 2199 working on any transaction or application message not identified in 2200 the PA message. A PA message does not carry information about 2201 multiple transactions or application messages. 2203 If an agent is working on the transaction identified in the Progress 2204 Query (PQ) request, the agent MUST send the corresponding transaction 2205 ID (xid) when answering PQ with a PA message. Otherwise, the agent 2206 MUST NOT send the transaction ID. If an agent is working on the 2207 original application message for the specified transaction, the agent 2208 MUST send the Org-Data parameter. Otherwise (i.e., the agent has 2209 already sent or received the Application Message End (AME) message 2210 for the original dataflow), the agent MUST NOT send the Org-data 2211 parameter. 2213 Informally, the PA message relays sender's progress with the 2214 transaction and original dataflow identified by the Progress Query 2215 (PQ) message, provided the transaction identifier is still valid at 2216 the time of the answer. Absent information in the answer indicates 2217 invalid, unknown, or closed transaction and/or original dataflow from 2218 the query recipient point of view. 2220 11.24 Progress Report (PR) 2222 PR: extends message with { 2223 [xid]; 2224 [Org-Data: org-size]; 2225 }; 2227 A PR message carries senders state. The message semantics and 2228 associated requirements are identical to that of a Progress Answer 2229 (PA) message except that the PR message is sent unsolicited. The 2230 sender MAY report progress at any time. The sender MAY report 2231 progress unrelated to any transaction or original application message 2232 or related to any valid (current) transaction or original dataflow. 2234 Unsolicited progress reports are especially useful for OCP extensions 2235 dealing with "slow" callout services that introduce significant 2236 delays for the final application message recipient. The report may 2237 contain progress information that will make that final recipient more 2238 delay-tolerant. 2240 12. IAB Considerations 2242 OPES treatment of IETF Internet Architecture Board (IAB) 2243 considerations [RFC3238] are documented in [I-D.ietf-opes-iab]. 2245 13. Security Considerations 2247 This section examines security considerations for OCP. OPES threats 2248 are documented in [I-D.ietf-opes-threats]. 2250 OCP relays application messages that may contain sensitive 2251 information. Appropriate transport encryption can be negotiated to 2252 prevent information leakage or modification (see Section 6), but OCP 2253 agents may support unencrypted transport by default. Such default 2254 OCP agent configurations will expose application messages to third 2255 party recording and modification, even if OPES proxies themselves are 2256 secure. 2258 OCP implementation bugs may lead to security vulnerabilities in OCP 2259 agents, even if OCP traffic itself remains secure. For example, a 2260 buffer overflow in a callout server caused by a malicious OPES 2261 processor may grant that processor access to information from other 2262 (100% secure) OCP connections, including connections with other OPES 2263 processors. 2265 Careless OCP implementations may rely on various OCP identifiers to 2266 be unique across all OCP agents. A malicious agent can inject an OCP 2267 message that matches identifiers used by other agents, in an attempt 2268 to get access to sensitive data. OCP implementations must always 2269 check an identifier for being "local" to the corresponding connection 2270 before using that identifier. 2272 OCP is a stateful protocol. Several OCP commands increase the amount 2273 of state that the recipient has to maintain. For example, a Service 2274 Group Created (SGC) message instructs the recipient to maintain an 2275 association between a service group identifier and a list of 2276 services. 2278 Implementations that cannot handle resource exhaustion correctly 2279 increase security risks. The following are known OCP-related 2280 resources that may be exhausted during a compliant OCP message 2281 exchange: 2283 OCP message structures: OCP message syntax does not limit the nesting 2284 depth of OCP message structures and does not place an upper limit 2285 on the length (number of OCTETs) of most syntax elements. 2287 concurrent connections: OCP does not place an upper limit on the 2288 number of concurrent connections that a callout server may be 2289 instructed to create via Connection Start (CS) messages. 2291 service groups: OCP does not place an upper limit on the number of 2292 service group associations that a callout server may be instructed 2293 to create via Service Group Created (SGC) messages. 2295 concurrent transactions: OCP does not place an upper limit on the 2296 number of concurrent transactions that a callout server may be 2297 instructed to maintain via Transaction Start (TS) messages. 2299 concurrent flows: OCP Core does not place an upper limit on the 2300 number of concurrent adapted flows that an OPES processor may be 2301 instructed to maintain via Application Message Start (AMS) 2302 messages. 2304 14. IANA Considerations 2306 The IANA maintains a list of OCP features, including application 2307 profiles (Section 10.11). For each feature, its "uri" parameter value 2308 is registered along with the extension parameters (if any). 2309 Registered feature syntax and semantics are documented using PETDM 2310 notation (Section 9). 2312 The IESG is responsible for assigning a designated expert to review 2313 each standards-track registration prior to the IANA making the 2314 assignment. The OPES working group mailing list may be used to 2315 solicit commentary for both standards-track and non-standards-track 2316 features. 2318 Standards-track OCP Core extensions SHOULD use "http://iana.org/ 2319 assignments/opes/ocp/" prefix for feature "uri" parameters. It is 2320 suggested that the IANA populates resources identified by such "uri" 2321 parameters with corresponding feature registrations. It is also 2322 suggested that the IANA maintains an index of all registered OCP 2323 features at http://iana.org/assignments/opes/ocp/ URL or on a page 2324 linked from that URL. 2326 This specification defines no OCP features for IANA registration. 2328 15. Compliance 2330 This specification defines compliance for the following compliance 2331 subjects: OPES processors (OCP client implementations), callout 2332 servers (OCP server implementations), OCP extensions. An OCP agent (a 2333 processor or callout server) may also be referred to as "sender" or 2334 "recipient" of an OCP message. 2336 A compliance subject is compliant if it satisfies all applicable 2337 "MUST" and "SHOULD" level requirements. By definition, to satisfy a 2338 "MUST" level requirement means to act as prescribed by the 2339 requirement; to satisfy a "SHOULD" level requirement means to either 2340 act as prescribed by the requirement or have a reason to act 2341 differently. A requirement is applicable to the subject if it 2342 instructs (addresses) the subject. 2344 Informally, OCP compliance means that there are no known "MUST" 2345 violations, and all "SHOULD" violations are conscious. In other 2346 words, a "SHOULD" means "MUST satisfy or MUST have a reason to 2347 violate". It is expected that compliance claims are accompanied by a 2348 list of unsupported SHOULDs (if any), in an appropriate format, 2349 explaining why preferred behavior was not chosen. 2351 Only normative parts of this specification affect compliance. 2353 Normative parts are: parts explicitly marked using the word 2354 "normative", definitions, and phrases containing unquoted capitalized 2355 keywords from [RFC2119]. Consequently, examples and illustrations are 2356 not normative. 2358 15.1 Extending OCP Core 2360 OCP extensions MUST NOT change OCP Core message format, as defined by 2361 ABNF and accompanying normative rules in Section 3.1. The intent of 2362 this requirement is to allow OCP message viewers, validators, and 2363 "intermediary" software to at least isolate and decompose any OCP 2364 message, even a message with unknown to them (i.e., extended) 2365 semantics. 2367 OCP extensions are allowed to change normative OCP Core requirements 2368 for OPES processors and callout servers. However, OCP extensions 2369 SHOULD NOT make such changes and MUST require on a "MUST"-level that 2370 such changes are negotiated prior to taking effect. Informally, this 2371 specification defines compliant OCP agent behavior until changes to 2372 this specifications (if any) are successfully negotiated. 2374 For example, if an RTSP profile for OCP requires support for offsets 2375 exceeding 2147483647 octets, the profile specification can document 2376 appropriate OCP changes while requiring that RTSP adaptation agents 2377 negotiate "large offsets" support before using large offsets. Such 2378 negotiation can be bundled with negotiating another feature (e.g., 2379 negotiating an RTSP profile may imply support for "large offsets"). 2381 As implied by the above rules, OCP extensions may dynamically alter 2382 the negotiation mechanism itself, but such an alternation would have 2383 to be negotiated first, using the negotiation mechanism defined by 2384 this specification. For example, successfully negotiating a feature 2385 might change the default "Offer-Pending" value from false to true. 2387 Appendix A. Message Summary 2389 This appendix is not normative. The table below summarizes key OCP 2390 message properties. For each message, the table provides the 2391 following information: 2393 name: message name as seen on the wire; 2395 title: human-friendly message title; 2397 P: whether this specification documents message semantics as sent by 2398 an OPES processor; 2400 S: whether this specification documents message semantics as sent by 2401 a callout server; 2403 tie: related messages such as associated request or response message 2404 or associated state message. 2406 +-------+----------------------------+-------+-------+--------------+ 2407 | name | title | P | S | tie | 2408 +-------+----------------------------+-------+-------+--------------+ 2409 | CS | Connection Start | X | X | CE | 2410 | CE | Connection End | X | X | CS | 2411 | SGC | Service Group Created | X | X | SGD TS | 2412 | SGD | Service Group Destroyed | X | X | SGC | 2413 | TS | Transaction Start | X | | TE SGC | 2414 | TE | Transaction End | X | X | TS | 2415 | AMS | Application Message Start | X | X | AME | 2416 | AME | Application Message End | X | X | AMS DSS | 2417 | DUM | Data Use Mine | X | X | DUY DWP | 2418 | DUY | Data Use Yours | | X | DUM DPI | 2419 | DPI | Data Preservation Interest | | X | DUY | 2420 | DWSS | Want Stop Sending Data | | X | DWSR DSS | 2421 | DWSR | Want Stop Receiving Data | | X | DWSS | 2422 | DSS | Stop Sending Data | X | | DWSS | 2423 | DWP | Want Data Paused | X | X | DPM | 2424 | DPM | Paused My Data | X | X | DWP DWM | 2425 | DWM | Want More Data | X | X | DPM | 2426 | NO | Negotiation Offer | X | X | NR SGC | 2427 | NR | Negotiation Response | X | X | NO | 2428 | PQ | Progress Query | X | X | PA | 2429 | PA | Progress Answer | X | X | PQ PR | 2430 | PR | Progress Report | X | X | PA | 2431 | AQ | Ability Query | X | X | AA | 2432 | AA | Ability Answer | X | X | AQ | 2433 +-------+----------------------------+-------+-------+--------------+ 2435 Appendix B. State Summary 2437 This appendix is not normative. The table below summarizes OCP 2438 states. Some states are maintained across multiple transactions and 2439 application messages. Some states correspond to a single request/ 2440 response dialog; asynchronous nature of most OCP message exchanges 2441 requires OCP agents to process other messages while waiting for a 2442 response to a request and, hence, maintaining the state of the 2443 dialog. 2445 For each state, the table provides the following information: 2447 state: short state label 2449 birth: messages creating this state 2451 death: messages destroying this state 2453 ID: associated identifier, if any 2455 +-------------------------------+-------------+-------------+-------+ 2456 | state | birth | death | ID | 2457 +-------------------------------+-------------+-------------+-------+ 2458 | connection | CS | CE | | 2459 | service group | SGC | SGD | sg-id | 2460 | transaction | TS | TE | xid | 2461 | application message and | AMS | AME | | 2462 | dataflow | | | | 2463 | premature org-dataflow | DWSR | AME | | 2464 | termination | | | | 2465 | premature adp-dataflow | DWSS | DSS AME | | 2466 | termination | | | | 2467 | paused dataflow | DPM | DWM | | 2468 | preservation commitment | DUM | DPI AME | | 2469 | negotiation | NO | NR | | 2470 | progress inquiry | PQ | PA | | 2471 | ability inquiry | PQ | PA | | 2472 +-------------------------------+-------------+-------------+-------+ 2474 Appendix C. Acknowledgments 2476 The author gratefully acknowledges the contributions of: Abbie Barbir 2477 (Nortel Networks), Oskar Batuner (Independent Consultant), Larry 2478 Masinter (Adobe), Karel Mittig (France Telecom R&D), Markus Hofmann 2479 (Bell Labs), Hilarie Orman (The Purple Streak), Reinaldo Penno 2480 (Nortel Networks), Martin Stecher (Webwasher) as well as an anonymous 2481 OPES working group participant. 2483 Special thanks to Marshall Rose for his xml2rfc tool. 2485 Appendix D. Change Log 2487 RFC Editor Note: This section is to be removed during the final 2488 publication of the document. 2490 Internal WG revision control ID: $Id: ocp-core.xml,v 1.89 2004/05/05 2491 08:04:36 rousskov Exp $ 2492 2004/05/05 2494 * Disallowed syntax changes for extensions to allow viewers and 2495 other "intermediary" software to "handle" any message the 2496 semantics of which they do not understand. Still allow Core 2497 extensions to change other normative Core requirements, but 2498 replaced the corresponding "MAY change" rule with "SHOULD NOT 2499 change". Polished the section's title. 2501 * Claimed full IPR compliance with RFC 3667 that updated RFC 2026 2502 we used before. 2504 * Upgraded xml2rfc version to 1.23 to claim RFC 3667 compliance, 2505 which caused minor differences in whitespace formatting. 2507 * Fixed formatting (indentation) of several examples. 2509 2004/05/03 2511 * Explicitly and formally required that negotiated features are 2512 effective immediately and polished negotiation example to 2513 reflect that. 2515 * Further clarified that extensions may change Core requirements, 2516 including negotiation mechanisms, as long as all changes are 2517 negotiated first. For example, the first dynamic change to the 2518 negotiation mechanism would have to be negotiated using the 2519 Core negotiation mechanism. 2521 * Informally noted that extensions may add further restrictions 2522 on negotiation semantics. 2524 * Filled IANA Considerations section and changed example URIs to 2525 reflect proposed IANA registration format. 2527 2003/12/15 2529 * Added an OPES Document Map boilerplate. 2531 2003/12/12 2533 * Be explicit about one premature dataflow termination not 2534 affecting the other dataflow termination. 2536 * Editorial changes. 2538 2003/12/11 2540 * Polished Abstract. 2542 * Replaced overlapping DIY and DWOL mechanisms with atomic 2543 mechanisms to terminate original or adapted dataflow that can 2544 be combined to support "Getting Out Of The Data Loop" 2545 optimization. Streamlined related 206 (partial) status code 2546 definition. 2548 * Added namespace tags to PETDM so that extensions can extend 2549 Core messages without renaming them (changing OCP message type 2550 changes its name which is not acceptable for most extensions). 2551 The same technique can be useful for extending Core types when 2552 the extended type is meant to be used everywhere the original 2553 core type was used. 2555 * Renamed "application binding" to "application profile". 2557 * Acknowledged Larry Masinter contribution. Larry reviewed HTTP 2558 Adaptations draft and gave a few very useful comments related 2559 to OCP Core. 2561 * Editorial changes. 2563 2003/12/07 2565 * Be more explicit about absence of OCP connection encryption and 2566 agent authentication requirements in OCP Core. 2568 * Removed application message identifier (am-id). OCP Core now 2569 defaults to single original and adapted messages, leaving it up 2570 to OCP extensions to specify how to distinguish multiple 2571 original or adapted dataflows within the same transaction. HTTP 2572 binding does not need to do that. SMTP binding will need to do 2573 that. 2575 * Editorial changes. 2577 * Added request/response states to State Summary appendix. 2579 2003/11/01 2581 * Simplified/streamlined ping-pong interface: Moved "unsolicited 2582 pong" semantics to a Progress Report (PR) message. Moved 2583 "solicited pong" semantics to a Progress Answer (PA) message. 2584 Renamed Progress Request (ping) to Progress Query (PQ). Renamed 2585 "Progress" parameter to "Org-Data". 2587 * Added informative summaries of OCP messages and states as 2588 appendices. 2590 * Added a requirement for uni values to increase so that agents 2591 can easily enforce uni uniqueness. 2593 * Added Dataflow-specific types for size, offset, am-id, and 2594 sg-id. Resolved several ambiguities in message declarations: 2595 "which am-id should this message use, original or adapted?". 2597 * Renamed Data Interested in Using Yours (DIUY) message to Data 2598 Preservation Interest (DPI). 2600 * Renamed Data Won't Look At Yours (DWLY) message to Ignoring 2601 Your Data (DIY). 2603 * Renamed Data Pause (data-pause) message to Want Data Paused 2604 (DWP). 2606 * Renamed Data Paused (data-paused) message to Paused My Data 2607 (DPM). 2609 * Renamed Data Need (data-need) message to Wont More Data (DWM). 2611 * Renamed Data Want Out (DWO) message to Want Out Of The Data 2612 Loop (DWOL). 2614 2003/10/31 2616 * Changed Kept parameter syntax and clarified/simplified/improved 2617 its semantics. Renamed DWSY message to DIUY and clarified/ 2618 simplified/improved its semantics. All data preservation 2619 interface is now built around a single continues data chunk 2620 that Kept parameter and DIUY message refer to when they need to 2621 specify what is preserved or needs to be. 2623 * Added Negotiation Phase and an optional "Offer-Pending" 2624 parameter to NO and NR messages to ensure that an OCP agent can 2625 negotiate vital features before application data is seen on the 2626 wire. 2628 * Polished dataflow pausing interface and made its support 2629 mandatory. Gave an OPES processor the same abilities to pause/ 2630 resume dataflow that a callout server has. 2632 * Added a Timeouts section, requiring all OCP agents to support 2633 timeouts of some sort. 2635 * Removed data loss to-do item. Extensions would have to take 2636 care of that complication. 2638 2003/10/30 2640 * Merged Capability and State Inquiry mechanisms into a simpler 2641 Ability Query/Answer (AQ/AA) interface. Added a new MUST: OCP 2642 extensions must document what it means to "support" a given 2643 feature they document. The definition is needed for generation 2644 of AA messages. 2646 * Removed DoS attacks against callout service as a security 2647 consideration because its place is in OPES architecture or OPES 2648 security drafts. 2650 * Merged DACK mechanism into a polished ping-pong mechanism. 2652 * Added a new requirement: An OCP application binding 2653 specification MUST document whether multiple adapted versions 2654 of an original message are allowed. 2656 * Declared all OCP messages using PETDM. 2658 * Deleted "Application Protocol Requirements" Section as 2659 essentially unused. 2661 2003/10/28 2663 * Simplified and polished CS message rules. Callout servers MUST 2664 send CS now so that processors can be sure the other end is 2665 talking OCP. 2667 * Made "Type Declaration Mnemonic (TDM)" a top-level section 2668 titled "Protocol Element Type Declaration Mnemonic (PETDM)" and 2669 documented OCP message declaration mnemonic. 2671 * Merged parameter type declarations with parameter declarations. 2673 * Polished parameter type declarations. 2675 2003/10/26 2677 * Started using TDM for Core value types. 2679 * Added Data Want Out (DWO) message. 2681 * Added Data Wont Look at Yours (DWLY) message. 2683 * Renamed Wont-Use to more specific Wont-Send. Made Wont-Send 2684 parameter into a Data Wont Send Yours (DWSY) message because it 2685 controls original dataflow and is not specific to a particular 2686 adapted AM (there can be many). This change means that Data Use 2687 Yours (DUY) messages are no longer terminating preservation 2688 commitment by default. Thus, we lost a little in terms of 2689 performance (unless processors look ahead for DWSYs) but gained 2690 a lot of simplicity in terms of support for multiple adapted 2691 application messages (SMTP case). 2693 * Added 206 (partial data) status code definition. 2695 * 206 status code should be used with AME, not TE. 2697 * Replaced "global scope" with "connection scope" in negotiation 2698 rules. 2700 2003/10/25 2702 * Clarified negotiation mechanism when it comes to negotiating 2703 multiple [possibly conflicting] features. 2705 * Clarified service group-scoped negotiations. Agents must watch 2706 out for global conflicts when doing group-scoped negotiations 2707 and vice-versa. 2709 2003/10/24 2711 * Added 'Out Of The Loop' Optimization section. 2713 * Added 'Data Recycling' Optimization section. 2715 * Added "Type Declaration Mnemonic" (TDM) to facilitate type 2716 declarations here and in OCP extensions. 2718 2003/10/19 2720 * Removed optional "sizep" parameter. HTTP needs 2721 content-dependent parameter (AM-EL), and we do not know any 2722 generic application for sizep that would be worth supporting in 2723 Core. 2725 2003/10/08 2727 * Documented backslash (\) and CRLF (\r\n) OCP message rendering 2728 tricks. 2730 2003/10/07 2732 * Added named structure members to message BNF. Used MIME-like 2733 syntax already used for named parameters. Named members are 2734 needed to represent optional structure members. 2736 head-sid15 2738 * Removed leftovers of data-have message name. Use Data Use Mine 2739 instead (Karel Mittig). 2741 * Anonymized named parameters and removed currently unused "rid" 2742 parameter in ping and pong messages (Karel Mittig). 2744 * Renamed DUM.please-ack to "DUM.ack" (Karel Mittig). More work 2745 is needed to polish and simplify acknowledgment mechanism. 2747 head-sid14 2749 * Documented known resource-exhaustion security risks. 2751 * Polished compliance definition. Avoid two levels of compliance. 2753 head-sid13 2755 * Added SG parameter to Negotiation Offer (NO) and Negotiation 2756 Response (NR) messages to limit the result of negotiations to 2757 the specified service group. Still need to document SG-related 2758 logic in the Negotiation section. 2760 * Removed "services" parameter from Transaction Start (TS) 2761 message because we have to rely on service groups exclusively, 2762 because only service groups can have negotiated application 2763 profiles associated with them. 2765 * Replaced data-id parameter with "Kept: kept-offset" and 2766 "Wont-Use: used-size" parameter. We probably need octet-based 2767 granularity, and old data-id only offered fragment-based 2768 granularity. 2770 * Made AME and TE messages required. 2772 * Documented result parameter syntax and two result codes: 200 2773 (success) and 400 (failure). 2775 * Added optional "result" parameter to CE. 2777 head-sid12 2779 * Fixed BNF to remove extra SP and "," in front of structure and 2780 list values. 2782 * Fixed the type of "id" field in a "service" structure. 2784 * Documented "sg-id" parameter. 2786 * Renamed "copied" to "data-id" so that it can be used by both 2787 agents. An OPES processor uses named "Copied: data-id" 2788 parameter and a callout server uses anonymous "data-id" 2789 parameter (instead of previously documented "copy-am-offset"). 2791 * Removed "rid" parameter from Negotiation Offer (NO) message as 2792 unused. 2794 * Removed "size" parameter from messages with payload since 2795 payload syntax includes an explicit size value. 2797 * Renamed Data Have (DH) message to Data Use Mine (DUM) message 2798 to preserve the symmetry with Data Use Yours (DUY) message and 2799 to prepare for possible addition of Data Check Mine (DCM) 2800 message. 2802 * Finished phasing out the "modified" message parameter. 2804 * Added an "As-is" named-parameter to mark adapted pieces of data 2805 identical to the original. 2807 * Replaced a huge "message nesting" figure with a set of short 2808 specific rules illustrating the same concept. Added a new 2809 "Exchange Patterns" subsection to accommodate the rules and 2810 related matters. The figure was not clear enough. Hopefully, 2811 the rules are. 2813 head-sid10 2815 * Removed the concept of OCP connection as a group of messages 2816 sharing the same group of callout services. Now there is no 2817 difference between OCP connection and transport connection. 2819 * Added a concept of a Service Group, which is a list of services 2820 with an identifier, for now. A given Service Group is 2821 referenced by the creating/destroying side only, to prevent 2822 destruction synchronization. 2824 * Removed Connection Services (CSvc) message. 2826 * Removed connection priority until proven generally useful. Can 2827 be implemented as an extension. 2829 head-sid9 2831 * Added Negotiation and Capability Inquiry sections. 2833 * Deleted data-end message because AME (Application Message End) 2834 already does the same thing and because there is no data-start 2835 message. 2837 * Deleted meta-* messages. Data-* messages are now used for both 2838 metadata and data since OCP does not know the difference, but 2839 must provide the same exchange mechanism for both. 2841 * Use a single message name (short or long, depending on the 2842 message) instead of using full and abbreviated versions and 2843 trying to enforce abbreviations on the wire. Be more consistent 2844 in creating short message names. 2846 * Resurrected OCP scope figure based on popular demand. 2848 * Applied Martin Stecher comments dated 2003/05/30. 2850 head-sid8 2852 * Added structure and list values to ABNF syntax. 2854 * Messages with multiple equally-named parameters are 2855 semantically invalid. 2857 * Added types for message parameters. 2859 * Started replacing complicated, error-prone, and probably mostly 2860 useless "modified" parameter with a clear and simple "as-is" 2861 parameter. 2863 * Converted parameter descriptions from list items to 2864 subsections. 2866 * OCP syntax requires one or two character lookups to determine 2867 the next message part. Fixed a comment for implementors saying 2868 that one lookup is always sufficient. 2870 head-sid7 2872 * Mentioned TCP/IP/Internet as assumed transport/network, with 2873 any other reliable connection-oriented transport/network usable 2874 as well. We do not document how OCP messages are mapped to TCP 2875 but it should be obvious. See Overall Operation section. 2877 * Applied Martin Stecher's corrections to OCP message syntax and 2878 definitions of messages. 2880 * Restricted full message name use to documentation, debuggers, 2881 and such. The differences in abbreviated and full name usage 2882 still need more consideration and polishing. 2884 * IAB Considerations section now refers to the future opes-iab 2885 draft. 2887 head-sid6 2889 * Added OCP message syntax. Reformatted message descriptions to 2890 match new syntax concepts. 2892 * Started adding meta-have message to exchange metadata details. 2893 Removed negotiation messages for now (posted new messages to 2894 the list for a discussion). 2896 * Added Security Considerations section (based on Abbie Barbir's 2897 original text). 2899 head-sid4 2901 * Changed document labels to reflect future "WG draft" status. 2903 * Added Acknowledgments section. 2905 * Added "Core" to the title since we expect application specific 2906 drafts to follow and because this document, even when complete, 2907 cannot specify a "working" protocol without 2908 application-specific parts. This change is still debatable. 2910 * Added reference to required future application-specific specs 2911 in the Introduction. 2913 * Moved all rant about irrelevance of application protocols 2914 proxied by an OPES processor to the "Application proxies and 2915 OCP scope" section. Removed "processor input" and "processor 2916 output" terms. No reason to define a new term when its only 2917 purpose is to document irrelevance? 2919 * Moved "OCP message" definition to the terminology section. 2921 * Clarified "application message" definition based on recent WG 2922 discussions and suggestions. There seems to be consensus that 2923 "application message" is whatever OPES processor and callout 2924 server define or agree on, but OCP needs some minimal structure 2925 (content + metadata) 2927 * Synced data and metadata definitions with the new "application 2928 message" definition. 2930 * Simplified "Overall Operation" section since it no longer need 2931 to talk about irrelevance of application protocols proxied by 2932 an OPES processor. 2934 * Illustrated nesting/relationship of key OCP concepts 2935 (application message, OCP message, transaction, connection, 2936 transport connection, etc.). The figure needs more work. 2938 * Listed all from-processor and from-server OCP messages in one 2939 place, with references to message definitions. 2941 * Added "services" message parameter, assuming that more than one 2942 service may be requested/executed with one transaction. 2944 * Gave callout server ability to report what services were 2945 actually applied (see "services" parameter definition). 2947 head-sid3 2949 * clarified application message definition and OCP boundaries by 2950 introducing three kinds of "applications": processor input, 2951 processor output, and OCP application 2953 * made "Overall Operation" a top-level section since it got long 2954 and has its own subsections now; lots of editorial changes in 2955 this sections, new figures 2957 * added illustrations of OCP messages, transactions, and 2958 connections 2960 head-sid2 2962 * introduced a notion of meta-data to both simplify OCP and make 2963 OCP agnostic to application meta-data; previous approach 2964 essentially assumed existence of a few common properties like 2965 protocol name or application message source/destination while 2966 not allowing any other properties to be exchanged between OCP 2967 agents); specific meta-data format/contents is not important to 2968 OCP but OCP will help agents to negotiate that format/contents 2970 * removed wording implying that OCP adapts application messages; 2971 OCP only used to exchange data and meta-data (which facilitates 2972 adaptation) 2974 * changed most of the definitions; added definitions for 2975 meta-data, original/adapted flows, and others 2977 * split 'data-pause' message into 'data-pause' request by the 2978 callout server and 'data-paused' notification by the OPES 2979 processor; fixed "paused" state management 2981 * added motivation for data acking mechanism 2983 * replaced "am-proto", "am-kind", "am-source", and 2984 "am-destination" parameters with "meta-data" 2986 * replaced SERVER and CLIENT placeholders with "callout server" 2987 and "OPES processor" 2989 * added editing marks 2991 16. References 2993 16.1 Normative References 2995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2996 Requirement Levels", BCP 14, RFC 2119, March 1997. 2998 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2999 Specifications: ABNF", RFC 2234, November 1997. 3001 [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3002 Resource Identifiers (URI): Generic Syntax", RFC 2396, 3003 August 1998. 3005 [I-D.ietf-opes-architecture] 3006 Barbir, A., "An Architecture for Open Pluggable Edge 3007 Services (OPES)", draft-ietf-opes-architecture-04 (work in 3008 progress), December 2002. 3010 16.2 Informative References 3012 [I-D.ietf-opes-protocol-reqs] 3013 Beck, A., "Requirements for OPES Callout Protocols", 3014 draft-ietf-opes-protocol-reqs-03 (work in progress), 3015 December 2002. 3017 [I-D.ietf-opes-threats] 3018 Barbir, A., "Security Threats and Risks for Open", 3019 draft-ietf-opes-threats-03 (work in progress), December 3020 2003. 3022 [I-D.ietf-opes-scenarios] 3023 Barbir, A., "OPES Use Cases and Deployment Scenarios", 3024 draft-ietf-opes-scenarios-01 (work in progress), August 3025 2002. 3027 [I-D.ietf-opes-authorization] 3028 Batuner, O., Beck, A., Chan, T., Orman, H. and A. Barbir, 3029 "Policy, Authorization and Enforcement Requirements of 3030 OPES", draft-ietf-opes-authorization-03 (work in 3031 progress), April 2004. 3033 [I-D.ietf-opes-end-comm] 3034 Barbir, A., "OPES entities and end points communication", 3035 draft-ietf-opes-end-comm-06 (work in progress), December 3036 2003. 3038 [I-D.ietf-opes-rules-p] 3039 Beck, A. and A. Rousskov, "P: Message Processing 3040 Language", draft-ietf-opes-rules-p-02 (work in progress), 3041 October 2003. 3043 [I-D.ietf-opes-iab] 3044 Barbir, A. and A. Rousskov, "OPES Treatment of IAB 3045 Considerations", draft-ietf-opes-iab-05 (work in 3046 progress), April 2004. 3048 [I-D.ietf-opes-http] 3049 Rousskov, A. and M. Stecher, "HTTP adaptation with OPES", 3050 draft-ietf-opes-http-02 (work in progress), January 2004. 3052 [I-D.ietf-fax-esmtp-conneg] 3053 Toyoda, K. and D. Crocker, "SMTP and MIME Extensions For 3054 Content Conversion", draft-ietf-fax-esmtp-conneg-09 (work 3055 in progress), December 2003. 3057 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 3058 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 3059 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3061 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 3062 RFC 3080, March 2001. 3064 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 3065 Considerations for Open Pluggable Edge Services", RFC 3066 3238, January 2002. 3068 Author's Address 3070 Alex Rousskov 3071 The Measurement Factory 3073 EMail: rousskov@measurement-factory.com 3074 URI: http://www.measurement-factory.com/ 3076 Intellectual Property Statement 3078 The IETF takes no position regarding the validity or scope of any 3079 Intellectual Property Rights or other rights that might be claimed to 3080 pertain to the implementation or use of the technology described in 3081 this document or the extent to which any license under such rights 3082 might or might not be available; nor does it represent that it has 3083 made any independent effort to identify any such rights. Information 3084 on the IETF's procedures with respect to rights in IETF Documents can 3085 be found in BCP 78 and BCP 79. 3087 Copies of IPR disclosures made to the IETF Secretariat and any 3088 assurances of licenses to be made available, or the result of an 3089 attempt made to obtain a general license or permission for the use of 3090 such proprietary rights by implementers or users of this 3091 specification can be obtained from the IETF on-line IPR repository at 3092 http://www.ietf.org/ipr. 3094 The IETF invites any interested party to bring to its attention any 3095 copyrights, patents or patent applications, or other proprietary 3096 rights that may cover technology that may be required to implement 3097 this standard. Please address the information to the IETF at 3098 ietf-ipr@ietf.org. 3100 Disclaimer of Validity 3102 This document and the information contained herein are provided on an 3103 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3104 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3105 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3106 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3107 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3108 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3110 Copyright Statement 3112 Copyright (C) The Internet Society (2004). This document is subject 3113 to the rights, licenses and restrictions contained in BCP 78, and 3114 except as set forth therein, the authors retain all their rights. 3116 Acknowledgment 3118 Funding for the RFC Editor function is currently provided by the 3119 Internet Society.