- From: Cullen Jennings <fluffy@cisco.com>
- Date: Mon, 23 Feb 2009 12:43:49 -0700
- To: Dan Connolly <connolly@w3.org>
- Cc: www-tag@w3.org, Thomas Roessler <tlr@w3.org>
Hi all, I really should say more about this in the draft and I would appreciate your advice on the topic. The previous -00 version of this draft just used the existing http https schemes and said do SRV. Some people pointed out that this did not work well from a transition or negotiation point of view. Imagine you have a server that was running at www.example.com port 1234 and had a SRV record for it. Http client A support SRV but client B does not. A gets the URL www.example.com and connects to the correct thing. But client B does not know that it can't correctly process this and can not give the user an error, instead it connects to some web server running on port 80 of wherever the A record for www.example.com points to. A new scheme seemed like it provided a way to deal with this transition and errors. That said, I would love it it the major web browsers just did SRV for http URL and it just worked - it's easy to implement and the world would be a better place :-) However, I'm not in a good position to judge the likelihood of anything like that happening or what the best transition path from where we are today to being able to use SRV is but I love any advice the tag has. Thanks, Cullen PS. I'm working with linksys folks so you can do something like have a few NASs in your home behind a full cone NAT. The NAS uses a service like DynDNS to discover a public port on the NAT and then uses DynDNS to configure www.mydomain.dyndns.org to point at that port. Then someone can use a URL like http+srv://www.mydomain.dyndns.org to reach that web server running on the NAS. This works with multiple media servers or NASs in the home and allows things like facebook to reach in and grab that content. It requires no static port forwarding on the NAT and allowed multiple devices behind the same NAT to all do this. When the NAS or NAT reboots or get a different IP address, things all update automatically with no change to the URL. One way or another, I need to solve this problem and ship something but I'm very open to what is the best way to solve it. On Feb 23, 2009, at 11:32 AM, Dan Connolly wrote: > srv records for web servers seems like a fine idea, > long overdue; but I'm skeptical that it's worth a new URI scheme. > > I'm interested to know whether Noah and other TAG members > have other opinions. > > cf. ISSUE-49 schemeProtocols-49 > http://www.w3.org/2001/tag/group/track/issues/49 > > Begin forwarded message: > >> From: Mark Nottingham <mnot@mnot.net> >> Date: 23 February 2009 07:22:43 CEST >> To: HTTP Working Group <ietf-http-wg@w3.org> >> Subject: Fwd: I-D Action:draft-jennings-http-srv-01.txt >> Archived-At: > <http://www.w3.org/mid/327B22FA-F09A-4817-8C2B-E728D5E08274@mnot.net >>> >> >> FYI. >> >> Begin forwarded message: >> >>> From: Internet-Drafts@ietf.org >>> Date: 23 February 2009 3:45:01 PM >>> To: i-d-announce@ietf.org >>> Subject: I-D Action:draft-jennings-http-srv-01.txt >>> Reply-To: internet-drafts@ietf.org >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : DNS SRV Records for HTTP >>> Author(s) : C. Jennings >>> Filename : draft-jennings-http-srv-01.txt >>> Pages : 7 >>> Date : 2009-02-22 >>> >>> This document specifies a new URI scheme called http+srv which >>> uses a >>> DNS SRV lookup to locate a HTTP server. The http+srv scheme >>> operates >>> in the same way as an http scheme but instead of the normal DNS A >>> record lookup that a http scheme would use, it uses an DNS SRV >>> lookup. This memo also defines a https+srv scheme that operates in >>> the same was a an https URI but uses DNS SRV lookups. >>> >>> The draft is being discussed on the apps-discuss@ietf.org list. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-jennings-http-srv-01.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> Below is the data which will enable a MIME compliant mail reader >>> implementation to automatically retrieve the ASCII version of the >>> Internet-Draft. >> Content-Type: text/plain<BR>Content-ID: > <2009-02-22203840.I-D@ietf.org >> ><BR><BR> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > gpg D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E >
Received on Monday, 23 February 2009 19:44:36 UTC