idnits 2.17.1 draft-wood-tae-specifying-uri-transports-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (February 26, 2009) is 5537 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-03 == Outdated reference: A later version (-02) exists of draft-natarajan-http-over-sctp-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: 2 errors (**), 0 flaws (~~), 5 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 February 26, 2009 5 Expires: August 30, 2009 7 Specifying transport mechanisms for retrieval or delivery of URIs 8 draft-wood-tae-specifying-uri-transports-02 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 August 30, 2009. 33 Copyright Notice 35 Copyright (c) 2009 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 in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes a simple extension of the URI format to allow 47 preferred transport mechanisms, including protocols, ports and 48 interfaces, to be specified as parseable additions to the scheme 49 name. This explicit configuration is beneficial for separation of 50 HTTP from underlying transports, which has been increasingly 51 recognised as useful when a variety of ways of transporting or 52 configuring use of HTTP are available and a choice of mechanism to 53 use must be indicated. 55 Table of Contents 57 1. Background and Introduction . . . . . . . . . . . . . . . . . . 3 58 2. Extending the URI scheme to indicate transports and 59 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Relevant work . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Background and Introduction 70 Desire to separate the Hypertext Transfer Protocol (HTTP) [RFC2616] 71 from its traditional transport of the Transmission Control Protocol 72 (TCP) is increasing. 74 There are environments where TCP is not suitable, or absent, yet HTTP 75 can still be used as a method to transfer data. Being able to 76 indicate the desired transport and interface to use in the URI for a 77 program to interpret when executing HTTP GETs or PUTs is useful when 78 a choice of mechanisms and interfaces are available. 80 This document outlines how the desired transport and interface can be 81 indicated in the Uniform Resource Identifier (URI) format [RFC3986] 82 by a simple extension to that format using existing syntax. 84 This syntax is useful for carrying HTTP over different transport 85 protocols. HTTP can be thought of a session layer, running over a 86 transport layer providing reliable delivery of the HTTP stream 87 between hops. This transport layer is commonly (and almost 88 universally) TCP in the terrestrial Internet, although alternative 89 transport layers, such as SCTP, can also be used under HTTP 90 [I-D.natarajan-http-over-sctp]. For long-delay networks, or for 91 network conditions where TCP or an equivalent is not suitable, an 92 alternative transport layer such as Saratoga 93 [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in hop-by- 94 hop communications between nodes. This has been described in detail 95 [I-D.wood-dtnrg-http-dtn-delivery]. HTTP requires only reliable 96 streaming that can be used to provide ordered delivery to the 97 application; how that reliable streaming is provided is up to the 98 local transport layer in the local network. TCP or SCTP would be 99 used to carry HTTP over the congestion-sensitive public Internet, 100 while Saratoga would be used for HTTP across private links. 102 Steve Deering has often described IP as 'the waist in the hourglass' 103 [Deering98] - what is above and touching on IP can be changed, what 104 is below and touching on IP can be changed, but provided the new 105 elements continue to interface to and work with IP, the hourglass 106 remains complete and the network stack remains functional. Here, 107 HTTP is the waist in this particular hourglass; applications can use 108 HTTP to communicate, provided HTTP runs over a reliable transport 109 stream. The applications can vary. The transport stream can be 110 changed; HTTP does not have to run over TCP/IP, but could even be 111 made to run directly over something else entirely. Given the 112 prevalence of IP in many networks, it is likely that two waists 113 exist; IP and HTTP are likely choices, but the transport protocol and 114 physical enviroment will vary more. 116 Being able to specify how HTTP or other schemes are carried is useful 117 when a variety of methods are available to choose from. The syntax 118 described here is useful for local configuration, e.g. in a scripting 119 language that is aware of the local host and remote host's shared 120 support of a given transport protocol. It is less useful on the 121 public world-wide web, because users (and web page designers) are not 122 generally capable of determining which transport protocol(s) are 123 supported by their web browser, operating system, or network. 125 2. Extending the URI scheme to indicate transports and interfaces 127 The URI format syntax ([RFC3986], section 3.1) defines the scheme as: 129 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 131 To quote [RFC2718], section 2.2.2: 133 "When a scheme is associated with a network protocol, the 134 specification should completely describe how URLs are translated into 135 protocol actions in sufficient detail to make the access of the 136 network resource unambiguous. If an implementation of the URL scheme 137 requires some configuration, the configuration elements must be 138 clearly identified." 140 Within these constraints, this draft proposes that schemes can be 141 extended to indicate transport and interface, in the format: 143 scheme = scheme name [ "+" port ] [ "-" transport ] ["." interface ] 145 where the optionally-included +port is a description mapping to the 146 default IANA-assigned port number, or the equivalent name, indicating 147 the desired behaviour over a transport. The optionally-included 148 -transport is the transport name or IANA protocol identifier number 149 that that name maps to. The optionally-included .interface can 150 contain a locally-meaningful specifier identifying that interface. 152 This would permit http-sctp:// or http+saratoga-udp:// for the uses 153 outlined in [I-D.natarajan-http-over-sctp] and 154 [I-D.wood-dtnrg-http-dtn-delivery]. Port and internet protocol 155 numbers assigned by IANA are accepted as equivalent to assigned names 156 for these underlying protocols, so http+7542-17:// specifies HTTP 157 over Saratoga over UDP. http-132 is equivalent to http-sctp in 158 specifying HTTP over SCTP. As is usual, these are case insensitive, 159 so that http-sctp, HTTP-sctp, and HtTp-ScTp are all equivalent. 161 If required, the port the scheme is actually run over, which the 162 behaviour of the specified default port is mapped to, is still 163 indicated later in the URI as :number, e.g. :80. When this is not 164 specified the default port is used. 166 Knowing that a higher-layer protocol is always associated with TCP or 167 UDP would mean that -tcp or -udp could be omitted. http by itself is 168 taken to mean http-tcp, and is therefore backwards-compatible with 169 current use. 171 Being able to specify the local interface to initiate a transaction 172 on when a choice of interfaces is available on a multihomed device is 173 useful, e.g. http+saratoga.serial0://. 175 3. Relevant work 177 [I-D.natarajan-http-over-sctp] proposes carrying http over sctp. 178 This could be indicated with http-sctp:. 180 [I-D.wood-dtnrg-http-dtn-delivery] proposes separating HTTP from the 181 underlying transport entirely, and running it over other other 182 transports, such as Saratoga [I-D.wood-tsvwg-saratoga]. 184 [I-D.jennings-http-srv] has proposed a DNS lookup of a SRV record to 185 return a dynamic port value, as well as an address, and indicates 186 this using http+srv:// and http+srv:// in line with the use of '+' 187 for ports as indicated above. 189 Alternatively, some new DNS record type returning address, port and 190 other access information could be explicitly accessed via e.g. 191 http-dns://. Other work on evolving the URI format to enable service 192 discovery with DNS for different transport protocols is in e.g. 193 [Uruena05]. It should be possible to combine the static 194 configuration in the parseable scheme format described here with 195 getting other configuration information that is not explicitly given, 196 but that is needed to access the URI dyamically, from DNS records 197 when appropriate. Any static information given should override 198 information from dynamic configuration, just as explicitly indicating 199 a port with e.g. :80 in the URI explicitly overrides theport returned 200 by http+srv:. 202 4. Security Considerations 204 No additional security concerns have been thought of at this time. 206 5. IANA Considerations 208 No additional IANA considerations have been thought of at this time. 210 6. References 212 6.1. Normative References 214 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 215 "Guidelines for new URL Schemes", RFC 2718, November 1999. 217 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 218 Resource Identifier (URI): Generic Syntax", STD 66, 219 RFC 3986, January 2005. 221 6.2. Informative References 223 [Deering98] 224 Deering, S., "Watching the Waist of the Protocol 225 Hourglass", keynote, IEEE International Conference on 226 Network Protocols (ICNP), Austin Texas, October 1998. 228 [I-D.jennings-http-srv] 229 Jennings, C., "DNS SRV Records for HTTP", 230 draft-jennings-http-srv-03 (work in progress), 231 February 2009. 233 [I-D.natarajan-http-over-sctp] 234 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 235 "Using SCTP as a Transport Layer Protocol for HTTP", 236 draft-natarajan-http-over-sctp-00 (work in progress), 237 November 2008. 239 [I-D.wood-dtnrg-http-dtn-delivery] 240 Wood, L. and P. Holliday, "Using HTTP for delivery in 241 Delay/Disruption-Tolerant Networks", 242 draft-wood-dtnrg-http-dtn-delivery-02 (work in progress), 243 October 2008. 245 [I-D.wood-tsvwg-saratoga] 246 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 247 Jackson, "Saratoga: A Scalable File Transfer Protocol", 248 draft-wood-tsvwg-saratoga-02 (work in progress), 249 October 2008. 251 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 252 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 253 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 255 [Uruena05] 256 Uruena, M. and D. Larrabeiti, "Nested Uniform Resource 257 Identifiers", Proceedings of the 31st EUROMICRO Conference 258 on Software Engineering and Advanced Applications, pp. 259 380-385 , August 2005. 261 Author's Address 263 Lloyd Wood 264 Cisco Systems 265 11 New Square Park, Bedfont Lakes 266 Feltham, Middlesex TW14 8HA 267 United Kingdom 269 Phone: +44-20-8824-4236 270 Email: lwood@cisco.com