idnits 2.17.1 draft-ietf-opes-http-03.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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1460. ** 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. 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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 270: '... An OCP agent MUST send application ...' RFC 2119 keyword, line 272: '... order part MAY terminate the transa...' RFC 2119 keyword, line 274: '...n OPES processor MUST NOT send parts t...' RFC 2119 keyword, line 275: '...d profile. An callout server MUST NOT...' RFC 2119 keyword, line 277: '...ving an not-listed part MUST terminate...' (67 more instances...) 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 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 (April 19, 2004) is 7312 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-opes-architecture' is defined on line 1381, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-08) exists of draft-ietf-opes-end-comm-06 ** Downref: Normative reference to an Informational draft: draft-ietf-opes-end-comm (ref. 'I-D.ietf-opes-end-comm') == Outdated reference: A later version (-05) exists of draft-ietf-opes-ocp-core-04 Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: October 21, 2004 M. Stecher 5 CyberGuard Corporation 6 April 19, 2004 8 HTTP adaptation with OPES 9 draft-ietf-opes-http-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on October 21, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). 40 Abstract 42 Open Pluggable Edge Services (OPES) framework documents several 43 application-agnostic mechanisms such as OPES tracing, OPES bypass, 44 and OPES callout protocol. This document extends those generic 45 mechanisms for Hypertext Transfer Protocol (HTTP) adaptation. 46 Together, application-agnostic OPES documents and this HTTP profile 47 constitute a complete specification for HTTP adaptation with OPES. 49 Table of Contents 51 1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. OPES Document Map . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Callout Protocol . . . . . . . . . . . . . . . . . . . . . . . 6 54 3.1 Application Message Parts . . . . . . . . . . . . . . . . 6 55 3.2 Application Profile Features . . . . . . . . . . . . . . . 7 56 3.2.1 Profile Parts . . . . . . . . . . . . . . . . . . . . 8 57 3.2.2 Profile Structure . . . . . . . . . . . . . . . . . . 9 58 3.2.3 Aux-Parts . . . . . . . . . . . . . . . . . . . . . . 10 59 3.2.4 Pause-At-Body . . . . . . . . . . . . . . . . . . . . 10 60 3.2.5 Stop-Receiving-Body . . . . . . . . . . . . . . . . . 11 61 3.2.6 Preservation-Interest-Body . . . . . . . . . . . . . . 11 62 3.2.7 Content-Encodings . . . . . . . . . . . . . . . . . . 12 63 3.2.8 Profile Negotiation Example . . . . . . . . . . . . . 13 64 3.3 Application Message Start Message . . . . . . . . . . . . 14 65 3.4 DUM Message . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.5 Selective Adaptation . . . . . . . . . . . . . . . . . . . 15 67 3.6 Hop-by-hop Headers . . . . . . . . . . . . . . . . . . . . 16 68 3.7 Transfer Encodings . . . . . . . . . . . . . . . . . . . . 16 69 3.8 HTTP Header Correctness . . . . . . . . . . . . . . . . . 17 70 3.8.1 Message Size Recalculation . . . . . . . . . . . . . . 17 71 3.8.2 Content-MD5 Header . . . . . . . . . . . . . . . . . . 18 72 3.9 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 4. Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 74 5. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 75 6. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 27 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 78 9. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 30 79 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 80 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 82 10.1 Normative References . . . . . . . . . . . . . . . . . . . 38 83 10.2 Informative References . . . . . . . . . . . . . . . . . . 38 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 39 85 Intellectual Property and Copyright Statements . . . . . . . . 40 87 1. Scope 89 The Open Pluggable Edge Services (OPES) framework documents several 90 application-agnostic mechanisms such as OPES processor and endpoints 91 communications [I-D.ietf-opes-end-comm] or OPES callout protocol 92 [I-D.ietf-opes-ocp-core]. This document extends those generic 93 mechanisms for adaptation of a specific application protocol, HTTP 94 [RFC2616]. Together, application-agnostic OPES documents and this 95 HTTP profile constitute a complete specification for HTTP adaptation 96 with OPES. 98 The primary sections of this document specify HTTP-specific 99 extensions for the corresponding application-agnostic mechanisms 100 documented elsewhere. 102 2. OPES Document Map 104 This document belongs to a large set of OPES specifications produced 105 by the IETF OPES Working Group. Familiarity with the overall OPES 106 approach and typical scenarios is often essential when trying to 107 comprehend isolated OPES documents. This section provides an index 108 of OPES documents to assist the reader with finding "missing" 109 information. 111 o The document on "OPES Use Cases and Deployment Scenarios" 112 [I-D.ietf-opes-scenarios] describes a set of services and 113 applications that are considered in scope for OPES and have been 114 used as a motivation and guidance in designing the OPES 115 architecture. 117 o The OPES architecture and common terminology are described in "An 118 Architecture for Open Pluggable Edge Services (OPES)" [I-D.ietf- 119 opes-architecture]. 121 o "Policy, Authorization and Enforcement Requirements of OPES" 122 [I-D.ietf-opes-authorization] outlines requirements and 123 assumptions on the policy framework, without specifying concrete 124 authorization and enforcement methods. 126 o "Security Threats and Risks for OPES" [I-D.ietf-opes-threats] 127 provides OPES risk analysis, without recommending specific 128 solutions. 130 o "OPES Treatment of IAB Considerations" [I-D.ietf-opes-iab] 131 addresses all architecture-level considerations expressed by the 132 IETF Internet Architecture Board (IAB) when the OPES WG was 133 chartered. 135 o At the core of the OPES architecture are the OPES processor and 136 the callout server, two network elements that communicate with 137 each other via an OPES Callout Protocol (OCP). The requirements 138 for such protocol are discussed in "Requirements for OPES Callout 139 Protocols" [I-D.ietf-opes-protocol-reqs]. 141 o "OPES Callout Protocol Core" [I-D.ietf-opes-ocp-core] specifies an 142 application agnostic protocol core to be used for the 143 communication between OPES processor and callout server. 145 o "OPES entities and end points communications" [I-D.ietf-opes-end- 146 comm] specifies generic tracing and bypass mechanisms for OPES. 148 o The OCP Core and Communications documents are independent from the 149 application protocol being adapted by OPES entities. Their 150 generic mechanisms have to be complemented by application-specific 151 profiles. This document, HTTP adaptation with OPES, is such an 152 application profile for HTTP. It specifies how application- 153 agnostic OPES mechanisms are to be used and augmented in order to 154 support adaptation of HTTP messages. 156 o Finally, "P: Message Processing Language" [I-D.ietf-opes-rules-p] 157 defines a language for specifying what OPES adaptations (e.g, 158 translation) must be applied to what application messages (e.g., 159 e-mail from bob@example.com). P language is meant for configuring 160 application proxies (OPES processors). 162 3. Callout Protocol 164 This section documents the HTTP profile for the OPES Callout Protocol 165 (OCP) Core [I-D.ietf-opes-ocp-core]. Familiarity with OCP Core is 166 required to understand the HTTP profile. This section uses OCP Core 167 conventions, terminology, and mechanisms. 169 OPES processor communicates its desire to adapt HTTP messages via a 170 Negotiation Offer (NO) message with HTTP-specific feature identifiers 171 documented in Section 3.2. HTTP-specific OCP optimization mechanisms 172 can be negotiated at the same time. A callout server that supports 173 adaptation of HTTP messages has a chance to negotiate what HTTP 174 message parts will participate in adaptation, including negotiation 175 of HTTP request parts as metadata for HTTP response adaptation. 176 Negotiable HTTP message parts are documented in Section 3.1. 178 HTTP profile introduces a new parameter for the Application Message 179 Start (AMS) message to communicate known HTTP message length (HTTP 180 headers often do not convey length information reliably or at all). 181 This parameter is documented in Section 3.3. Section 3.4 documents a 182 mechanism to report HTTP message part with Data Use Mine (DUM) 183 messages. 185 The remaining OCP sections document various OCP marshaling corner 186 cases such as handling of HTTP transfer encodings and 100 Continue 187 responses. 189 3.1 Application Message Parts 191 An HTTP message may have several well-known parts: headers, body, and 192 trailers. HTTP OPES processors are likely to have information about 193 HTTP message parts because they have to isolate and interpret HTTP 194 headers and find HTTP message boundaries. Callout servers may either 195 not care about certain parts or may benefit from reusing HTTP OPES 196 processor work on isolating and categorizing interesting parts. 198 The following is the declaration of am-part (application message 199 part) type using OCP Core Protocol Element Type Declaration Mnemonic 200 (PETDM): 202 am-part: extends atom; 203 am-parts: extends list of am-part; 205 Figure 1 207 The following six "am-part" atoms are valid values: 209 request-header: The start-line of an HTTP request message, all 210 request message headers, and the CRLF separator at the end of HTTP 211 headers (compare with section 4.1 of [RFC2616]). 213 request-body: The message body of an HTTP request message as defined 214 in section 4.3 of [RFC2616] but not including the trailer. 216 request-trailer: The entity headers of the trailer of an HTTP request 217 message in chunked transfer encoding. This part follows the same 218 syntax as the trailer defined in section 3.6.1 of [RFC2616]. 220 response-header: The start-line of an HTTP response message, all 221 response message headers, and the CRLF separator at the end of 222 HTTP headers (compare with section 4.1 of [RFC2616]). 224 response-body: The message body of an HTTP response message as 225 defined in section 4.3 of [RFC2616] but not including the trailer. 227 response-trailer: The entity headers of the trailer of an HTTP 228 response message in chunked transfer encoding. This part follows 229 the same syntax as the trailer defined in section 3.6.1 of 230 [RFC2616]. 232 3.2 Application Profile Features 234 This document defines two HTTP profiles for OCP: request and response 235 profiles. These two profiles are described below. Each profile has 236 a unique feature identifier, a list of original application message 237 parts, and a list of adapted application message parts: 239 profile ID: http://www.iana.org/assignments/opes/ocp/http/request 241 original request parts: request-header, request-body, request- 242 trailer 244 adapted request parts: request-header, request-body, request- 245 trailer 247 adapted response parts: response-header, response-body, response- 248 trailer 250 profile ID: http://www.iana.org/assignments/opes/ocp/http/response 252 original transaction parts: request-header (aux), request-body 253 (aux), request-trailer (aux), response-header, response-body, 254 response-trailer 256 adapted response parts: response-header, response-body, response- 257 trailer 259 The request profile contains two variants of adapted part lists: HTTP 260 request parts and HTTP response parts. Parts marked with an "(aux)" 261 suffix are auxiliary parts that can only be used if explicitly 262 negotiated for a profile. See Section 3.2.1 for specific rules 263 governing negotiation and use of am-parts. 265 The scope of a negotiated profile is the OCP connection (default) or 266 the service group specified via the SG parameter. 268 3.2.1 Profile Parts 270 An OCP agent MUST send application message parts in the order implied 271 by the profile parts lists above. An OCP agent receiving an out-of- 272 order part MAY terminate the transaction with an error. 274 An OPES processor MUST NOT send parts that are not listed as 275 "original" in the negotiated profile. An callout server MUST NOT 276 send parts that are not listed as "adapted" in the negotiated 277 profile. An OCP agent receiving an not-listed part MUST terminate 278 the transaction with an error. The informal rationale for the last 279 requirement is to reduce the number of subtle interoperability 280 problems where an agent thinks that the parts it is sending are 281 understood/used by the other agent when, in fact, they are being 282 ignored or skipped because they are not expected. 284 Some HTTP messages lack certain parts. For example, many HTTP 285 requests do not have bodies, and most HTTP messages do not have 286 trailers. An OCP agent MUST NOT send (i.e., must skip) absent 287 application message parts. 289 An OCP agent MUST send present non-auxiliary parts and it MUST send 290 those present auxiliary parts that were negotiated via the Aux-Parts 291 (Section 3.2.3) parameter. OCP agents MUST NOT send auxiliary parts 292 that were not negotiated via the Aux-Parts (Section 3.2.3) parameter. 294 An OCP agent receiving a message part in violation of the above 295 requirements MAY terminate the corresponding transaction with an 296 error. 298 By design, original parts not included in the adapted parts list 299 cannot be adapted. In other words, a callout service can only adapt 300 parts in the adapted parts list even though it may have access to 301 other parts. 303 In the request profile, the callout server MUST send either adapted 304 request parts or adapted response parts. An OPES processor receiving 305 adapted flow with application message parts from both lists (in 306 violation of the previous rule) MUST terminate the OCP transaction 307 with an error. Informally, the callout server sends adapted response 308 parts to "short-circuit" the HTTP transaction, forcing the OPES 309 processor to return an HTTP response without forwarding an adapted 310 HTTP request. This short-circuiting is useful for responding, for 311 example, to an HTTP request that the callout service defines as 312 forbidden. 314 Unless explicitly configured to do otherwise, an OPES processor MUST 315 offer all non-auxiliary original parts in Negotiation Offer (NO) 316 messages. See Section 3.5 for this rule rationale and examples of 317 harmful side-effects from selective adaptation. 319 3.2.2 Profile Structure 321 An HTTP application profile feature extends semantics of the feature 322 type of OCP Core while adding the following named parameters to that 323 type: 325 o Aux-Parts (Section 3.2.3) 327 o Pause-At-Body (Section 3.2.4) 329 o Stop-Receiving-Body (Section 3.2.5) 331 o Preservation-Interest-Body (Section 3.2.6) 333 o Content-Encodings (Section 3.2.7) 335 The definition of the HTTP profile feature structure using PETDM 336 follows: 338 HTTP-Profile: extends Feature with { 339 [Aux-Parts: am-parts]; 340 [Pause-At-Body: size]; 341 [Stop-Receiving-Body: size]; 342 [Preservation-Interest-Body: size]; 343 [Content-Encodings: codings]; 344 }; 346 Figure 2 348 An HTTP profile structure can be used in feature lists of Negotiation 349 Offer (NO) messages and as anonymous parameter of an Negotiation 350 Response (NR) message. All profile parameters apply to any OCP 351 transaction within profile scope. 353 3.2.3 Aux-Parts 355 The Aux-Parts parameter of an HTTP response profile can be used to 356 negotiate the inclusion of auxiliary application message parts into 357 the original data flow. The parameter is a possibly empty list of 358 am-part tokens. An OPES processor MAY send an Aux-Parts parameter to 359 advertise availability of auxiliary application message parts. A 360 callout server MAY respond with a possibly empty subset of the parts 361 it needs. The callout server response defines the subset of 362 successfully negotiated auxiliary message parts. 364 When receiving a Negotiation Offer (NO) message, the callout server 365 MUST ignore any non-auxiliary part listed in the Aux-Parts parameter. 366 When sending a Negotiation Response (NR) message, the callout server 367 MUST NOT select any application message part that was not explicitly 368 listed in the negotiation offer. In case of a violation of the last 369 rule, the OPES processor MUST terminate the transaction. 371 An OPES processor MUST send each negotiated auxiliary part to the 372 callout server, unless the part is absent. 374 Example: 375 Aux-Parts: (request-header,request-body) 377 Figure 3 379 3.2.4 Pause-At-Body 381 A callout server MAY use the Pause-At-Body parameter to request a 382 pause in original application message body transmission before 383 original dataflow starts. The parameter's value is of type "offset". 384 The parameter specifies the start of the non-auxiliary application 385 message body suffix that the sender is temporary not interested in 386 seeing. 388 [headers][ body prefix | body suffix ][trailer] 389 <-- ? --><-- offset --><-- ? ----------------> 390 <-- equiv. DWP offset -> 392 Figure 4 394 When an OPES processor receives a Pause-At-Body parameter, it MUST 395 behave as if it has received a Want Data Paused (DWP) message with 396 the corresponding org-offset. Note that the latter offset is 397 different from the Pause-At-Body offset and is unknown until the size 398 of the HTTP message headers is known. 400 For example, if the Pause-At-Body value is zero, the OPES processor 401 should send a Paused My Data (DPM) message just before it sends the 402 first Data Use Mine (DUM) message with the response-body part in the 403 HTTP response profile. If the Pause-At-Body value is 300, the OPES 404 processor should send a DPM message after transmitting 300 OCTETs for 405 that application message part. 407 Example: 408 Pause-At-Body: 0 410 Figure 5 412 3.2.5 Stop-Receiving-Body 414 A callout server MAY use the Stop-Receiving-Body parameter to imply a 415 DWSR message behavior before the original dataflow starts. The 416 parameter's value is of type "offset". The parameter specifies an 417 offset into the original, non-auxiliary message body part (request- 418 body in request profile and response-body in response profile). 420 A callout service MAY send a Stop-Receiving-Body parameter with its 421 negotiation response if there is a fixed offset into the message body 422 for all transactions of a profile for which a Want Stop Receiving 423 Data (DWSR) message would be sent. An OPES processor MUST behave as 424 if it has received a DWSR message with the corresponding offset. 425 Note that the latter offset is different from the Stop-Receiving-Body 426 offset and is unknown until the size of the HTTP message headers is 427 known. 429 For example, if the Stop-Receiving-Body value is zero in an HTTP 430 response profile, the OPES processor should send an AME message with 431 result code 206 immediately after sending the response-header message 432 part and before starting with the response-body message part. 434 Example: 435 Stop-Receiving-Body: 0 437 Figure 6 439 3.2.6 Preservation-Interest-Body 441 The Preservation-Interest-Body parameter can be used to optimize data 442 preservation at the OPES processor. The parameter's value is of type 443 "size" and denominates a prefix size of the original, non-auxiliary 444 message body part (request-body in HTTP request profile and response- 445 body in response profile). 447 A callout service MAY send a Preservation-Interest-Body parameter 448 with its negotiation response if there is a fixed-size prefix of the 449 application message body for which a Data Preservation Interest (DPI) 450 message would be sent. An OPES processor MUST behave as if it 451 receives a DPI message with org-offset zero and org-size equal to the 452 value of the Preservation-Interest-Body parameter. 454 For example, if the Preservation-Interest-Body value is zero in an 455 HTTP response profile, the callout server must not send any DUY 456 message for the response-body part; the OPES processor may use this 457 information to optimize its data preservation behavior even before it 458 makes the decision to preserve data. 460 Example: 461 Preservation-Interest-Body: 0 463 Figure 7 465 3.2.7 Content-Encodings 467 A callout server MAY send a Content-Encodings list to indicate its 468 preferences in content encodings. Encodings listed first are 469 preferred to other encodings. An OPES processor MAY use any content 470 encoding when sending application messages to a callout server. 472 The list of preferred content encodings does not imply lack of 473 support for other encodings. The OPES processor MUST NOT bypass a 474 service just because the actual content encoding does not match the 475 service's preferences. 477 If an OCP agent receives an application message that it cannot handle 478 due to specific content encoding, the usual transaction termination 479 rules apply. 481 content-coding: extends atom; 482 content-codings: extends list of content-coding; 484 Example: 485 Content-Encodings: (gzip) 487 Figure 8 489 The semantics of content-coding is defined in section 3.5 of 490 [RFC2616]. 492 3.2.8 Profile Negotiation Example 494 Example: 495 P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response" 496 Aux-Parts: (request-header,request-body) 497 }) 498 SG: 5 499 ; 500 S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response" 501 Aux-Parts: (request-header) 502 Pause-At-Body: 30 503 Preservation-Interest-Body: 0 504 Content-Encodings: (gzip) 505 } 506 SG: 5 507 ; 509 Figure 9 511 This example shows a negotiation offer made by an OPES processor for 512 a service group (id 5) that has already been created; the callout 513 server sends an adequate negotiation response. 515 The OPES processor offers one profile feature for HTTP response 516 messages. Besides the standard message parts, the OPES processor is 517 able to add the header and body of the original HTTP request as 518 auxiliary message parts. 520 The callout server requests the auxiliary request-header part, but is 521 not interested in receiving the request-body part. 523 The OPES processor sends at most the following message parts, in the 524 specified order, for all transactions in service group 5: request- 525 header, response-header, response-body, response-trailer. Note that 526 the request-body part is not included (because it is an auxiliary 527 part that was not explicitly requested). Some of the response parts 528 may not be sent if the original message lacks them. 530 The callout server indicates through the Preservation-Interest-Body 531 parameter with size zero that it will not send any DUY messages. The 532 OPES processor may therefore preserve no preservation for any 533 transaction of this profile. 535 By sending a Pause-At-Body value of 30, the callout server requests a 536 data pause. The OPES processor sends a Paused My Data (DPM) message 537 immediately after sending at least 30 OCTETs of the response-body 538 part. Thereafter, the OPES processor waits for a Want More Data 539 (DWM) message from the callout service. 541 3.3 Application Message Start Message 543 A new named parameter for Application Message Start (AMS) messages is 544 introduced. 546 AM-EL: size 548 Figure 10 550 AM-EL value is the size of the request-body part in the HTTP request 551 profile, and is the size of the response-body part in the HTTP 552 response profile, before any transfer codings have been applied (or 553 after all transfer codings have been removed). This definition is 554 consistent with the HTTP entity length definition. 556 An OCP agent that knows the exact length of the HTTP message entity 557 (see Section 7.2.2 "Entity Length" in [RFC2616]) at the time it sends 558 the AMS message, SHOULD announce this length using the AM-EL named 559 parameter of an AMS message. If the exact entity length is not 560 known, an OCP agent MUST NOT send an AM-EL parameter. Relaying 561 correct entity length can have significant performance advantages for 562 the recipient, and implementations are strongly encouraged to relay 563 known entity lengths. Similarly, relaying incorrect entity length 564 can have drastic correctness consequences for the recipient, and 565 implementations are urged to exercise great care when relaying entity 566 length. 568 An OPES processor receiving an AM-EL parameter SHOULD use the 569 parameter's value in a Content-Length HTTP entity header when 570 constructing an HTTP message, provided a Content-Length HTTP entity 571 header is allowed for the given application message by HTTP (see 572 Section 3.8.1). 574 3.4 DUM Message 576 A new named parameter for Data Use Mine (DUM) messages is introduced. 578 AM-Part: am-part 580 Figure 11 582 An OCP agent MUST send an AM-Part parameter with every DUM message 583 that is a part of an OCP transaction with an HTTP profile. The AM- 584 Part parameter value is a single am-part token. As implied by the 585 syntax, a DUM message can only contain data of a single application 586 message part. One message part can be fragmented into any number of 587 DUM messages with the same AM-Part parameter. 589 The following example shows three DUM messages containing an abridged 590 HTTP response message. The response-body part is fragmented and sent 591 within two DUM messages. 593 Example: 594 P: DUM 88 1 0 595 Kept: 0 596 AM-Part: response-header 598 64:HTTP/1.1 200 OK 599 Content-Type: text/html 600 Content-Length: 51 602 ; 603 P: DUM 88 1 64 604 Kept: 64 605 AM-Part: response-body 607 19:This is 608 ; 609 P: DUM 88 1 83 610 Kept: 83 611 AM-Part: response-body 613 32: a simple message. 614 ; 616 Figure 12 618 3.5 Selective Adaptation 620 The HTTP profile for OCP applies to all HTTP messages. That scope 621 includes HTTP messages such as 1xx (Informational) responses, POST, 622 CONNECT, and OPTIONS requests as well as responses with extension 623 status codes and requests with extension methods. Unless 624 specifically configured to do otherwise, an OPES processor MUST 625 forward all HTTP messages for adaptation at callout servers. OPES 626 bypass instructions, configured HTTP message handling rules, and OCP- 627 negotiation with a callout server are all examples of an acceptable 628 "specific configuration" that provides an exception to this rule. 630 While it may seem useless to attempt to adapt "control" messages such 631 as a 100 (Continue) response, skipping such messages by default may 632 lead to serious security flaws and interoperability problems. For 633 example, sensitive company information might be relayed via a 634 carefully crafted 100 Continue response or a malicious CONNECT 635 request may not get logged if OPES processor does not forward these 636 messages to a callout service that is supposed to handle them. 638 By design, OPES processor implementation cannot unilaterally decide 639 that an HTTP message is not worth adapting. It needs a callout 640 server opinion, a configuration setting, or another external 641 information to make the decision. 643 3.6 Hop-by-hop Headers 645 HTTP defines several hop-by-hop headers (e.g., Connection) and allows 646 for extension headers to be specified as hop-by-hop ones (via the 647 Connection header mechanism). Depending on the environment and 648 configuration, an OPES processor MAY forward hop-by-hop headers to 649 callout servers and MAY use hop-by-hop headers returned by callout 650 servers to build an HTTP message for the next application hop. 651 However, see Section 3.7 for requirements specific to the Transfer- 652 Encoding header. 654 For example, a logging or statistics collection service may want to 655 see hop-by-hop headers sent by the previous application hop to the 656 OPES processor and/or hop-by-hop headers sent by the OPES processor 657 to the next application hop. Another service may actually handle 658 HTTP logic of removing and adding hop-by-hop headers. Many services 659 will ignore hop-by-hop headers. This specification does not define a 660 mechanism for distinguishing these use cases. 662 3.7 Transfer Encodings 664 HTTP messages may use transfer encodings, a hop-by-hop encoding 665 feature of HTTP. Adaptations that use HTTP transfer encodings have 666 to be explicitly negotiated. This specification does not document 667 such negotiations. In the absence of explicit transfer-encoding 668 negotiations, an OCP agent MUST NOT send transfer-encoded application 669 message bodies. 671 Informally, the above rule means that the agent or its environment 672 have to make sure that all transfer encodings are stripped from an 673 HTTP message body before it enters OCP scope. An agent MUST 674 terminate the OCP transaction if it has to send an application 675 message body but cannot remove all transfer encodings. Violations of 676 these rules lead to interoperability problems. 678 If an OCP agent receives transfer-encoded application data in 679 violation of the above requirement, the agent MAY terminate the 680 corresponding OCP transaction. 682 An OPES processor removing transfer encodings MUST remove the 683 Transfer-Encoding header before sending the header part to the 684 callout service. A callout server receiving a Transfer-Encoding 685 header MAY assume that original application data is still transfer- 686 encoded (and terminate the transaction). The OPES processor MUST 687 send a correct Transfer-Encoding header to the next HTTP recipient 688 independent of what header (if any) the callout server returned. 690 Logging and wiretapping are the examples where negotiating acceptable 691 transfer encodings may be worthwhile. While a callout server may not 692 be able to strip an encoding, it may still want to log the entire 693 message "as is". In most cases, however, the callout server would 694 not be able to meaningfully handle unknown transfer encodings. 696 3.8 HTTP Header Correctness 698 When communicating with HTTP applications, OPES processors MUST 699 ensure correctness of all computable HTTP headers documented in 700 specifications that the processors intend to be compliant with. A 701 computable header is defined as a header which value can be computed 702 based on the message body alone. For example, the correctness of 703 Content-Length and Content-MD5 headers has to be ensured by 704 processors claiming compliance with HTTP/1.1 ([RFC2616]). 706 Informally and by default, the OPES processor has to validate and 707 eventually recalculate, add, or remove computable HTTP headers in 708 order to build a compliant HTTP message from an adapted application 709 message returned by the callout server. If a particular OPES 710 processor trusts certain HTTP headers that a callout service sends, 711 it can use those headers "as is". 713 An OPES processor MAY forward a partially adapted HTTP message from a 714 callout server to the next callout server, without verifying HTTP 715 header correctness. Consequently, a callout service cannot assume 716 that the HTTP headers it receives are correct or final from an HTTP 717 point of view. 719 The following subsections present guidelines for the recalculation of 720 some HTTP headers. 722 3.8.1 Message Size Recalculation 724 By default, an OCP agent MUST NOT trust the Content-Length header 725 that is sent within an HTTP header message part. The message length 726 could be modified by a callout service without adaptation of the HTTP 727 message headers. 729 Before sending the HTTP message to the HTTP peer, the OPES processor 730 has to ensure correctness of the message length indication according 731 to section 4.4 of [RFC2616]. 733 Besides ensuring HTTP message correctness, good OPES processors set 734 up the message to optimize performance, including minimizing delivery 735 latency. Specifically, indicating the end of a message by closing 736 the HTTP connection ought to be the last resort: 738 o If the callout server sends an AM-EL parameter with its AMS 739 message, the OPES processor SHOULD use this value to create a 740 Content-Length header to be able to keep a persistent HTTP 741 connection. Note that HTTP rules prohibit a Content-Length header 742 to be used in transfer encoded messages. 744 o If AM-EL parameter or equivalent entity length information is not 745 available, and HTTP rules allow for chunked transfer encoding, the 746 OPES processor SHOULD use chunked transfer encoding. Note that 747 any Content-Length header has to be removed in this case. 749 o If the message size is not known a priori and chunked transfer 750 coding cannot be used, but the OPES processor can wait for the OCP 751 transaction to finish before forwarding the adapted HTTP message 752 on a persistent HTTP connection, then the processor SHOULD compute 753 and add a Content-Length header. 755 o Finally, if all optimizations are not applicable, the OPES 756 processor SHOULD delete any Content-Length header and forward 757 adapted data immediately, while indicating the message end by 758 closing the HTTP connection. 760 3.8.2 Content-MD5 Header 762 By default, the OPES processor MUST assume that the callout service 763 modifies the content in a way that the MD5 checksum of the message 764 body becomes invalid. 766 According to section 14.15 of [RFC2616], HTTP intermediaries must not 767 generate Content-MD5 headers. A recalculation is therefore possible 768 only if the OPES processor is considered authoritative for the entity 769 being adapted. An un-authoritative OPES processor MUST remove the 770 Content-MD5 header unless it detects that the HTTP message was not 771 modified; in this case it MAY leave the Content-MD5 header in the 772 message. When such detection significantly increases message 773 latency, deleting the Content-MD5 header may be a better option. 775 3.9 Examples 777 This is a possible OCP message flow using an HTTP request profile. 778 An end-user wants to access the home page of 779 www.restricted.example.com, through the proxy, but access is denied 780 by a URL blocking service running on the callout server used by the 781 proxy. 783 OCP messages from the OPES processor are marked with "P:" and OCP 784 messages from the callout server are marked with "S:". The OCP 785 connection is not closed at the end but kept open for the next OCP 786 transaction. 788 Example: 789 P: CS; 790 S: CS; 791 P: SGC 11 ({"31:ocp-test.example.com/url-filter"}); 792 P: NO ({"53:http://www.iana.org/assignments/opes/ocp/http/request"}) 793 SG: 11 794 ; 795 S: NR {"53:http://www.iana.org/assignments/opes/ocp/http/request"} 796 SG: 11 797 ; 798 P: TS 55 11; 799 P: AMS 55 800 AM-EL: 0 801 ; 802 P: DUM 55 0 803 Kept: 0 804 AM-Part: request-header 805 235:GET http://www.restricted.example.com/ HTTP/1.1 806 Accept: */* 807 Accept-Language: de 808 Accept-Encoding: gzip, deflate 809 User-Agent: Mozilla/4.0 (compatible; Windows NT 5.0) 810 Host: www.restricted.example.com 811 Proxy-Connection: Keep-Alive 813 ; 814 P: AME 55; 815 S: AMS 55; 816 S: DUM 55 0 817 AM-Part: response-header 819 76:HTTP/1.1 403 Forbidden 820 Content-Type: text/html 821 Proxy-Connection: close 823 ; 824 S: DUM 55 0 825 AM-Part: response-body 827 67:You are not allowed to 828 access this page. 829 ; 830 S: AME 55; 831 P: TE 55; 832 S: TE 55; 833 Figure 13 835 The next example is a language translation of a small plain text file 836 that gets transferred in an HTTP response. In this example, OCP 837 agents negotiate a profile for the whole OCP connection. The OCP 838 connection remains open in the end of the OCP transaction. (Note 839 that NO and NR messages were rendered with an extra new line to 840 satisfy RFC formatting requirements.) 842 Example: 843 P: CS; 844 S: CS; 845 P: NO 846 ({"54:http://www.iana.org/assignments/opes/ocp/http/response"}); 847 S: NR 848 {"54:http://www.iana.org/assignments/opes/ocp/http/response"}; 849 P: SGC 12 ({"44:ocp-test.example.com/translate?from=EN&to=DE"}); 850 P: TS 89 12; 851 P: AMS 89 852 AM-EL: 86 853 ; 854 P: DUM 89 0 855 AM-Part: response-header 857 65:HTTP/1.1 200 OK 858 Content-Type: text/plain 859 Content-Length: 86 861 ; 862 P: DUM 89 65 863 AM-Part: response-body 865 86:Whether 'tis nobler in the mind to suffer 866 The slings and arrows of outrageous fortune 867 ; 868 P: AME 89; 869 S: AMS 89 870 AM-EL: 78 871 ; 872 P: TE 89; 873 S: DUM 89 0 874 AM-Part: response-header 876 65:HTTP/1.1 200 OK 877 Content-Type: text/plain 878 Content-Length: 78 879 ; 880 S: DUM 89 63 881 AM-Part: response-body 883 80:Ob's edler im Gemuet, die Pfeil und Schleudern 884 des wuetenden Geschicks erdulden 885 ; 886 S: AME 89; 887 S: TE 89; 889 Figure 14 891 The following example shows modification of an HTML resource and 892 demonstrates data preservation optimization. The callout server uses 893 a DUY message to send back an unchanged response header part but 894 because it does not know the size of the altered HTML resource at the 895 time it sends the AMS message, the callout server omits the AM-EL 896 parameter; the OPES processor is responsible for adjusting the 897 Content-Length header. 899 Example: 900 P: CS; 901 S: CS; 902 P: SGC 10 ({"30:ocp-test.example.com/ad-filter"}); 903 P: NO ({"54:http://www.iana.org/assignments/opes/ocp/http/response" 904 Aux-Parts: (request-header,request-body) 905 },{"45:http://www.iana.org/assignments/opes/ocp/MIME"}) 906 SG: 10 907 ; 908 S: NR {"54:http://www.iana.org/assignments/opes/ocp/http/response" 909 Aux-Parts: (request-header) 910 Content-Encodings: (gzip) 911 } 912 SG: 10 913 ; 914 P: TS 88 10; 915 P: AMS 88 916 AM-EL: 95 917 ; 918 P: DUM 88 0 919 AM-Part: request-header 921 65:GET /opes/adsample.html HTTP/1.1 922 Host: www.martin-stecher.de 924 ; 925 P: DUM 88 65 926 Kept: 65 64 927 AM-Part: response-header 929 64:HTTP/1.1 200 OK 930 Content-Type: text/html 931 Content-Length: 95 933 ; 934 P: DUM 88 129 935 Kept: 65 90 936 AM-Part: response-body 938 26: 939 940 This is my 941 ; 942 S: AMS 88; 943 P: DUM 88 155 944 Kept: 65 158 945 AM-Part: response-body 947 68: new ad: 949 950 951 ; 952 S: DUY 88 65 64 953 S: DPI 88 129 2147483647; 954 P: AME 88; 955 S: DUM 88 0 956 AM-Part: response-body 958 52: 959 960 This is my new ad: 961 962 963 ; 964 S: DPI 88 129 0; 965 P: TE 88; 966 S: AME 88; 967 S: TE 88; 969 Figure 15 971 4. Tracing 973 [I-D.ietf-opes-end-comm] defines application-agnostic tracing 974 facilities in OPES. Compliance with this specification requires 975 compliance with [I-D.ietf-opes-end-comm]. When adapting HTTP, trace 976 entries are supplied using HTTP message headers. The following HTTP 977 extension headers are defined to carry trace entries. Their 978 definitions are given using BNF notation and elements defined in 979 [RFC2616]. 981 OPES-System = "OPES-System" ":" #trace-entry 982 OPES-Via = "OPES-Via" ":" #trace-entry 984 trace-entry = opes-agent-id *( ";" parameter ) 985 opes-agent-id = absoluteURI 987 Figure 16 989 An OPES System MUST add its trace entry to the OPES-System header. 990 Other OPES agents MUST use the OPES-Via header if they add their 991 tracing entries. All OPES agents MUST append their entries. 992 Informally, OPES-System is the only required OPES tracing header 993 while OPES-Via provides optional tracing details; both headers 994 reflect the order of trace entry additions. 996 If an OPES-Via header is used in the original application message, an 997 OPES System MUST append its entry to the OPES-Via header. Otherwise, 998 an OPES System MAY append its entry to the OPES-Via header. If an 999 OPES System is using both headers, it MUST add identical trace 1000 entries except it MAY omit some or all trace-entry parameters from 1001 the the OPES-Via header. Informally, the OPES System entries in the 1002 OPES-Via header are used to delimit and group OPES-Via entries from 1003 different OPES Systems without having a priory knowledge about OPES 1004 System identifiers. 1006 Note that all of these headers are defined using #list constructs 1007 and, hence, a valid HTTP message may contain multiple trace entries 1008 per header. OPES agents SHOULD use a single header-field rather than 1009 using multiple equally-named fields to record a long trace. Using 1010 multiple equally-named extension header-fields is illegal from HTTP 1011 point of view and may not work with some of the OPES-unaware HTTP 1012 proxies. 1014 For example, here is an HTTP response message header after OPES 1015 adaptations have been applied by a single OPES processor executing 10 1016 OPES services: 1018 Example: 1019 HTTP/1.1 200 OK 1020 Date: Thu, 18 Sep 2003 06:25:24 GMT 1021 Last-Modified: Wed, 17 Sep 2003 18:24:25 GMT 1022 Content-type: application/octet-stream 1023 OPES-System: http://www.cdn.example.com/opes?session=ac79a749f56 1024 OPES-Via: http://www.cdn.example.com/opes?session=ac79a749f56, 1025 http://www.srvcs-4u.example.com/cat/?sid=123, 1026 http://www.srvcs-4u.example.com/cat/?sid=124, 1027 http://www.srvcs-4u.example.com/cat/?sid=125 ; mode=A 1029 Figure 17 1031 In the above example, the OPES processor has not included its trace 1032 entry or its trace entry was replaced by an OPES system trace entry. 1033 Only 3 out of 10 services are traced. The remaining services did not 1034 include their entries or their entries were removed by OPES system or 1035 processor. The last traced service included a "mode" parameter. 1036 Various identifiers in trace entries will probably have no meaning to 1037 the recipient of the message, but may be decoded by OPES System 1038 software. 1040 OPES entities MAY place optional tracing entries in a message trailer 1041 (i.e., entity-headers at the end of a Chunked-Body of a chunked- 1042 encoded message), provided trailer presence does not violate HTTP 1043 protocol. See [I-D.ietf-opes-end-comm] for a definition of what 1044 tracing entries are optional. OPES entities MUST NOT place required 1045 tracing entries in a message trailer. 1047 5. Bypass 1049 An HTTP extension header is introduced to allow for OPES system 1050 bypass as defined in [I-D.ietf-opes-end-comm]. 1052 OPES-Bypass = "OPES-Bypass" ":" ( "*" | 1#bypass-entry ) 1053 bypass-entry = opes-agent-id 1055 Figure 18 1057 This header can be added to HTTP requests to request OPES system 1058 bypass for the listed OPES agents. The asterisk "*" character is 1059 used to represent all possible OPES agents. 1061 See [I-D.ietf-opes-end-comm] for what can be bypassed and for bypass 1062 requirements. 1064 6. IAB Considerations 1066 OPES treatment of IETF Internet Architecture Board (IAB) 1067 considerations [RFC3238] are documented in "OPES Treatment of IAB 1068 Considerations" [I-D.ietf-opes-iab]. 1070 7. Security Considerations 1072 Application-independent security considerations are documented in 1073 application-agnostic OPES specifications. HTTP profiles do not 1074 introduce any HTTP-specific security considerations. However, that 1075 does not imply that HTTP adaptations are immune from security 1076 threats. 1078 Specific threat examples include such adaptations as rewriting the 1079 Request-URI of an HTTP CONNECT request or removing an HTTP hop-by-hop 1080 Upgrade header before the HTTP proxy can act on it. As with any 1081 adaptation, the OPES agents MUST NOT perform such actions without 1082 HTTP client or server consent. 1084 8. IANA Considerations 1086 The IANA registers request and response profile features 1087 (Section 3.2) using the registration procedure outlined in the "IANA 1088 Considerations" Section of OCP Core [I-D.ietf-opes-ocp-core]. The 1089 corresponding "uri" parameters for the two features are: 1091 o http://www.iana.org/assignments/opes/ocp/http/request 1093 o http://www.iana.org/assignments/opes/ocp/http/response 1095 9. Compliance 1097 Compliance with OPES mechanisms is defined in corresponding 1098 application-agnostic specifications. HTTP profiles for these 1099 mechanisms use corresponding compliance definitions from these 1100 specifications, as if each profile was incorporated into the 1101 application-agnostic specification it profiles. 1103 Appendix A. Acknowledgments 1105 The authors gratefully acknowledge the contributions of Robert 1106 Collins (Syncretize) and Larry Masinter (Adobe). Larry Masinter 1107 provided an early review of this document. 1109 Appendix B. Change Log 1111 Internal WG revision control ID: $Id: http.xml,v 1.78 2005/04/20 04: 1112 57:40 rousskov Exp $ 1114 version 03 1116 * Added IANA Considerations section that was written and sent to 1117 IESG after version 02 in a failed attempt to speed up 1118 publication. 1120 * Updated IANA IDs for request and response features. Slightly 1121 reformatted examples so that updated feature IDs fit RFC line 1122 width. 1124 * Updated examples to use example.com URIs. 1126 * Updated Security Considerations to address Allison Mankin's 1127 DISCUSS. 1129 * Updated Martin's affiliation. 1131 * Use RFC 3978 boilerplate. 1133 * Fixed "ho-by-hop" typo. 1135 2004/01/14 1137 * Polished examples rendering consistency. Use P: and S: 1138 prefixes for all OCP messages. Do not separate messages by 1139 empty lines. Use "Example" caption for all examples. 1141 * Replaced German umlauts in example. 1143 2004/01/13 1145 * Changed Transfer-Encoding header handling rule: OPES processor 1146 MUST delete it when it strips transfer encodings. This seems 1147 like a much more consistent/clean approach than the old SHOULD 1148 rule of leaving the header in. If a logging or similar service 1149 needs virgin headers, that service would either log headers 1150 only (and then stripping transfer encoding is not necessary) or 1151 it will not use HTTP profiles defined here so that it can log 1152 original transfer encodings as well. 1154 * Removed ToDo section. 1156 * Editorial changes. 1158 2004/01/07 1160 * Added second and third example. 1162 * Changed example syntax using now P: and S: prefixes. 1164 * OCP example section with first example 1166 2003/12/19 1168 * Let Pause-At-Body parameter refer to new Paused My Data (DPM) 1169 OCP core message. 1171 * Renamed Wont-Look-Body to Stop-Receiving-Body and changed 1172 reference to Want Stop Receiving Data (DWSR) OCP core message. 1174 * Renamed Wont-Send-Body to Preservation-Interest-Body, reverted 1175 logic of size parameter and changed reference to Data 1176 Preservation Interest (DPI) OCP core message. 1178 2003/12/14 1180 * Added a Selective Adaptation section to cover adaptation of 100 1181 Continue, CONNECT, and other "unusual" HTTP messages. 1183 * Added new requirement: an OPES processor MUST offer all non- 1184 auxiliary original parts in NO messages. Without this 1185 requirement, the "Selective Adaptation" section would make 1186 little sense since vital HTTP message parts could be 1187 selectively skipped by the processor. 1189 * Added an introduction to the OCP section. 1191 * Added an OPES Document Map boilerplate. 1193 2003/12/14 1195 * Explicitly require OCP Core familiarity for OCP HTTP Profile 1196 understanding. 1198 * Added Robert Collins and Larry Masinter to the Acknowledgments 1199 section. 1201 * Renamed "binding" to "profile" as suggested by external 1202 reviews. 1204 2003/11/21 1206 * Moved profile part notes completely to the "Profile Parts" 1207 section and changed labels of original and adapted part lists. 1209 2003/11/18 1211 * Re-documented OPES tracing headers. Use OPES System entries in 1212 OPES-Via to indicate system boundaries. Note that using 1213 multiple OPES- headers may be illegal from HTTP point of view, 1214 but header-values may be repeated. 1216 2003/10/27 1218 * Proof reading. 1220 * Renamed document to draft-ietf-opes-http-01. 1222 * Wont-Send-Body parameter refers to DWSY message and Wont-Look- 1223 Body parameter refers to DWLY messages of OCP core. 1225 2003/10/26 1227 * Deleted resolved XXXes. 1229 * Section "Profile Parts": Cleaned-up and removed ambiguities. 1231 * Renamed Wont-Use-Body to Wont-Send-Body and added Wont-Look- 1232 Body 1234 * Documented OCP parameters in TDM as required by OCP core. 1236 * Adjusted the Profile Negotiation example 1238 * Remove Skip-Parts and added Wont-Use-Body and Pause-At-Body. 1239 We agreed that these parameters solve the what-parts-to-send- 1240 or-skip problem that Skip-Parts introduced. 1242 2003/10/24 1244 * Changed beginning of section HTTP Header Correctness to "When 1245 communicating with HTTP applications, OPES processors MUST..." 1247 * Added second variant of adapted parts for request profile and 1248 so introduced short-circuit possibility for callout services. 1250 * Removed the comment about Transfer-Encoding problems; there is 1251 no problem if we have a MUST that precludes any encodings and a 1252 MUST that terminates the transaction if not all encodings can 1253 be removed. Added 2nd MUST and an informal sentence that warns 1254 for interoperability problems if these rules are violated. 1256 * Renamed optional parts to auxiliary parts; Optional-Parts 1257 parameter becomes Aux-Parts 1259 2003/10/22 1261 * Fixed the after-negotiation part of the profile negotiation 1262 example. 1264 * An OPES processor has to use the adapted version of the skipped 1265 part if it is available or processor's own (original) version 1266 of the part if the callout server did not send an adapted 1267 version. 1269 * AM-Parts not listed in the corresponding section of a 1270 negotiated profile MUST NOT be sent. 1272 * Deleted resolved XXXes. 1274 * Resurrected and polished a note that original parts not 1275 included in the adapted parts list cannot be adapted. 1277 * Skipped parts MAY be sent by processor because a MUST NOT send 1278 requirement would essentially require buffering a potentially 1279 large part at the processor. The MAY requirement moves the 1280 burden to the service, which is likely to be in a better 1281 position than processor to optimize. 1283 * Do not support extension am-parts explicitly; extension/new 1284 profiles can defined them explicitly as needed and a different 1285 profile would most certainly be required to add a meaningful 1286 new part anyway. 1288 * Proof reading 1290 2003/10/21 1292 * Added few more XXXs and commented others. All new comments are 1293 marked with (MS). 1295 * Replaced "am-part string" with "am-part tokens" 1297 2003/10/20 1299 * Made sure that most RFC2119 requirements have a subject. 1301 * Added XXXs to identify places that need more work. 1303 * Added section Application Message Start introducing AM-EL named 1304 parameter 1306 * Removed sizep parameter reference 1308 * Updated Message Size Recalculation section 1310 * Added references to other documents 1312 * Filled bypass section 1314 * Little first proofreading 1316 2003/10/17 1318 * Completed section HTTP Header Correctness 1320 * Note about header correctness in Transfer-Encodings section 1322 2003/10/16 1324 * Removed Transfer-Encodings as a named parameter of profile 1325 feature 1327 * Moved Transfer-Encodings section 1329 * Added section HTTP Header Correctness 1331 2003/10/13 1333 * Filled transfer- and content-encodings paragraphs 1335 * Fixed negotiation example 1337 2003/10/10 1339 * Filled application message part section. 1341 * Added Data Use Mine Message section. 1343 * Restructured, changed and enhanced Callout Protocol section and 1344 subsections. 1346 2003/09/24 1348 * Removed duplicate and empty Tracing section. 1350 * Moved the Bypass section behind the Tracing section. 1352 head-sid13 1354 * Removed HTTP-transaction profile, added optional parts as 1355 feature parameters, added example. 1357 head-sid12 1359 * Initial revision. 1361 10. References 1363 10.1 Normative References 1365 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., 1366 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1367 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1369 [I-D.ietf-opes-end-comm] 1370 Barbir, A., "OPES entities and end points communication", 1371 draft-ietf-opes-end-comm-06 (work in progress), 1372 December 2003. 1374 [I-D.ietf-opes-ocp-core] 1375 Rousskov, A., "OPES Callout Protocol Core", 1376 draft-ietf-opes-ocp-core-04 (work in progress), 1377 December 2003. 1379 10.2 Informative References 1381 [I-D.ietf-opes-architecture] 1382 Barbir, A., "An Architecture for Open Pluggable Edge 1383 Services (OPES)", draft-ietf-opes-architecture-04 (work in 1384 progress), December 2002. 1386 [I-D.ietf-opes-protocol-reqs] 1387 Beck, A., "Requirements for OPES Callout Protocols", 1388 draft-ietf-opes-protocol-reqs-03 (work in progress), 1389 December 2002. 1391 [I-D.ietf-opes-threats] 1392 Barbir, A., "Security Threats and Risks for Open", 1393 draft-ietf-opes-threats-03 (work in progress), 1394 December 2003. 1396 [I-D.ietf-opes-scenarios] 1397 Barbir, A., "OPES Use Cases and Deployment Scenarios", 1398 draft-ietf-opes-scenarios-01 (work in progress), 1399 August 2002. 1401 [I-D.ietf-opes-authorization] 1402 Batuner, O., Beck, A., Chan, T., Orman, H., and A. Barbir, 1403 "Policy, Authorization and Enforcement Requirements of 1404 OPES", draft-ietf-opes-authorization-03 (work in 1405 progress), April 2004. 1407 [I-D.ietf-opes-rules-p] 1408 Beck, A. and A. Rousskov, "P: Message Processing 1409 Language", draft-ietf-opes-rules-p-02 (work in progress), 1410 October 2003. 1412 [I-D.ietf-opes-iab] 1413 Barbir, A. and A. Rousskov, "OPES Treatment of IAB 1414 Considerations", draft-ietf-opes-iab-05 (work in 1415 progress), April 2004. 1417 [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy 1418 Considerations for Open Pluggable Edge Services", 1419 RFC 3238, January 2002. 1421 Authors' Addresses 1423 Alex Rousskov 1424 The Measurement Factory 1426 Email: rousskov@measurement-factory.com 1427 URI: http://www.measurement-factory.com/ 1429 Martin Stecher 1430 CyberGuard Corporation 1431 Vattmannstr. 3 1432 Paderborn 33100 1433 DE 1435 Email: martin.stecher@webwasher.com 1436 URI: http://www.webwasher.com/ 1438 Intellectual Property Statement 1440 The IETF takes no position regarding the validity or scope of any 1441 Intellectual Property Rights or other rights that might be claimed to 1442 pertain to the implementation or use of the technology described in 1443 this document or the extent to which any license under such rights 1444 might or might not be available; nor does it represent that it has 1445 made any independent effort to identify any such rights. Information 1446 on the procedures with respect to rights in RFC documents can be 1447 found in BCP 78 and BCP 79. 1449 Copies of IPR disclosures made to the IETF Secretariat and any 1450 assurances of licenses to be made available, or the result of an 1451 attempt made to obtain a general license or permission for the use of 1452 such proprietary rights by implementers or users of this 1453 specification can be obtained from the IETF on-line IPR repository at 1454 http://www.ietf.org/ipr. 1456 The IETF invites any interested party to bring to its attention any 1457 copyrights, patents or patent applications, or other proprietary 1458 rights that may cover technology that may be required to implement 1459 this standard. Please address the information to the IETF at 1460 ietf-ipr@ietf.org. 1462 Disclaimer of Validity 1464 This document and the information contained herein are provided on an 1465 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1466 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1467 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1468 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1469 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1470 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1472 Copyright Statement 1474 Copyright (C) The Internet Society (2004). This document is subject 1475 to the rights, licenses and restrictions contained in BCP 78, and 1476 except as set forth therein, the authors retain all their rights. 1478 Acknowledgment 1480 Funding for the RFC Editor function is currently provided by the 1481 Internet Society.