Subject: draft-jennings-http-srv-00.txt

From: Cullen Jennings <[email-masked]>
Date: Sun, 6 Jul 2008 21:10:35 -0700

This draft proposes the age old idea of using SRV records for HTTP. I  
love to get peoples thoughts over the next month or so.

Thanks, Cullen

Begin forwarded message:

> From: [email-masked]
> Date: July 6, 2008 7:45:01 PM PDT (CA)
> To: [email-masked]
> Subject: I-D Action:draft-jennings-http-srv-00.txt
> Reply-To: [email-masked]
>
> 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-00.txt
> 	Pages           : 5
> 	Date            : 2008-07-06
>
> This document specifies a mechanism for an HTTP client to perform a
> DNS SRV lookup to find an HTTP server.
>
> The draft is being discussed on the [email-masked] list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jennings-http-srv-00.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.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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

_______________________________________________
Apps-Discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Jul 2008 14:11:15 -0700

>love to get peoples thoughts over the next month or so.

Those tiny, white specks you see on the horizon, bobbing up and
down on the waves of change are on a ship.  That ship might, using a
powerful set of lenses, see the ship that has sailed off carrying this idea.
>From where we stand, we cannot even see that ship any more.  It
is far, far below our horizon. 

Having standard browsers change behavior on this one falls
into the category of "not very likely", to put it mildly.  You
give as one of your driving use cases:

   For example, a portal such as Facebook often acts a web client and
   calls specific HTTP-based APIs on other web servers.  These APIs may
   require the use of this specification.  In this situation, the end
   user's web browser might not do the SRV lookup when it browsed to the
   portal web pages, but the HTTP calls that the portal made out to
   other sites to generate the content would use this mechanism.

That would create a (possibly temporary, possibly permanent)
situation in which different classes of application did different things
to resolve the same URI scheme.  Given that the same device
could have both applications (e.g. browser and web server on
the same desktop/laptop), that means they would have to call
different libraries or have code specific to the API.  As we've
discovered in the land of Unicode versioning, relying on the
version of the library you access is tricky and not very likely
to work.  So we really need new APIs completely for this
and some way of disambiguating the situations in which
you call them vs. today's HTTP.  Re-using the same scheme
for this makes it very hard to get that right.   (And I suspect
the security considerations of both coexisting for the foreseeable
future are more than your draft suggests). 

If facebook needs this, they can mint a new URI scheme and run
up a U-NAPTR mechanism that allows them to do cool re-writing.
That gets them a lot more than port numbers (which, in internal
APIs aren't klugy enough to matter much). I'd encourage registration
of that scheme, naturally, but since it is in internal APIs, most things
won't have to know or care.  If there turns out to be a groundswell
of need for interoperability among these APIs, we can produce some
new scheme that covers that need.  But re-using the string
HTTP for it doesn't seem like a good idea to me.

I know I fall on the extreme end of the "strings are cheap"
view of URI schemes, but I think I'm squarely in the middle of
"ambiguity is expensive".  At this stage, this proposal creates
ambiguity (is this X old enough to do A/AAAA only or will it
do SRV then A/AAAA?) for something that seems easily handled
in other ways.

	two cents,
				Ted

>Content-Type: message/external-body; name="mime-attachment"
>Content-Description: mime-attachment
>Content-Disposition: attachment; filename="mime-attachment"; size=330;
>	creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>
>Content-Disposition: attachment; filename="mime-attachment"
>Content-Type: message/external-body; x-unix-mode=0666;
>	name="mime-attachment"
>Content-Transfer-Encoding: 7bit
>
>Content-Type: text/plain<BR>Content-ID: &lt;[email-masked]&gt;<BR><BR>
>
>Content-Type: text/plain; name="ATT00001.txt"
>Content-Description: ATT00001.txt
>Content-Disposition: attachment; filename="ATT00001.txt"; size=336;
>	creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>
>Attachment converted: Macintosh HD:ATT00001 2704.txt (TEXT/ttxt) (007EB89D)
>Content-Type: text/plain; name="ATT00002.txt"
>Content-Description: ATT00002.txt
>Content-Disposition: attachment; filename="ATT00002.txt"; size=215;
>	creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>	modification-date="Mon, 07 Jul 2008 13:25:42 GMT"
>
>Attachment converted: Macintosh HD:ATT00002 687.txt (TEXT/ttxt) (007EB89E)

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jul 2008 18:01:45 -0400

I rarely do this, but

+1

emphatically.  One URI scheme, one resolution mechanism.

    john

--On Monday, 07 July, 2008 14:11 -0700 Ted Hardie
<[email-masked]> wrote:

>> This draft proposes the age old idea of using SRV records for
>> HTTP. I love to get peoples thoughts over the next month or
>> so.
>> 
>> Thanks, Cullen
>> 
> 
> down on the waves of change are on a ship.  That ship might,
> using a powerful set of lenses, see the ship that has sailed
> off carrying this idea. From where we stand, we cannot even
> see that ship any more.  It is far, far below our horizon. 
> 
>    For example, a portal such as Facebook often acts a web
> client and    calls specific HTTP-based APIs on other web
> servers.  These APIs may    require the use of this
> specification.  In this situation, the end    user's web
> browser might not do the SRV lookup when it browsed to the
> portal web pages, but the HTTP calls that the portal made out
> to    other sites to generate the content would use this
> mechanism.
> 
> situation in which different classes of application did
> different things to resolve the same URI scheme.  Given that
> the same device could have both applications (e.g. browser and
> web server on the same desktop/laptop), that means they would
> have to call different libraries or have code specific to the
> API.  As we've discovered in the land of Unicode versioning,
> relying on the version of the library you access is tricky and
> not very likely to work.  So we really need new APIs
> completely for this and some way of disambiguating the
> situations in which you call them vs. today's HTTP.  Re-using
> the same scheme for this makes it very hard to get that right.
> (And I suspect the security considerations of both coexisting
> for the foreseeable future are more than your draft suggests). 
> 
> APIs aren't klugy enough to matter much). I'd encourage
> registration of that scheme, naturally, but since it is in
> internal APIs, most things won't have to know or care.  If
> there turns out to be a groundswell of need for
> interoperability among these APIs, we can produce some new
> scheme that covers that need.  But re-using the string HTTP
> for it doesn't seem like a good idea to me.
> 
>>> A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories.
>>> 
>>> This document specifies a mechanism for an HTTP client to
>>> perform a DNS SRV lookup to find an HTTP server.
>>> 
>>> Below is the data which will enable a MIME compliant mail
>>> reader implementation to automatically retrieve the ASCII
>>> version of the Internet-Draft.
>> 
>> Content-Disposition: attachment; filename="mime-attachment";
>> size=330; creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>> Content-Type: text/plain<BR>Content-ID:
>> &lt;[email-masked]&gt;<BR><BR>
>> 
>> Content-Disposition: attachment; filename="ATT00001.txt";
>> size=336; creation-date="Mon, 07 Jul 2008 13:25:42 GMT";
>> Attachment converted: Macintosh HD:ATT00001 2704.txt
>> (TEXT/ttxt) (007EB89D) Content-Type: text/plain;
>> name="ATT00002.txt"
>> Content-Disposition: attachment; filename="ATT00002.txt";
>> size=215; creation-date="Mon, 07 Jul 2008 13:25:42 GMT";