idnits 2.17.1 draft-wood-tae-specifying-uri-transports-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 19, 2008) is 5604 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2718 (Obsoleted by RFC 4395) == Outdated reference: A later version (-05) exists of draft-jennings-http-srv-00 == Outdated reference: A later version (-09) exists of draft-wood-dtnrg-http-dtn-delivery-02 == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-02 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft Cisco Systems 4 Intended status: Experimental December 19, 2008 5 Expires: June 22, 2009 7 Specifying transport mechanisms for retrieval or delivery of URIs 8 draft-wood-tae-specifying-uri-transports-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on June 22, 2009. 33 Copyright Notice 35 Copyright (c) 2008 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. 45 Abstract 47 This document describes a simple extension of the URI format to allow 48 preferred transport mechanisms and interfaces to be specified. This 49 explicit configuration is beneficial for separation of HTTP from 50 underlying transports, which has been increasingly recognised as 51 useful. Explicit configuration in the URI for programs is valuable 52 when TCP, traditionally used to carry HTTP, is not present or not 53 desired, or when other methods of determining or negotiating the 54 appropriate transport method to use, e.g. the Domain Name System 55 (DNS), are absent. 57 Table of Contents 59 1. Background and Introduction . . . . . . . . . . . . . . . . . . 3 60 2. Extending the URI scheme to indicate transports and 61 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Background and Introduction 72 Desire to separate the Hypertext Transfer Protocol (HTTP) [RFC2616] 73 from its traditional transport of the Transmission Control Protocol 74 (TCP) is increasing. 76 There are environments where TCP is not suitable, or absent, yet HTTP 77 can still be used as a method to transfer data. Being able to 78 indicate the desired transport and interface to use in the URI for a 79 program to interpret when executing HTTP GETs or PUTs is useful when 80 a choice of mechanisms and interfaces are available. 82 This document outlines how the desired transport and interface can be 83 indicated in the Uniform Resource Identifier (URI) format [RFC3986] 84 by a simple extension to that format using existing syntax. 86 This syntax is useful for carrying HTTP over different transport 87 protocols. HTTP can be thought of a session layer, running over a 88 transport layer providing reliable delivery of the HTTP stream 89 between hops. This transport layer is commonly (and almost 90 universally) TCP in the terrestrial Internet, although alternative 91 transport layers, such as SCTP, can also be used under HTTP 92 [I-D.natarajan-httpbis-sctp]. For long-delay networks, or for 93 network conditions where TCP or an equivalent is not suitable, an 94 alternative transport layer such as Saratoga 95 [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by- 96 hop communications between nodes. This has been described in detail 97 [I-D.wood-dtnrg-http-dtn-delivery]. HTTP requires only reliable 98 streaming that can be used to provide ordered delivery to the 99 application; how that reliable streaming is provided is up to the 100 local transport layer in the local network. TCP or SCTP would be 101 used to carry HTTP over the congestion-sensitive public Internet, 102 while Saratoga would be used for HTTP across private links. 104 Steve Deering has often described IP as 'the waist in the hourglass' 105 [Deering98] - what is above and touching on IP can be changed, what 106 is below and touching on IP can be changed, but provided the new 107 elements continue to interface to and work with IP, the hourglass 108 remains complete and the network stack remains functional. Here, 109 HTTP is the waist in this particular hourglass; applications can use 110 HTTP to communicate, provided HTTP runs over a reliable transport 111 stream. The applications can vary. The transport stream can be 112 changed; HTTP does not have to run over TCP/IP, but could even be 113 made to run directly over something else entirely. Given the 114 prevalence of IP in many networks, it is likely that two waists 115 exist; IP and HTTP are likely choices, but the transport protocol and 116 physical enviroment will vary more. 118 Being able to specify how HTTP or other schemes are carried is useful 119 when a variety of methods are available to choose from. The syntax 120 described here is useful for local configuration, e.g. in a scripting 121 language that is aware of the local host and remote host's shared 122 support of a given transport protocol. It is less useful on the 123 public world-wide web, because users (and web page design) are not 124 generally capable of determining which transport protocol(s) are 125 supported by their web browser, operating system, or network. 127 2. Extending the URI scheme to indicate transports and interfaces 129 The URI format syntax ([RFC3986], section 3.1) defines the scheme as: 131 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 133 To quote [RFC2718], section 2.2.2: 135 "When a scheme is associated with a network protocol, the 136 specification should completely describe how URLs are translated into 137 protocol actions in sufficient detail to make the access of the 138 network resource unambiguous. If an implementation of the URL scheme 139 requires some configuration, the configuration elements must be 140 clearly identified." 142 Within these constraints, this draft proposes that schemes can be 143 extended to indicate transport and interface, in the format: 145 scheme = scheme name [ "+" port ] [ "-" transport ] ["." interface ] 147 where the optionally-included +port is a description mapping to the 148 default IANA-assigned port number, or the equivalent name, indicating 149 the desired behaviour over a transport. The optionally-included 150 -transport is the transport name or IANA protocol identifier number 151 that that name maps to. The optionally-included .interface can 152 contain a locally-meaningful specifier identifying that interface. 154 This would permit http-sctp:// or http+saratoga-udp:// for the uses 155 outlined in [I-D.natarajan-httpbis-sctp] and 156 [I-D.wood-dtnrg-http-dtn-delivery]. Port and internet protocol 157 numbers assigned by IANA are accepted as equivalent to assigned names 158 for these underlying protocols, so http+7542-17:// specifies HTTP 159 over Saratoga over UDP. http-132 is equivalent to http-sctp in 160 specifying HTTP over SCTP. As is usual, these are case insensitive, 161 so that http-sctp, HTTP-sctp, and HtTp-ScTp are all equivalent. 163 If required, the port the scheme is actually run over, which the 164 behaviour of the specified default port is mapped to, is still 165 indicated later in the URI as :number, e.g. :80. When this is not 166 specified the default port is used. 168 Knowing that a higher-layer protocol is always associated with TCP or 169 UDP would mean that -tcp or -udp could be omitted. http by itself is 170 taken to mean http-tcp, and is therefore backwards-compatible with 171 current use. 173 Being able to specify the local interface to initiate a transaction 174 on when a choice of interfaces is available on a multihomed device is 175 useful, e.g. http+saratoga.serial0://. 177 3. Related work 179 [I-D.jennings-http-srv] has proposed a DNS lookup of a SRV record to 180 return a dynamic port value, as well as an address. Rather than 181 overloading existing use of "http://", this could be specially 182 indicated via e.g. http-srv://. Alternatively, some new DNS record 183 type returning address, port and other access information could be 184 explicitly accessed via e.g. http-dns://. 186 Other work on evolving the URI format to enable service discovery 187 with DNS for different transport protocols is in e.g. [Uruena05]. 189 It should be possible to combine the static configuration in the 190 parseable scheme format described here with getting other 191 configuration information that is not explicitly given, but that is 192 needed to access the URI dyamically, from DNS records when 193 appropriate. 195 4. Security Considerations 197 No additional security concerns have been thought of at this time. 199 5. IANA Considerations 201 No additional IANA considerations have been thought of at this time. 203 6. References 205 6.1. Normative References 207 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 208 "Guidelines for new URL Schemes", RFC 2718, November 1999. 210 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 211 Resource Identifier (URI): Generic Syntax", STD 66, 212 RFC 3986, January 2005. 214 6.2. Informative References 216 [Deering98] 217 Deering, S., "Watching the Waist of the Protocol 218 Hourglass", keynote, IEEE International Conference on 219 Network Protocols (ICNP), Austin Texas, October 1998. 221 [I-D.jennings-http-srv] 222 Jennings, C., "DNS SRV Records for HTTP", 223 draft-jennings-http-srv-00 (work in progress), July 2008. 225 [I-D.natarajan-httpbis-sctp] 226 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 227 "Using SCTP as a Transport Layer Protocol for HTTP", 228 draft-natarajan-httpbis-sctp-00 (work in progress), 229 October 2008. 231 [I-D.wood-dtnrg-http-dtn-delivery] 232 Wood, L. and P. Holliday, "Using HTTP for delivery in 233 Delay/Disruption-Tolerant Networks", 234 draft-wood-dtnrg-http-dtn-delivery-02 (work in progress), 235 October 2008. 237 [I-D.wood-tsvwg-saratoga] 238 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 239 Jackson, "Saratoga: A Scalable File Transfer Protocol", 240 draft-wood-tsvwg-saratoga-02 (work in progress), 241 October 2008. 243 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 244 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 245 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 247 [Uruena05] 248 Uruena, M. and D. Larrabeiti, "Nested Uniform Resource 249 Identifiers", Proceedings of the 31st EUROMICRO Conference 250 on Software Engineering and Advanced Applications, pp. 251 380-385 , August 2005. 253 Author's Address 255 Lloyd Wood 256 Cisco Systems 257 11 New Square Park, Bedfont Lakes 258 Feltham, Middlesex TW14 8HA 259 United Kingdom 261 Phone: +44-20-8824-4236 262 Email: lwood@cisco.com