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

Dan Connolly asks:

> I'm interested to know whether Noah and other TAG members have other 
opinions.

Short answer: I don't have one that's sufficiently well informed to be 
useful as a net answer, but...

Cullen Jennings wrote:

> Two questions, first when you talk about the overhead of introducing a 
> new URI scheme, are you talking about the difficulty of getting this 
> introduced and used on general web browsers for general web use? I 
> agree that would be hard.

I think it goes beyond the overhead of >introducing< it.  Let's assume 
that this new scheme has become widely deployed, in that servers and 
clients everywhere know about it.  There's still a cost to wiring 
restrictions on how something is accessed into its identifier, I think. 
Let's say that you had a document on a server that needed SRV records, so 
you create a uri http+srv://example.org/mydoc.  Perhaps it's on one of 
those home servers you're trying to support.  Years go by, your site gets 
famous, and you want to rehost it at an ISP.  Well, they better let you 
create an SRV record for your server, whether it's otherwise needed or 
not, because the names (identifiers) of your resource mandate that SRV be 
used.  Maybe that's a problem or maybe it's just a nuissance.

I think you lose some of the other promise of SRV records by relying on 
the URI scheme:  let's say you have three servers you want to consolidate, 
and you don't want to use Apache tricks to share hosting, so you're 
tempted to use SRV records and run servers on multiple ports. 
Unfortunately, all your documents are named with http-scheme URIs, so 
there's no hint to the client to use SRV.  I'm less sure this use case is 
a good one, but I think it's worth consideration.

I think the closest point of comparison is http vs https, which we did 
debate in an earlier incarnation of the TAG when I wrote some of the 
drafts of [1].  I should say that those drafts were put aside because 
there was no consensus on what they tried to say, but at least some 
members expressed the opinion that https in particular was justified 
because URIs are about the contract between an identifer and its referent. 
 When you attempt to access a resource using an https URI it's implicit 
that certain mechanisms such as digital certificates will be used to 
increase the assurance that the correct resource has indeed been 
contacted.  With http, you're more vulnerable to things like DNS spoofing. 
 So, in that sense, https is truly a different namespace from http.  Note 
that https has the same drawbacks listed above for http+srv.  If you 
change hosts from one https server to another for the same resource, then 
the 2nd one must authenticate as well.  That seems appropriate to me

While I see no outright violations of Web architecture in using http+srv, 
it doesn't seem to me to have good cost/benefit, and I'm not sure it 
conveniently meets the use cases you'd want it too.

As I said at the start, don't take the above as a well reasoned net 
answer, but rather as some fragmentary thoughts for discussion.

Noah


[1] http://www.w3.org/2001/tag/doc/SchemeProtocols.html

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Dan Connolly <connolly@w3.org>
Sent by: www-tag-request@w3.org
02/23/2009 01:32 PM
 
        To:     www-tag@w3.org
        cc:     Thomas Roessler <tlr@w3.org>, Cullen Jennings 
<fluffy@cisco.com>, (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        http+srv worth its own URI scheme? (ISSUE-49 
schemeProtocols-49)


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:
&lt;2009-02-22203840.I-D@ietf.org 
> &gt;<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 Friday, 27 March 2009 23:24:38 UTC