idnits 2.17.1 draft-wood-tae-specifying-uri-transports-08.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 (May 8, 2010) is 5073 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 (-14) exists of draft-faltstrom-uri-04 -- No information found for draft-wood-dtnrg-http-delivery - is the name correct? == Outdated reference: A later version (-22) exists of draft-wood-tsvwg-saratoga-05 -- 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 (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Wood 3 Internet-Draft University of Surrey 4 Intended status: Experimental May 8, 2010 5 Expires: November 9, 2010 7 Specifying transport mechanisms in Uniform Resource Identifiers 8 draft-wood-tae-specifying-uri-transports-08 10 Abstract 12 This document describes a simple extension of the Uniform Resource 13 Identifier (URI) format that allows preferred transport mechanisms, 14 including protocols, ports and interfaces, to be specified as 15 parseable additions to the scheme name. This explicit configuration 16 is beneficial for separation of the HyperText Transfer Protocol 17 (HTTP) from underlying transports, which has been increasingly 18 recognised as useful when a variety of ways of transporting or 19 configuring use of HTTP are available and a choice of mechanism to 20 use must be indicated. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 9, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Background and Introduction . . . . . . . . . . . . . . . . . . 3 57 2. Foundations of URI scheme syntax . . . . . . . . . . . . . . . 4 58 3. Extending the URI scheme to indicate transports and 59 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Use of these modifiers . . . . . . . . . . . . . . . . . . . . 5 61 5. Relevant work . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 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, and 81 infrastructure such as DNS cannot be queried for advice. 83 This document outlines how the desired transport and interface can be 84 indicated in the Uniform Resource Identifier (URI) format [RFC3986] 85 by a simple extension to that format using existing syntax. 87 This syntax is useful for carrying HTTP over different transport 88 protocols. HTTP can be thought of a session layer, running over a 89 transport layer providing reliable delivery of the HTTP stream. This 90 transport layer has commonly (and almost universally) been TCP in the 91 terrestrial Internet, although alternative transport layers, such as 92 SCTP, can also be used under HTTP [I-D.natarajan-http-over-sctp]. 93 For long-delay networks, or for network conditions where TCP or an 94 equivalent is not suitable, an alternative transport layer such as 95 Saratoga [I-D.wood-tsvwg-saratoga] can be used under HTTP instead in 96 hop-by-hop communications between nodes. This has been described in 97 detail [I-D.wood-dtnrg-http-dtn-delivery]. 99 HTTP requires only reliable streaming that can be used to provide 100 ordered delivery to the application; how that reliable streaming is 101 provided is up to the local transport layer in the local network. In 102 the examples given above, TCP or SCTP are used to carry HTTP over the 103 congestion-sensitive public Internet, while Saratoga would be used 104 for HTTP across dedicated private links. 106 Steve Deering has often described IP as 'the waist in the hourglass' 107 [Deering98] - what is above and touching on IP can be changed, what 108 is below and touching on IP can be changed, but provided the new 109 elements continue to interface to and work with IP, the hourglass 110 remains complete and the network stack remains functional. Here, 111 HTTP is the waist in this particular hourglass; applications can use 112 HTTP to communicate, provided HTTP runs over a reliable transport 113 stream. The applications can vary. The transport stream can be 114 changed; HTTP does not even have to run over a TCP/IP stack, but 115 could even be made to run directly over something else entirely. 116 Given the prevalence of IP in many networks, it is likely that two 117 popular waists (layers that other layers interface to) exist: IP and 118 HTTP. The transport protocol and physical enviroment that IP and 119 HTTP are used with will vary more, depending on local conditions and 120 needs. 122 Being able to specify how HTTP or other schemes are carried is useful 123 when a variety of methods are available to choose from. The syntax 124 described here is useful for local configuration, e.g. in a scripting 125 language that is aware of the local host and remote host's shared 126 support of a given transport protocol. It is less useful on the 127 public world-wide web, because users (and web page designers) are not 128 generally capable of determining which transport protocol(s) are 129 supported by their web browser, operating system, or network. 130 However, the option to explicitly choose a communication method is 131 useful. 133 2. Foundations of URI scheme syntax 135 Before describing an extension to URI scheme syntax, it is worthwhile 136 to lay out the foundations on which this syntax is based. 138 HTTP is not explicitly tied to use over TCP. To quote [RFC2616], 139 section 1.4: 141 "HTTP communication usually takes place over TCP/IP connections. The 142 default port is TCP 80, but other ports can be used. This does not 143 preclude HTTP from being implemented on top of any other protocol on 144 the Internet, or on other networks. HTTP only presumes a reliable 145 transport; any protocol that provides such guarantees can be used; 146 the mapping of the HTTP/1.1 request and response structures onto the 147 transport data units of the protocol in question is outside the scope 148 of this specification." 150 The URI format syntax ([RFC3986], section 3.1) defines the scheme as: 152 scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) 154 The period (.) is in use in a number of scheme names; the other 155 punctuation characters appear unused. 157 To quote [RFC2718], section 2.2.2: 159 "When a scheme is associated with a network protocol, the 160 specification should completely describe how URLs are translated into 161 protocol actions in sufficient detail to make the access of the 162 network resource unambiguous. If an implementation of the URL scheme 163 requires some configuration, the configuration elements must be 164 clearly identified." 166 3. Extending the URI scheme to indicate transports and interfaces 168 Within the established foundation, this draft proposes that schemes 169 can be extended to include configuration elements that indicate 170 transport and interface. These modify use of the http request, and 171 are in the format as given in the following figure: 173 extended-scheme = scheme ["-+" port-behaviour ] 174 ["++" transport ] 175 ["+-" interface ] 176 ["--" dynamic-configuration] 178 Figure 1 180 where the optionally-included -+port is a description mapping to the 181 default IANA-assigned port number, or the equivalent name, indicating 182 the desired behaviour over a transport. This information is 183 specified locally as service names in e.g. /etc/services on unix 184 machines. 186 The optionally-included ++transport is the transport name or IANA 187 protocol identifier number that that name maps to. As we aim to 188 separate HTTP from TCP and place it over other transports, nicknaming 189 this proposal 'http++' obviously follows. 191 The optionally-included +-interface can contain a locally-meaningful 192 specifier identifying the local interface to use; useful on multi- 193 homed devices. The local interface identifier may identify a virtual 194 or physical interface or one that is only capable of using IPv4, 195 IPv6, or another network protocol (in the case of HTTP being run over 196 something other than a TCP/IP stack.) Defining virtual interfaces 197 limited to one network protocol allows the choice of network protocol 198 to be made. 200 The optionally-included "--" gets configuration information and 201 transport/services to use dynamically via some method, e.g. via DNS 202 records, but can be partly overriden by other locally-provided 203 configuration from the other three modifier types described above. 204 This is described more in the 'relevant work' section below. 206 4. Use of these modifiers 208 Use of these modifiers would permit http++sctp:// or 209 http-+saratoga++udp:// for the uses outlined in 210 [I-D.natarajan-http-over-sctp] and 211 [I-D.wood-dtnrg-http-dtn-delivery]. Port and internet protocol 212 numbers assigned by IANA are accepted as equivalent to assigned names 213 for these underlying protocols, so http-+7542++17:// specifies HTTP 214 over Saratoga over UDP. http++132 is equivalent to http++sctp in 215 specifying HTTP over SCTP. As is usual, these are case insensitive, 216 so that http++sctp, HTTP++sctp, and HtTp++ScTp are all equivalent. 218 Adding these optional transport indicators to the scheme name does 219 not change the namespace in any way; the URI should still be treated 220 as if it began simply http: and is the http namespace. Similarly, 221 'https++' shares the https namespace, only indicating services, 222 transports and interfaces for the https request to use. 224 This document deliberately does not state what 'http:' by itself 225 implies; local use may invoke dynamic configuration, or simultaneous 226 attempts to use multiple available transports or interfaces. 'http:' 227 is NOT restricted to mean 'http++tcp:'. 229 If required, the port the scheme is actually run over, which the 230 behaviour of any specified default port is mapped to, is still 231 indicated later in the URI as :number, e.g. :80. When this is not 232 specified the default port for that tranport behaviour is used. For 233 example, Saratoga runs over UDP and is assigned default port 7452 by 234 IANA. Saying 'http-+7452:' means do the default behaviour for port 235 7452, i.e. use the Saratoga protocol. http-+7452://blah:1024 236 indicates that the default behaviour on port 7452 - that is, Saratoga 237 - should be carried over to port 1024, i.e. use the Saratoga protocol 238 on port 1024 instead. 240 Knowing that a '-+' service port behaviour stated in the scheme is 241 only associated with either TCP or UDP would mean that ++tcp or ++udp 242 can be omitted when that -+behaviour is given. That is, -+saratoga 243 is known to mean -+saratoga++udp. 245 Being able to specify the local interface to initiate a transaction 246 on when a choice of interfaces is available on a multihomed device is 247 useful, e.g. http-+saratoga+-serial0://. 249 5. Relevant work 251 [I-D.natarajan-http-over-sctp] proposes carrying http over sctp. 252 This can be indicated with http++sctp:. 254 [I-D.wood-dtnrg-http-dtn-delivery] proposes separating HTTP from the 255 underlying transport entirely, and running it over other transports, 256 such as Saratoga [I-D.wood-tsvwg-saratoga]. This can be specified 257 locally with http-+saratoga++udp: or simply http-+saratoga:. 259 We can also use '--' to indicate that information on resolving the 260 URI must be sought from the network. 262 [I-D.jennings-http-srv] has proposed using DNS lookup of a SRV record 263 to return a dynamic port value, as well as an address, and could 264 indicate this using http--srv:// and http--srv:// in line with the 265 use of a service name as indicated above. [Ed note: need to double- 266 check Cullen's current draft.] 268 Alternatively, some new DNS record type returning address, port and 269 other access information could be explicitly accessed via e.g. 270 http--dns:// or some other indication of method. This could take 271 advantage of DNS Name Authority Pointers (NAPTR) via S-NAPTR and 272 U-NAPTR [RFC3958] [RFC4848], and encourage the use of and testing 273 with those protocols before wider deployment. [I-D.faltstrom-uri] 274 expands further on this approach. Both SRV and NAPTR can be used by 275 SIP in allocating SIP servers [RFC3263]. 277 Other work on evolving the URI format to enable service discovery 278 with DNS for different transport protocols is in e.g. [Uruena05]. 280 It should be possible to combine the static configuration in the 281 parseable scheme format described here with getting other 282 configuration information that is not explicitly given, but that is 283 needed to access the URI dyamically, from DNS records when 284 appropriate. Any static information explicitly provided should 285 override information from dynamic configuration, just as explicitly 286 indicating a port with e.g. :80 in the URI explicitly overrides the 287 port returned by http--srv:. 289 6. Security Considerations 291 No additional security concerns have been thought of at this time. 293 7. IANA Considerations 295 No additional IANA considerations have been thought of at this time. 297 8. Acknowledgements 299 Thanks go to Fred Baker, Leslie Daigle, Alfred Hoenes, Cullen 300 Jennings, Jonathan Leighton, Preethi Natarajan, Chip Sharp and Dan 301 Wing for discussion on points of this draft. 303 9. References 304 9.1. Normative References 306 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 307 "Guidelines for new URL Schemes", RFC 2718, November 1999. 309 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 310 Resource Identifier (URI): Generic Syntax", STD 66, 311 RFC 3986, January 2005. 313 9.2. Informative References 315 [Deering98] 316 Deering, S., "Watching the Waist of the Protocol 317 Hourglass", keynote, IEEE International Conference on 318 Network Protocols (ICNP), Austin Texas, October 1998. 320 [I-D.faltstrom-uri] 321 Faltstrom, P. and O. Kolkman, "The Uniform Resource 322 Identifier (URI) DNS Resource Record", 323 draft-faltstrom-uri-04 (work in progress), May 2009. 325 [I-D.jennings-http-srv] 326 Jennings, C., "DNS SRV Records for HTTP", 327 draft-jennings-http-srv-05 (work in progress), March 2009. 329 [I-D.natarajan-http-over-sctp] 330 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 331 "Using SCTP as a Transport Layer Protocol for HTTP", 332 draft-natarajan-http-over-sctp-02 (work in progress), 333 July 2009. 335 [I-D.wood-dtnrg-http-dtn-delivery] 336 Wood, L. and P. Holliday, "Using HTTP for delivery in 337 Delay/Disruption-Tolerant Networks", 338 draft-wood-dtnrg-http-delivery-05 (work in progress) , 339 May 2010. 341 [I-D.wood-tsvwg-saratoga] 342 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 343 Jackson, "Saratoga: A Scalable File Transfer Protocol", 344 draft-wood-tsvwg-saratoga-05 (work in progress) , 345 May 2010. 347 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 348 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 349 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 351 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 352 Protocol (SIP): Locating SIP Servers", RFC 3263, 353 June 2002. 355 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 356 Service Location Using SRV RRs and the Dynamic Delegation 357 Discovery Service (DDDS)", RFC 3958, January 2005. 359 [RFC4848] Daigle, L., "Domain-Based Application Service Location 360 Using URIs and the Dynamic Delegation Discovery Service 361 (DDDS)", RFC 4848, April 2007. 363 [Uruena05] 364 Uruena, M. and D. Larrabeiti, "Nested Uniform Resource 365 Identifiers", Proceedings of the 31st EUROMICRO Conference 366 on Software Engineering and Advanced Applications, pp. 367 380-385 , August 2005. 369 Author's Address 371 Lloyd Wood 372 Centre for Communication Systems Research, University of Surrey 373 Guildford, Surrey GU2 7XH 374 United Kingdom 376 Phone: +44-1483-698123 377 Email: L.Wood@surrey.ac.uk