Re: on DNS records

On Wed, Nov 14, 2012 at 10:30:21PM +0000, Adrien W. de Croy wrote:
> 
> If we had change of scheme on the table (which I don't think we do), 
> and possible change of port, then need it be http at all?
> 
> e.g. are we then talking about new protocol on new port?

yes, raw HTTP2 on dedicated default port.

> I'd suggest "http2://" as a scheme name will be unpopular, maybe 
> something more user-friendly for example "web://"

Possibly, yes.

> I think also in the unlikely event that such a proposal went any 
> further, we could look at a new way to determine how to connect etc.
> 
> Web content authors don't want to be concerned about the protocol used 
> to deliver their pages.

But they already do. I really think that's a wrong argument we've already
read here, because many of them are already used to have their application
frameworks build the URLs automatically. They even ask us (the reverse-proxy
guys) to provide some "X-Protocol: https" or "X-SSL: yes" to help them
decide whether to emit "http://" or "https://" in all the pages the build.
So the scheme is not that much of an issue, and certainly not a show-stopper.

> So any new scheme would need to take that out of the hands of the 
> content author, and would therefore need to allow use of http/1.1, 
> http/1.1/tls, http2, ftp, ldap, newproto etc etc.

I'm not sure I'm following you here :-/

> If the spec required that to connect for a web:// URL the client must 
> do a DNS WEB (new RR) record lookup, which could then specify 
> transport, port and server name then all this could be published by the 
> site operator.

We should really not put a MUST here, because it is already incompatible
with plain IP addresses. How did you configure your WiFi router at home ?
You certainly connected to http://192.168.1.1/ and you did not have a
DNS yet. Quite frankly, I don't see what this DNS mess will bring, because
everything is contained in the URI and the DNS only knows how the site is
connected to the net, not how to reach it.

> This would then be extensible, and allow for other transport or 
> transfer protocols to be used for the web in future.

That's precisely what the scheme was made for ! Define what transport
protocol to use to fetch the resource.

Willy

Received on Wednesday, 14 November 2012 22:48:15 UTC