Re: http+srv worth its own URI scheme? (ISSUE-49 schemeProtocols-49)

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 port 1234 and had a SRV record for it. Http client  
A support SRV but client B does not. A gets the URL  
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 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 to point at that port. Then  
someone can use a URL like http+srv:// 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
> Begin forwarded message:
>> From: Mark Nottingham <>
>> Date: 23 February 2009 07:22:43 CEST
>> To: HTTP Working Group <>
>> Subject: Fwd: I-D Action:draft-jennings-http-srv-01.txt
>> Archived-At:
> <
>> FYI.
>> Begin forwarded message:
>>> From:
>>> Date: 23 February 2009 3:45:01 PM
>>> To:
>>> Subject: I-D Action:draft-jennings-http-srv-01.txt
>>> Reply-To:
>>> 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 list.
>>> A URL for this Internet-Draft is:
>>> Internet-Drafts are also available by anonymous FTP at:
>>> 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:
> &lt;
>> &gt;<BR><BR>
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> Internet-Draft directories:
>>> or
> -- 
> Dan Connolly, W3C
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 23 February 2009 19:44:36 UTC