idnits 2.17.1 draft-jennings-http-srv-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2009) is 5500 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Informational March 7, 2009 5 Expires: September 8, 2009 7 DNS SRV Records for HTTP 8 draft-jennings-http-srv-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. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 8, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document specifies a new URI scheme called http+srv which uses a 57 DNS SRV lookup to locate a HTTP server. The http+srv scheme operates 58 in the same way as an http scheme but instead of the normal DNS 59 lookup that a http scheme would use, it first tries an DNS SRV 60 lookup. This memo also defines a https+srv scheme that operates in 61 the same was as an https URI but uses DNS SRV lookups. 63 The draft is being discussed on the apps-discuss@ietf.org list. 65 Legal 67 This documents and the information contained therein are provided on 68 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 69 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 70 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 71 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 72 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 73 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 74 FOR A PARTICULAR PURPOSE. 76 1. Introduction 78 Web services often define APIs where software running on machine in a 79 data center acts as an HTTP client and performs some http 80 transactions to another HTTP server. For example, a portal such as 81 Facebook can act as a http client and call specific HTTP-based APIs 82 on other http servers. The reality of current networks is a large 83 portion of the hosts have NATed addresses and often can not run on 84 port 80. This is likely to become more common with the deployment of 85 Carrier Grade NAT. DNS SRV records allow a DNS lookup of a name like 86 www.example.com to provide both a port and the IP addresses of the 87 HTTP server. 89 This specification defines two new URI schemes, http+srv, and https+ 90 srv which are like http and https respectively. When a http client 91 uses one of theses schemes to locate a web server, it starts by doing 92 a DNS SRV record lookup and if one is found, uses that result. If no 93 SRV record is found, it falls back to a DNS address (A or AAAA) 94 record. The specification does not update or modify HTTP in any way. 96 It is not expected that most web browsers would support these schemes 97 for generic web use. It would instead be used for particular 98 applications using HTTP such as specific web APIs. These APIs would 99 be defined to require the use of this specification. In this 100 situation, the end user's web browser might not do the SRV lookup 101 when it browsed to the portal web pages, but the HTTP calls that the 102 portal made out to other sites to generate the content would use this 103 mechanism. As such architectures become more common, DNS SRV would 104 allow many servers that are just providing an API to run on ports 105 other than 80 even though main portal sites may still be running on 106 the well known ports. Eventually, web browsers may end up supporting 107 these SRV lookups, as the implementation is trivial and has very 108 little downside. 110 This technique is useful where users wish to run a web server behind 111 a NAT but cannot control which port the NAT will allocate for the 112 service. It is also useful where several users want to run different 113 web servers on the same machine. A third use case for HTTP SRV is a 114 situation in which all requests should be sent to a primary server, 115 but if that server is down, then requests should fall back to an 116 alternative server. 118 2. Open Issues 120 The big open issue seems to be if one should just update the HTTP 121 scheme to do this SRV lookup and not create a new scheme. The 00 122 version of this draft did that. A new scheme makes this somewhat 123 unusable for general web surfing while using the old scheme results 124 in a very long transition times where different clients resolve URLs 125 in different ways. 127 3. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC 2119 [RFC2119]. 133 4. Mechanisms 135 Applications compliant with this specification MUST perform an SRV 136 lookup as specified in [RFC2782] when resolving the host portion of a 137 http+srv or https+srv URI. As defined in the IANA port numbers 138 registry, the service names used are _http and _https respectively. 139 As described in RFC 2782, if no SRV record is present, the resolution 140 will fall back on using other DNS records that would be used by a 141 http scheme as defined in HTTP[RFC2616]. The rest of the http+srv 142 URI is processed in the same way as an http URI in RFC 2616 while the 143 rest of a https+srv scheme URI is processed the same way as a https 144 URI as defined in [RFC2818]. 146 5. Example 148 In the following example, the client will do a lookup on the URI, 149 which finds the SRV record that then points at the A record that 150 points at the IP address. 152 URI: https+srv://example.com 153 DNS SRV RR: _https._tcp.example.com. SRV 1 0 8080 host1.example.com. 154 DNS A RR: host1.example.com. A 192.0.2.88 156 Figure 1 158 In this case the client would form a TCP connection to 192.0.2.88: 159 8080 then start TLS over that connection. Note that the certificate 160 in the TLS handshake would be matched to example.com as that was the 161 names used in the URI and it would not be matched to 162 host1.example.com. 164 6. IANA Considerations 166 This specification registers two provisional URI schemes. 168 6.1. http+srv URI scheme 170 URI scheme name: 172 http+srv 174 Status: 176 provisional 178 URI scheme syntax: 180 Identical to http URI as defined in RFC 2616 but using the 'http+ 181 srv' protocol identifier in place of the 'http' protocol 182 identifier 184 URI scheme semantics: 186 See draft-jennings-http-srv 188 Encoding considerations: 190 No special considerations 192 Applications/protocols that use this URI scheme name: 194 Applications which need to lookup http servers using DNS SRV 196 Interoperability considerations.: 198 None known 200 Security considerations.: 202 Same as http URI. See RFC 2616 204 Contact.: 206 Cullen Jennings 208 Author/Change controller.: 210 Cullen Jennings 212 References.: 214 draft-jennings-http-srv 216 RFC 3986 218 RFC 2616 220 6.2. https+srv URI scheme 222 URI scheme name: 224 https+srv 226 Status: 228 provisional 230 URI scheme syntax: 232 Identical to http URI as defined in RFC 2818 but using the 'https+ 233 srv' protocol identifier in place of the 'https' protocol 234 identifier 236 URI scheme semantics: 238 See draft-jennings-http-srv 240 Encoding considerations: 242 No special considerations 244 Applications/protocols that use this URI scheme name: 246 Applications which need to lookup http servers using DNS SRV 248 Interoperability considerations.: 250 None known 252 Security considerations.: 254 Same as https URI. See RFC 2818 256 Contact.: 258 Cullen Jennings 260 Author/Change controller.: 262 Cullen Jennings 264 References.: 266 draft-jennings-http-srv 268 RFC 3986 270 RFC 2818 272 7. Security Considerations 274 This introduces no new security considerations beyond the common 275 usage of HTTP. It is analogous to DNS CNAME records that redirect 276 address records. 278 8. Acknowledgements 280 Variants of this idea has been proposed by many people, including 281 Mark Andrews and Thor Kottelin in an internet draft in 2000. A 282 related draft[wood-tae-specifying-uri-transports] discusses selecting 283 SCTP for HTTP. 285 Some text came from various documents by Ted Hardie. Thanks to good 286 feedback from many people including Ted Hardie, S. Moonesamy, Cyrus 287 Daboo, Stefanos Harhalakis, Ray Bellis, John Klensin, and Eran 288 Hammer-Lahav. 290 9. References 292 9.1. Normative References 294 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 295 Requirement Levels", BCP 14, RFC 2119, March 1997. 297 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 298 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 299 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 301 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 302 specifying the location of services (DNS SRV)", RFC 2782, 303 February 2000. 305 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 307 9.2. Informative References 309 [wood-tae-specifying-uri-transports] 310 Wood, L., "Specifying transport mechanisms for retrieval 311 or delivery of URIs", 312 draft-wood-tae-specifying-uri-transports-01 (work in 313 progress), December 2008. 315 Author's Address 317 Cullen Jennings 318 Cisco Systems 319 170 West Tasman Drive 320 Mailstop SJC-30 321 San Jose, CA 95134 322 USA 324 Phone: +1 408 902-3341 325 Email: fluffy@cisco.com