| TOC |
|
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 (C) The Internet Society (2003). All Rights Reserved.
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.
| TOC |
| TOC |
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.
| TOC |
(XXX: document OPES-Trace HTTP extension-header)
| TOC |
(XXX: document OPES-Bypass HTTP extension-header)
| TOC |
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};
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.
(XXX: document HTTP message body encoding feature)
(XXX: document HTTP-specific values of AM-Part: named-parameter of Data Use Mine (DUM) OCP message)
| TOC |
OPES treatment of IETF Internet Architecture Board (IAB) considerations[RFC3238] are documented in [XXX].
| TOC |
Application-independent security considerations are documented in application-agnostic OPES specifications. HTTP binding does not introduce any HTTP-specific security considerations (XXX: really?).
| TOC |
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.
| TOC |
- XXX:
- Fix all XXXs.
| TOC |
Special thanks to Marshall Rose for his xml2rfc tool.
| TOC |
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.
| TOC |
| [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 (TXT, PS, PDF). |
| TOC |
| [RFC3238] | Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. |
| TOC |
| 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/ |
| TOC |
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.
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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the Internet Society.