[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 RFC 4236

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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/