W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: A mechanism to encode HTTP version information in DNS

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 18 Feb 2013 11:41:43 +1300
Message-ID: <51215CA7.5080904@treenet.co.nz>
To: ietf-http-wg@w3.org
On 18/02/2013 11:05 a.m., Phillip Hallam-Baker wrote:
>
>
> On Sun, Feb 17, 2013 at 4:31 PM, Adrien W. de Croy <adrien@qbik.com 
> <mailto:adrien@qbik.com>> wrote:
>
>     I've always thought one of the issues with SRV is the transport is
>     in the wrong part - the name, so you can't specify that with the
>     result.
>     For something new, we should look at putting the transport into
>     the RR data instead of the name
>     then it makes it possible to deploy over multiple transports later
>     on, e.g. SCTP, UDP whatever if desired.
>
>
> That is exactly what the URI RR does, the target is a URI which can of 
> course specify a new scheme.
>
> I think it best to treat _http._tcp as simply a code point 
> corresponding to the http URI scheme and the _tcp part as just a default..
>
> If you wanted to specify a different transport then you would either 
> specify a different scheme or you would specify it as a discovery 
> parameter for that scheme.
>

Or since HTTP is effectively a transport in these respects we have _http 
defined alongside _tcp, and make the under-layer transport an option in 
URI RR

   _http.example.com <http://tcp.example.com>  URI 10 10 
"http://www1.example.com/ TCP HTTP/2.0"

With default option for under-layer being TCP when no other is mentioned 
specifically.

Amos
Received on Sunday, 17 February 2013 22:42:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 February 2013 22:42:17 GMT