idnits 2.17.1 draft-wood-tae-specifying-uri-transports-06.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 (May 12, 2009) is 5434 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-02 == Outdated reference: A later version (-02) exists of draft-natarajan-http-over-sctp-01 -- 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-03 -- 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 (~~), 4 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 Cisco Systems 4 Intended status: Experimental May 12, 2009 5 Expires: November 13, 2009 7 Specifying transport mechanisms in Uniform Resource Identifiers 8 draft-wood-tae-specifying-uri-transports-06 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 November 13, 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 Uniform Resource 47 Identifier (URI) format that allows preferred transport mechanisms, 48 including protocols, ports and interfaces, to be specified as 49 parseable additions to the scheme name. This explicit configuration 50 is beneficial for separation of the HyperText Transfer Protocol 51 (HTTP) from underlying transports, which has been increasingly 52 recognised as useful when a variety of ways of transporting or 53 configuring use of HTTP are available and a choice of mechanism to 54 use must be indicated. 56 Table of Contents 58 1. Background and Introduction . . . . . . . . . . . . . . . . . . 3 59 2. Extending the URI scheme to indicate transports and 60 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Relevant work . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 67 7.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. Extending the URI scheme to indicate transports and interfaces 135 Before describing this URI scheme syntax, it is worthwhile to lay out 136 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." 165 With this foundation, this draft proposes that schemes can be 166 extended to include configuration elements that indicate transport 167 and interface. These modify use of the http request, and are in the 168 format: 170 scheme = scheme [ "-+" port behaviour ] [ "++" transport ] ["+-" 171 interface ] [ "--" dynamic configuration] 173 where the optionally-included -+port is a description mapping to the 174 default IANA-assigned port number, or the equivalent name, indicating 175 the desired behaviour over a transport. This information is 176 specified locally as service names in e.g. /etc/services on unix 177 machines. 179 The optionally-included ++transport is the transport name or IANA 180 protocol identifier number that that name maps to. As we aim to 181 separate HTTP from TCP and place it over other transports, nicknaming 182 this proposal 'http++' obviously follows. 184 The optionally-included +-interface can contain a locally-meaningful 185 specifier identifying the local interface to use; useful on multi- 186 homed devices. The local interface identifier may identify a virtual 187 or physical interface or one that is only capable of using IPv4, 188 IPv6, or another network protocol (in the case of HTTP being run over 189 something other than a TCP/IP stack.) Defining virtual interfaces 190 limited to one network protocol allows the choice of network protocol 191 to be made. 193 The optionally-included "--" gets configuration information and 194 transport/services to use dynamically via some method, e.g. DNS 195 records, but can be partly overriden by other locally-provided 196 configuration from the other three modifier types described above. 197 This is described more in the 'relevant work' section below. 199 Use of these modifiers would permit http++sctp:// or 200 http-+saratoga++udp:// for the uses outlined in 201 [I-D.natarajan-http-over-sctp] and 202 [I-D.wood-dtnrg-http-dtn-delivery]. Port and internet protocol 203 numbers assigned by IANA are accepted as equivalent to assigned names 204 for these underlying protocols, so http-+7542++17:// specifies HTTP 205 over Saratoga over UDP. http++132 is equivalent to http++sctp in 206 specifying HTTP over SCTP. As is usual, these are case insensitive, 207 so that http++sctp, HTTP++sctp, and HtTp++ScTp are all equivalent. 209 Adding these optional transport indicators to the scheme name does 210 not change the namespace in any way; the URI should still be treated 211 as if it began simply http: and is the http namespace. Similarly, 212 'https++' shares the https namespace, only indicating services, 213 transports and interfaces for the https request to use. 215 This document deliberately does not state what 'http:' by itself 216 implies; local use may invoke dynamic configuration, or simultaneous 217 attempts to use multiple available transports or interfaces. 'http:' 218 is NOT restricted to mean 'http++tcp:'. 220 If required, the port the scheme is actually run over, which the 221 behaviour of any specified default port is mapped to, is still 222 indicated later in the URI as :number, e.g. :80. When this is not 223 specified the default port for that tranport behaviour is used. For 224 example, Saratoga runs over UDP and is assigned default port 7452 by 225 IANA. Saying 'http-+7452:' means do the default behaviour for port 226 7452, i.e. use the Saratoga protocol. http-+7452://blah:1024 227 indicates that the default behaviour on port 7452 - that is, Saratoga 228 - should be carried over to port 1024, i.e. use the Saratoga protocol 229 on port 1024 instead. 231 Knowing that a '-+' service port behaviour stated in the scheme is 232 only associated with either TCP or UDP would mean that ++tcp or ++udp 233 can be omitted when that -+behaviour is given. That is, -+saratoga 234 is known to mean -+saratoga++udp. 236 Being able to specify the local interface to initiate a transaction 237 on when a choice of interfaces is available on a multihomed device is 238 useful, e.g. http-+saratoga+-serial0://. 240 3. Relevant work 242 [I-D.natarajan-http-over-sctp] proposes carrying http over sctp. 243 This can be indicated with http++sctp:. 245 [I-D.wood-dtnrg-http-dtn-delivery] proposes separating HTTP from the 246 underlying transport entirely, and running it over other transports, 247 such as Saratoga [I-D.wood-tsvwg-saratoga]. This can be specified 248 locally with http-+saratoga++udp: or simply http-+saratoga:. 250 We can also use '--' to indicate that information on resolving the 251 URI must be sought from the network. 253 [I-D.jennings-http-srv] has proposed using DNS lookup of a SRV record 254 to return a dynamic port value, as well as an address, and could 255 indicates this using http--srv:// and http--srv:// in line with the 256 use of a service name as indicated above. [Ed note: need to double- 257 check Cullen's current draft.] 259 Alternatively, some new DNS record type returning address, port and 260 other access information could be explicitly accessed via e.g. 261 http--dns:// or some other indication of method. This could take 262 advantage of DNS Name Authority Pointers (NAPTR) via S-NAPTR and 263 U-NAPTR [RFC3958] [RFC4848], and encourage the use of and testing 264 with those protocols before wider deployment. [I-D.faltstrom-uri] 265 expands further on this approach. Both SRV and NAPTR can be used by 266 SIP in allocating SIP servers [RFC3263]. 268 Other work on evolving the URI format to enable service discovery 269 with DNS for different transport protocols is in e.g. [Uruena05]. 271 It should be possible to combine the static configuration in the 272 parseable scheme format described here with getting other 273 configuration information that is not explicitly given, but that is 274 needed to access the URI dyamically, from DNS records when 275 appropriate. Any static information explicitly provided should 276 override information from dynamic configuration, just as explicitly 277 indicating a port with e.g. :80 in the URI explicitly overrides the 278 port returned by http--srv:. 280 4. Security Considerations 282 No additional security concerns have been thought of at this time. 284 5. IANA Considerations 286 No additional IANA considerations have been thought of at this time. 288 6. Acknowledgements 290 Thanks go to Fred Baker, Leslie Daigle, Cullen Jennings, Jonathan 291 Leighton, Preethi Natarajan, Chip Sharp and Dan Wing for discussion 292 on points of this draft. 294 7. References 296 7.1. Normative References 298 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 299 "Guidelines for new URL Schemes", RFC 2718, November 1999. 301 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 302 Resource Identifier (URI): Generic Syntax", STD 66, 303 RFC 3986, January 2005. 305 7.2. Informative References 307 [Deering98] 308 Deering, S., "Watching the Waist of the Protocol 309 Hourglass", keynote, IEEE International Conference on 310 Network Protocols (ICNP), Austin Texas, October 1998. 312 [I-D.faltstrom-uri] 313 Faltstrom, P. and O. Kolkman, "The Uniform Resource 314 Identifier (URI) DNS Resource Record", 315 draft-faltstrom-uri-02 (work in progress), November 2008. 317 [I-D.jennings-http-srv] 318 Jennings, C., "DNS SRV Records for HTTP", 319 draft-jennings-http-srv-05 (work in progress), March 2009. 321 [I-D.natarajan-http-over-sctp] 322 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 323 "Using SCTP as a Transport Layer Protocol for HTTP", 324 draft-natarajan-http-over-sctp-01 (work in progress), 325 March 2009. 327 [I-D.wood-dtnrg-http-dtn-delivery] 328 Wood, L. and P. Holliday, "Using HTTP for delivery in 329 Delay/Disruption-Tolerant Networks", 330 draft-wood-dtnrg-http-delivery-03 (work in progress) , 331 May 2009. 333 [I-D.wood-tsvwg-saratoga] 334 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 335 Jackson, "Saratoga: A Scalable File Transfer Protocol", 336 draft-wood-tsvwg-saratoga-03 (work in progress) , 337 May 2009. 339 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 340 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 341 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 343 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 344 Protocol (SIP): Locating SIP Servers", RFC 3263, 345 June 2002. 347 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 348 Service Location Using SRV RRs and the Dynamic Delegation 349 Discovery Service (DDDS)", RFC 3958, January 2005. 351 [RFC4848] Daigle, L., "Domain-Based Application Service Location 352 Using URIs and the Dynamic Delegation Discovery Service 353 (DDDS)", RFC 4848, April 2007. 355 [Uruena05] 356 Uruena, M. and D. Larrabeiti, "Nested Uniform Resource 357 Identifiers", Proceedings of the 31st EUROMICRO Conference 358 on Software Engineering and Advanced Applications, pp. 359 380-385 , August 2005. 361 Author's Address 363 Lloyd Wood 364 Cisco Systems 365 11 New Square Park, Bedfont Lakes 366 Feltham, Middlesex TW14 8HA 367 United Kingdom 369 Phone: +44-20-8824-4236 370 Email: lwood@cisco.com