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 draft-wood-tae-specifying-uri-transports-02 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- 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 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. Abstract 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 . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 6.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 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." Within these constraints, 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. 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 specifier 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 Wood Expires August 30, 2009 [Page 4] Internet-Draft Specifying URI transports February 2009 indicated later in the URI as :number, e.g. :80. When this is not specified the default port is used. Knowing that a higher-layer protocol is always associated with TCP or UDP would mean that -tcp or -udp could be omitted. http by itself is taken to mean http-tcp, and is therefore backwards-compatible with current use. 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 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 theport returned by http+srv:. 4. Security Considerations No additional security concerns have been thought of at this time. Wood Expires August 30, 2009 [Page 5] Internet-Draft Specifying URI transports February 2009 5. IANA Considerations No additional IANA considerations have been thought of at this time. 6. References 6.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. 6.2. Informative References [Deering98] Deering, S., "Watching the Waist of the Protocol Hourglass", keynote, IEEE International Conference on Network Protocols (ICNP), Austin Texas, October 1998. [I-D.jennings-http-srv] Jennings, C., "DNS SRV Records for HTTP", draft-jennings-http-srv-03 (work in progress), February 2009. [I-D.natarajan-http-over-sctp] 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. [I-D.wood-dtnrg-http-dtn-delivery] 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. [I-D.wood-tsvwg-saratoga] 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 Wood Expires August 30, 2009 [Page 6] Internet-Draft Specifying URI transports February 2009 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [Uruena05] 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]