Re: issue 381: Discovery of the support of the HTTP2 protocol: DNS-based Upgrade

On Sun, Feb 16, 2014 at 9:01 PM, Josh Goodall <joshua.goodall@gmail.com> wrote:
> On 12/02/2014 11:58 p.m., Salvatore Loreto wrote:
>> +1 x DNS SRV
>>
>> but I think it would be great to generalise its usage to discover if a domain support HTTP/1.1 or HTTP/2 or both
>> independently if they run on different ports or on the same port.
>
> A strong +1 for mandating SRV for HTTP/2.x discovery, because:

I'm open to speccing out SRV for HTTP/2 and potentially using it. But
I think mandating it is silly.

>
> * It is also the way to lookup both IPv4 and IPv6 simultaneously in a single query/response. Today we have unfortunate race conditions with dual-stack browsers issuing double queries. IPv6 needs your support!
>
> * It does away with the naked-domain-can't-be-an-alias bug. Hosting providers everywhere will cheer for you.
>
> * No new protocol should be using A (host) records to find service endpoints, SRV is the proper and extensible way. "A" is for Archaic. Philosophically, we shouldn't lookup a hostname at all, we should lookup a service and be told on which host(s) to find it.
>
> See RFC6186 for a worked example of how SRV records can be adopted for a specific application. Note also, IANA/IETF already expected HTTP to be using SRV, see RFC6335 (BCP165) sec.5 which deprecated "www"... but it just never took off. Well now's the only chance to fix that.

It's not immediately clear to me the extent to switch you are pushing
back on A record use. Do you think in-band discovery (well,
advertisement) via TLS-ALPN or HTTP Upgrade are acceptable mechanisms?
Because that's what we have today, with a potential for also using SRV
records or a new RR type. If you're saying that we can't use the
in-band advertisement mechanisms and MUST ONLY rely on SRV records,
then I'm afraid this is completely unacceptable.

>
>
>
> Josh.
>
>
> * discussed well in http://labs.apnic.net/presentations/store/2012-08-28-dual-stack-quality-apnic34.pdf
>
>

Received on Wednesday, 19 February 2014 01:03:11 UTC