- From: Josh Goodall <joshua@qutonic.com>
- Date: Fri, 28 Feb 2014 06:21:01 +1100
- To: IETF HTTP WG <ietf-http-wg@w3.org>
Hi, On 19 Feb 2014, at 12:02 pm, William Chan (陈智昌) <willchan@chromium.org> wrote: >> 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. Ah, yes. To clarify in standards language: I think support for SRV lookup in clients is a MUST not a MAY, and for the hosting setup probably a SHOULD[1]. I also think it should be preferred, that is, the raw IPv4 and IPv6 address record queries should be tried only after a query for SRV records has failed - and yes this means hosting providers who don’t adopt SRV in their DNS will bear the burden of a triple, rather than a single lookup. Note that this semantic has precedent - it is how the transition to MX records for email delivery was made and is called the “implicit MX” rule. I think HTTP/2.x should have a similar “implicit SRV” rule as the wise way to define the behaviour. See RFC5321 s5.1. So the positive incentive is declarative DNS support for h2 upgrade, which conveniently also supplies adequate support at last for IPv6, apex naked domains, alternative ports and the other benefits of SRV[2]. And performance becomes a stick to drive the adoption donkey.[3] > 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? Yes. I'm not suggesting those should be out. regards Josh. [1] This is a compromise. If one were designing a new protocol with no legacy concerns then I would strongly push for SRV as the only acceptable DNS record type for server discovery. [2] Fallback server & weighted-round-robin if you want them. [3] I know Eliot has expressed concerns about both future-proofing for h3, and for resolver performance at the <10% of sites that have zone cuts at _tcp.example.com in their public DNS. However, I think those are both manageable issues and do not outweigh the benefits of a DNS record that is immediately supported by practically all servers & hosting providers, and that solves several other lingering problems right off the bat.
Received on Thursday, 27 February 2014 19:21:33 UTC