idnits 2.17.1 draft-jennings-http-srv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 174. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 187. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 5, 2008) is 5773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 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: Standards Track July 5, 2008 5 Expires: January 6, 2009 7 DNS SRV Records for HTTP 8 draft-jennings-http-srv-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 6, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies a mechanism for an HTTP client to perform a 42 DNS SRV lookup to find an HTTP server. 44 The draft is being discussed on the apps-discuss@ietf.org list. 46 1. Introduction 48 The scarcity of IPv4 addresses makes it desirable to run HTTP servers 49 on ports other than 80; but URLs like http://www.example.com:3142 are 50 not particular good for humans to remember or use. DNS SRV records 51 allow a DNS lookup of a name like www.example.com to provide both a 52 port and the IP addresses of the HTTP server. 54 This technique is also useful where users wish to run a web server 55 behind a NAT but cannot control which port the NAT will allocate for 56 this server. Analogous situations that arise include residential 57 users who try to run HTTP servers on personal machines. 59 A third use case for HTTP SRV is a situation in which all requests 60 should be sent to a primary server, but if that server is down, then 61 requests fall back to some alternative server. 63 This specification does not update HTTP, and it is not expected that 64 most browsers would support it for generic web use. It would be 65 necessary, and supported, for particular applications using HTTP. 66 For example, a portal such as Facebook often acts a web client and 67 calls specific HTTP-based APIs on other web servers. These APIs may 68 require the use of this specification. In this situation, the end 69 user's web browser might not do the SRV lookup when it browsed to the 70 portal web pages, but the HTTP calls that the portal made out to 71 other sites to generate the content would use this mechanism. As 72 such architectures become more common, DNS SRV would allow many 73 servers that are just providing an API to run on ports other than 80, 74 even though main portal sites may still be running on the well known 75 ports. Eventually, web browsers may end up supporting these SRV 76 lookups, as the implementation is trivial and has very little 77 downside. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 3. Recommendations 87 HTTP[RFC2616] Clients compliant with this specification MUST perform 88 an SRV lookup as specified in [RFC2782] when resolving the host 89 portion of HTTP URI. As defined in the IANA port numbers registry, 90 the service names used are _http and _https. As described in RFC 91 2782, if no SRV record is present, the resolution will fall back on 92 using other DNS records. 94 4. Example 96 In the following example, the client will do a lookup on the URI, 97 which finds the SRV record that then points at the A record that 98 points at the IP address. 100 URI: http://example.com 101 DNS SRV RR: _http._tcp.example.com. SRV 1 0 8080 host1.example.com. 102 DNS A RR: host1.example.com. A 192.0.2.88 104 Figure 1 106 In this case the client would form a TCP connection to 192.0.2.88: 107 8080. 109 5. IANA Considerations 111 This document makes no request of IANA. 113 6. Security Considerations 115 This introduces no new security considerations beyond the common 116 usage of HTTP. It is analogous to DNS CNAME records that redirect to 117 other A records. 119 7. Acknowledgements 121 This idea has been proposed by many people, including Mark Andrews 122 and Thor Kottelin in an internet draft in 2000. 124 8. Normative References 126 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 127 Requirement Levels", BCP 14, RFC 2119, March 1997. 129 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 130 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 131 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 133 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 134 specifying the location of services (DNS SRV)", RFC 2782, 135 February 2000. 137 Author's Address 139 Cullen Jennings 140 Cisco Systems 141 170 West Tasman Drive 142 Mailstop SJC-21/2 143 San Jose, CA 95134 144 USA 146 Phone: +1 408 902-3341 147 Email: fluffy@cisco.com 149 Full Copyright Statement 151 Copyright (C) The IETF Trust (2008). 153 This document is subject to the rights, licenses and restrictions 154 contained in BCP 78, and except as set forth therein, the authors 155 retain all their rights. 157 This document and the information contained herein are provided on an 158 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 159 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 160 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 161 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 162 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 163 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 165 Intellectual Property 167 The IETF takes no position regarding the validity or scope of any 168 Intellectual Property Rights or other rights that might be claimed to 169 pertain to the implementation or use of the technology described in 170 this document or the extent to which any license under such rights 171 might or might not be available; nor does it represent that it has 172 made any independent effort to identify any such rights. Information 173 on the procedures with respect to rights in RFC documents can be 174 found in BCP 78 and BCP 79. 176 Copies of IPR disclosures made to the IETF Secretariat and any 177 assurances of licenses to be made available, or the result of an 178 attempt made to obtain a general license or permission for the use of 179 such proprietary rights by implementers or users of this 180 specification can be obtained from the IETF on-line IPR repository at 181 http://www.ietf.org/ipr. 183 The IETF invites any interested party to bring to its attention any 184 copyrights, patents or patent applications, or other proprietary 185 rights that may cover technology that may be required to implement 186 this standard. Please address the information to the IETF at 187 ietf-ipr@ietf.org. 189 Acknowledgment 191 Funding for the RFC Editor function is provided by the IETF 192 Administrative Support Activity (IASA).