[Search] [pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08                                    
Network Working Group                                            L. Wood
Internet-Draft                                             Cisco Systems
Intended status: Experimental                          February 26, 2009
Expires: August 30, 2009

   Specifying transport mechanisms for retrieval or delivery of URIs

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 30, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   This document describes a simple extension of the URI format to allow
   preferred transport mechanisms, including protocols, ports and
   interfaces, to be specified as parseable additions to the scheme

Wood                     Expires August 30, 2009                [Page 1]

Internet-Draft          Specifying URI transports          February 2009

   name.  This explicit configuration is beneficial for separation of
   HTTP from underlying transports, which has been increasingly
   recognised as useful when a variety of ways of transporting or
   configuring use of HTTP are available and a choice of mechanism to
   use must be indicated.

Table of Contents

   1.  Background and Introduction . . . . . . . . . . . . . . . . . . 3
   2.  Extending the URI scheme to indicate transports and
       interfaces  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Relevant work . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7

Wood                     Expires August 30, 2009                [Page 2]

Internet-Draft          Specifying URI transports          February 2009

1.  Background and Introduction

   Desire to separate the Hypertext Transfer Protocol (HTTP) [RFC2616]
   from its traditional transport of the Transmission Control Protocol
   (TCP) is increasing.

   There are environments where TCP is not suitable, or absent, yet HTTP
   can still be used as a method to transfer data.  Being able to
   indicate the desired transport and interface to use in the URI for a
   program to interpret when executing HTTP GETs or PUTs is useful when
   a choice of mechanisms and interfaces are available.

   This document outlines how the desired transport and interface can be
   indicated in the Uniform Resource Identifier (URI) format [RFC3986]
   by a simple extension to that format using existing syntax.

   This syntax is useful for carrying HTTP over different transport
   protocols.  HTTP can be thought of a session layer, running over a
   transport layer providing reliable delivery of the HTTP stream
   between hops.  This transport layer is commonly (and almost
   universally) TCP in the terrestrial Internet, although alternative
   transport layers, such as SCTP, can also be used under HTTP
   [I-D.natarajan-http-over-sctp].  For long-delay networks, or for
   network conditions where TCP or an equivalent is not suitable, an
   alternative transport layer such as Saratoga
   [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by-
   hop communications between nodes.  This has been described in detail
   [I-D.wood-dtnrg-http-dtn-delivery].  HTTP requires only reliable
   streaming that can be used to provide ordered delivery to the
   application; how that reliable streaming is provided is up to the
   local transport layer in the local network.  TCP or SCTP would be
   used to carry HTTP over the congestion-sensitive public Internet,
   while Saratoga would be used for HTTP across private links.

   Steve Deering has often described IP as 'the waist in the hourglass'
   [Deering98] - what is above and touching on IP can be changed, what
   is below and touching on IP can be changed, but provided the new
   elements continue to interface to and work with IP, the hourglass
   remains complete and the network stack remains functional.  Here,
   HTTP is the waist in this particular hourglass; applications can use
   HTTP to communicate, provided HTTP runs over a reliable transport
   stream.  The applications can vary.  The transport stream can be
   changed; HTTP does not have to run over TCP/IP, but could even be
   made to run directly over something else entirely.  Given the
   prevalence of IP in many networks, it is likely that two waists
   exist; IP and HTTP are likely choices, but the transport protocol and
   physical enviroment will vary more.

Wood                     Expires August 30, 2009                [Page 3]

Internet-Draft          Specifying URI transports          February 2009

   Being able to specify how HTTP or other schemes are carried is useful
   when a variety of methods are available to choose from.  The syntax
   described here is useful for local configuration, e.g. in a scripting
   language that is aware of the local host and remote host's shared
   support of a given transport protocol.  It is less useful on the
   public world-wide web, because users (and web page designers) are not
   generally capable of determining which transport protocol(s) are
   supported by their web browser, operating system, or network.

2.  Extending the URI scheme to indicate transports and interfaces

   Before describing this URI scheme syntax, it is worthwhile to lay out
   the foundations on which this syntax is based.

   HTTP is not explicitly tied to use over TCP.  To quote [RFC2616],
   section 1.4:

   "HTTP communication usually takes place over TCP/IP connections.  The
   default port is TCP 80, but other ports can be used.  This does not
   preclude HTTP from being implemented on top of any other protocol on
   the Internet, or on other networks.  HTTP only presumes a reliable
   transport; any protocol that provides such guarantees can be used;
   the mapping of the HTTP/1.1 request and response structures onto the
   transport data units of the protocol in question is outside the scope
   of this specification."

   The URI format syntax ([RFC3986], section 3.1) defines the scheme as:

   scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

   To quote [RFC2718], section 2.2.2:

   "When a scheme is associated with a network protocol, the
   specification should completely describe how URLs are translated into
   protocol actions in sufficient detail to make the access of the
   network resource unambiguous.  If an implementation of the URL scheme
   requires some configuration, the configuration elements must be
   clearly identified."

   With this foundation, this draft proposes that schemes can be
   extended to indicate transport and interface, in the format:

   scheme = scheme name [ "+" port ] [ "-" transport ] ["." interface ]

   where the optionally-included +port is a description mapping to the
   default IANA-assigned port number, or the equivalent name, indicating
   the desired behaviour over a transport.

Wood                     Expires August 30, 2009                [Page 4]

Internet-Draft          Specifying URI transports          February 2009

   The optionally-included -transport is the transport name or IANA
   protocol identifier number that that name maps to.  The optionally-
   included .interface can contain a locally-meaningful pecifier
   identifying that interface.

   This would permit http-sctp:// or http+saratoga-udp:// for the uses
   outlined in [I-D.natarajan-http-over-sctp] and
   [I-D.wood-dtnrg-http-dtn-delivery].  Port and internet protocol
   numbers assigned by IANA are accepted as equivalent to assigned names
   for these underlying protocols, so http+7542-17:// specifies HTTP
   over Saratoga over UDP. http-132 is equivalent to http-sctp in
   specifying HTTP over SCTP.  As is usual, these are case insensitive,
   so that http-sctp, HTTP-sctp, and HtTp-ScTp are all equivalent.

   If required, the port the scheme is actually run over, which the
   behaviour of the specified default port is mapped to, is still
   indicated later in the URI as :number, e.g. :80.  When this is not
   specified the default port for that tranport behaviour is used.

   Knowing that a '+' transport behaviour stated in the scheme is only
   associated with either TCP or UDP would mean that -tcp or -udp can be
   omitted when that +behaviour is given.

   Being able to specify the local interface to initiate a transaction
   on when a choice of interfaces is available on a multihomed device is
   useful, e.g. http+saratoga.serial0://.

3.  Relevant work

   [I-D.natarajan-http-over-sctp] proposes carrying http over sctp.
   This could be indicated with http-sctp:.

   [I-D.wood-dtnrg-http-dtn-delivery] proposes separating HTTP from the
   underlying transport entirely, and running it over other other
   transports, such as Saratoga [I-D.wood-tsvwg-saratoga].

   [I-D.jennings-http-srv] has proposed a DNS lookup of a SRV record to
   return a dynamic port value, as well as an address, and indicates
   this using http+srv:// and http+srv:// in line with the use of '+'
   for ports as indicated above.

   Alternatively, some new DNS record type returning address, port and
   other access information could be explicitly accessed via e.g.
   http-dns://.  Other work on evolving the URI format to enable service
   discovery with DNS for different transport protocols is in e.g.
   [Uruena05].  It should be possible to combine the static
   configuration in the parseable scheme format described here with

Wood                     Expires August 30, 2009                [Page 5]

Internet-Draft          Specifying URI transports          February 2009

   getting other configuration information that is not explicitly given,
   but that is needed to access the URI dyamically, from DNS records
   when appropriate.  Any static information given should override
   information from dynamic configuration, just as explicitly indicating
   a port with e.g. :80 in the URI explicitly overrides the port
   returned by http+srv:.

4.  Security Considerations

   No additional security concerns have been thought of at this time.

5.  IANA Considerations

   No additional IANA considerations have been thought of at this time.

6.  Acknowledgements

   Thanks go to Fred Baker, Cullen Jennings, Jonathan Leighton and Dan
   Wing for discussion on points of this draft.

7.  References

7.1.  Normative References

   [RFC2718]  Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
              "Guidelines for new URL Schemes", RFC 2718, November 1999.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

7.2.  Informative References

              Deering, S., "Watching the Waist of the Protocol
              Hourglass", keynote, IEEE International Conference on
              Network Protocols (ICNP), Austin Texas, October 1998.

              Jennings, C., "DNS SRV Records for HTTP",
              draft-jennings-http-srv-04 (work in progress),
              February 2009.


Wood                     Expires August 30, 2009                [Page 6]

Internet-Draft          Specifying URI transports          February 2009

              Natarajan, P., Amer, P., Leighton, J., and F. Baker,
              "Using SCTP as a Transport Layer Protocol for HTTP",
              draft-natarajan-http-over-sctp-00 (work in progress),
              November 2008.

              Wood, L. and P. Holliday, "Using HTTP for delivery in
              Delay/Disruption-Tolerant Networks",
              draft-wood-dtnrg-http-dtn-delivery-02 (work in progress),
              October 2008.

              Wood, L., McKim, J., Eddy, W., Ivancic, W., and C.
              Jackson, "Saratoga: A Scalable File Transfer Protocol",
              draft-wood-tsvwg-saratoga-02 (work in progress),
              October 2008.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

              Uruena, M. and D. Larrabeiti, "Nested Uniform Resource
              Identifiers", Proceedings of the 31st EUROMICRO Conference
              on Software Engineering and Advanced Applications, pp.
              380-385 , August 2005.

Author's Address

   Lloyd Wood
   Cisco Systems
   11 New Square Park, Bedfont Lakes
   Feltham, Middlesex  TW14 8HA
   United Kingdom

   Phone: +44-20-8824-4236
   Email: lwood@cisco.com

Wood                     Expires August 30, 2009                [Page 7]