idnits 2.17.1 draft-wood-tae-specifying-uri-transports-05.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 (March 23, 2009) is 5506 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 == 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 March 23, 2009 5 Expires: September 24, 2009 7 Specifying transport mechanisms in Uniform Resource Identifiers 8 draft-wood-tae-specifying-uri-transports-05 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 September 24, 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 cannmot 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 indicates 227 that the default behaviour on port 7452 - that is, Saratoga - should 228 be carried over to port 1024, i.e. use the Saratoga protocol on port 229 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. 267 Other work on evolving the URI format to enable service discovery 268 with DNS for different transport protocols is in e.g. [Uruena05]. 270 It should be possible to combine the static configuration in the 271 parseable scheme format described here with getting other 272 configuration information that is not explicitly given, but that is 273 needed to access the URI dyamically, from DNS records when 274 appropriate. Any static information explicitly provided should 275 override information from dynamic configuration, just as explicitly 276 indicating a port with e.g. :80 in the URI explicitly overrides the 277 port returned by http--srv:. 279 4. Security Considerations 281 No additional security concerns have been thought of at this time. 283 5. IANA Considerations 285 No additional IANA considerations have been thought of at this time. 287 6. Acknowledgements 289 Thanks go to Fred Baker, Leslie Daigle, Cullen Jennings, Jonathan 290 Leighton, Preethi Natarajan, Chip Sharp and Dan Wing for discussion 291 on points of this draft. 293 7. References 295 7.1. Normative References 297 [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, 298 "Guidelines for new URL Schemes", RFC 2718, November 1999. 300 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 301 Resource Identifier (URI): Generic Syntax", STD 66, 302 RFC 3986, January 2005. 304 7.2. Informative References 306 [Deering98] 307 Deering, S., "Watching the Waist of the Protocol 308 Hourglass", keynote, IEEE International Conference on 309 Network Protocols (ICNP), Austin Texas, October 1998. 311 [I-D.faltstrom-uri] 312 Faltstrom, P. and O. Kolkman, "The Uniform Resource 313 Identifier (URI) DNS Resource Record", 314 draft-faltstrom-uri-02 (work in progress), November 2008. 316 [I-D.jennings-http-srv] 317 Jennings, C., "DNS SRV Records for HTTP", 318 draft-jennings-http-srv-05 (work in progress), March 2009. 320 [I-D.natarajan-http-over-sctp] 321 Natarajan, P., Amer, P., Leighton, J., and F. Baker, 322 "Using SCTP as a Transport Layer Protocol for HTTP", 323 draft-natarajan-http-over-sctp-01 (work in progress), 324 March 2009. 326 [I-D.wood-dtnrg-http-dtn-delivery] 327 Wood, L. and P. Holliday, "Using HTTP for delivery in 328 Delay/Disruption-Tolerant Networks", 329 draft-wood-dtnrg-http-dtn-delivery-02 (work in progress), 330 October 2008. 332 [I-D.wood-tsvwg-saratoga] 333 Wood, L., McKim, J., Eddy, W., Ivancic, W., and C. 334 Jackson, "Saratoga: A Scalable File Transfer Protocol", 335 draft-wood-tsvwg-saratoga-02 (work in progress), 336 October 2008. 338 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 339 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 340 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 342 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 343 Service Location Using SRV RRs and the Dynamic Delegation 344 Discovery Service (DDDS)", RFC 3958, January 2005. 346 [RFC4848] Daigle, L., "Domain-Based Application Service Location 347 Using URIs and the Dynamic Delegation Discovery Service 348 (DDDS)", RFC 4848, April 2007. 350 [Uruena05] 351 Uruena, M. and D. Larrabeiti, "Nested Uniform Resource 352 Identifiers", Proceedings of the 31st EUROMICRO Conference 353 on Software Engineering and Advanced Applications, pp. 354 380-385 , August 2005. 356 Author's Address 358 Lloyd Wood 359 Cisco Systems 360 11 New Square Park, Bedfont Lakes 361 Feltham, Middlesex TW14 8HA 362 United Kingdom 364 Phone: +44-20-8824-4236 365 Email: lwood@cisco.com