Open Pluggable Edge Services A. Rousskov Internet-Draft The Measurement Factory Expires: January 12, 2004 M. Stecher webwasher AG July 14, 2003 HTTP adaptation with OPES draft-ietf-opes-http-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 12, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing, OPES bypass, and OPES callout protocol. This document binds those mechanisms to a specific application protocol, HTTP. Together, application-agnostic OPES documents and this HTTP binding constitute a complete specification for HTTP adaptation with OPES. Rousskov & Stecher Expires January 12, 2004 [Page 1] Internet-Draft HTTP adaptation with OPES July 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Callout Protocol . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Application Profile Features . . . . . . . . . . . . . . . . . 6 4.2 Application Body Encoding Feature . . . . . . . . . . . . . . 7 4.3 Application Message Parts . . . . . . . . . . . . . . . . . . 7 5. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. To-do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 B. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Normative References . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Rousskov & Stecher Expires January 12, 2004 [Page 2] Internet-Draft HTTP adaptation with OPES July 2003 1. Introduction Open Pluggable Edge Services (OPES) framework documents several application-agnostic mechanisms such as OPES tracing and bypass [XXX] or OPES callout protocol [XXX]. This document binds those mechanisms to a specific application protocol, HTTP [XXX]. Together, application-agnostic OPES documents and this HTTP binding constitute a complete specification for HTTP adaptation with OPES. The primary sections of this document specify HTTP bindings to the corresponding application-agnostic mechanisms documented elsewhere. Rousskov & Stecher Expires January 12, 2004 [Page 3] Internet-Draft HTTP adaptation with OPES July 2003 2. Tracing (XXX: document OPES-Trace HTTP extension-header) Rousskov & Stecher Expires January 12, 2004 [Page 4] Internet-Draft HTTP adaptation with OPES July 2003 3. Bypass (XXX: document OPES-Bypass HTTP extension-header) Rousskov & Stecher Expires January 12, 2004 [Page 5] Internet-Draft HTTP adaptation with OPES July 2003 4. Callout Protocol 4.1 Application Profile Features Two HTTP profiles are defined for OCP, depending on the original and adapted parts exchanged between OCP agents. These profiles are described below. For both profiles, the feature identifier as well as original and adapted parts are documented; optional parts are marked. Note that not all original parts are meant to be adapted. The order of parts within each flow is mandatory. (XXX: but one might receive a response before a complete request is sent!) Optional parts MUST be indicated as feature parameters, i.e. they are optional in the profile feature description, but once the agents negotiated a profile with optional parts, those parts become mandantory. http://iana.org/opes/ocp/HTTP/request original parts: request-header, request-body, request-trailer adapted parts: request-header, request-body, request-trailer http://iana.org/opes/ocp/HTTP/response original parts: request-header (optional), request-body (optional), request-trailer (optional), response-header, response-body, response-trailer adapted parts: response-header, response-body, response-trailer An agent agreeing to use a given profile during negotiation MUST send, accept, and adapt corresponding application message parts for the duration of the OCP connection (the profile scope). If the agent is unable to send a part, it MUST NOT initiate the transaction or MUST abort already initiated transaction. If an agent does not receive an expected part, and the missing part has not default value, the agent MUST abort the transaction. If an agent receives an unexpected part, the agent MUST abort the transaction. Application message part expectancy is determined based on part identifier alone (and not content). Example: NO ({"38:http://iana.org/opes/ocp/HTTP/response"}, {"38:http://iana.org/opes/ocp/HTTP/response" request-header}); NR {"38:http://iana.org/opes/ocp/HTTP/response" request-header}; Figure 1 Rousskov & Stecher Expires January 12, 2004 [Page 6] Internet-Draft HTTP adaptation with OPES July 2003 Note that the line break in the NO message is for rendering purpose in this document only; the real message MUST NOT have that line break. The OPES processor offers two profile features, both specify HTTP responses; the first profile includes the standard parts only, the second profile includes also the HTTP request header part. The callout server selects the profile with the additional HTTP request information. The application message sent by the OPES processor will then contain the parts request-header, response-header, response-body, response-trailer (in this order) and the callout server will respond with the parts response-header, response-body, response-trailer. 4.2 Application Body Encoding Feature (XXX: document HTTP message body encoding feature) 4.3 Application Message Parts (XXX: document HTTP-specific values of AM-Part: named-parameter of Data Use Mine (DUM) OCP message) Rousskov & Stecher Expires January 12, 2004 [Page 7] Internet-Draft HTTP adaptation with OPES July 2003 5. IAB Considerations OPES treatment of IETF Internet Architecture Board (IAB) considerations [RFC3238] are documented in [XXX]. Rousskov & Stecher Expires January 12, 2004 [Page 8] Internet-Draft HTTP adaptation with OPES July 2003 6. Security Considerations Application-independent security considerations are documented in application-agnostic OPES specifications. HTTP binding does not introduce any HTTP-specific security considerations (XXX: really?). Rousskov & Stecher Expires January 12, 2004 [Page 9] Internet-Draft HTTP adaptation with OPES July 2003 7. Compliance Compliance with OPES mechanisms is defined in corresponding application-agnostic specifications. HTTP-specific bindings for those mechanisms use corresponding compliance definitions from those specifications, as if each binding was incorporated into the application-agnostic specification it binds to. Rousskov & Stecher Expires January 12, 2004 [Page 10] Internet-Draft HTTP adaptation with OPES July 2003 8. To-do XXX: Fix all XXXs. Rousskov & Stecher Expires January 12, 2004 [Page 11] Internet-Draft HTTP adaptation with OPES July 2003 Appendix A. Acknowledgements Special thanks to Marshall Rose for his xml2rfc tool. Rousskov & Stecher Expires January 12, 2004 [Page 12] Internet-Draft HTTP adaptation with OPES July 2003 Appendix B. Change Log Internal WG revision control ID: $Id: http.xml,v 1.15 2003/07/14 20:13:59 rousskov Exp $ head-sid13 * Removed HTTP-transaction profile, added optional parts as feature parameters, added example. head-sid12 * Initial revision. Rousskov & Stecher Expires January 12, 2004 [Page 13] Internet-Draft HTTP adaptation with OPES July 2003 Normative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Rousskov & Stecher Expires January 12, 2004 [Page 14] Internet-Draft HTTP adaptation with OPES July 2003 Informative References [RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. Authors' Addresses Alex Rousskov The Measurement Factory EMail: rousskov@measurement-factory.com URI: http://www.measurement-factory.com/ Martin Stecher webwasher AG Vattmannstr. 3 Paderborn 33100 DE EMail: martin.stecher@webwasher.com URI: http://www.webwasher.com/ Rousskov & Stecher Expires January 12, 2004 [Page 15] Internet-Draft HTTP adaptation with OPES July 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Rousskov & Stecher Expires January 12, 2004 [Page 16] Internet-Draft HTTP adaptation with OPES July 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rousskov & Stecher Expires January 12, 2004 [Page 17]