4 ms·

http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/... That’s the final answer f

http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/0674.html http://lists.w3.org/Archives/Public/ietf-http-wg/2015AprJun/... That’s the final answer for HTTP2. They note as well that, were they to have proceeded, that the SRV record type would be inappropriate regardless and some new type would be needed. Therefore, proposing “SRV” to the HTTP working group for HTTP3 will not succeed. Proposing a new DNS record type might succeed, but it would no longer be called SRV. Based on their reply, I warn you to set your expectations low: proposing a new DNS record type to address their stated concerns would likely take enough time itself that it cannot ship a final RFC in time to be considered for HTTP/3.

skissane 8y ago
From Mark Nottingham's email: > the unfortunate limitations of some DNS gateways/proxies With growth in public DNS services like 8.8.8.8 and 1.1.1.1, plus the advent of DNS-over-HTTPS, I wonder for how much longer that will be a problem.
- floatingatoll 8y ago
  TLS 1.3 (2006) was held up for months-to-years by the "unfortunate limitations of some TLS gateways/proxies", and PCI compliance only requires TLS 1.1 as of this year (2018 — 12 years later). What solution is available that avoids high-latency additional round-trip requests and would be compatible with today's "unfortunate" gateways and proxies? DNS-over-HTTPS failed for me constantly while traveling, due to captive wifi portals that try to force you into your browser so they can get your Facebook cookie. DNS-over-HTTPS does not necessarily address the round-trip concerns, as it is simply a transport layer for DNS requests and does not guarantee the browser's ability to coalesce plural DNS requests prior to sending them up for resolution. So in light of TLS slowness and DoH unfamiliarity to the marketplace, I personally would expect Mark's described limitations to remain applicable for at least another ten years.
  - jupp0r 8y ago
    TLS 1.3 was finalized in August 2018, the first draft is from 2014. [1] [1]: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/ https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/
    - floatingatoll 8y ago
      Ugh, too late to fix, but thanks for pointing out the error. It should say TLS 1.1, not 1.3, there.
  - deleted 8y ago
    [deleted]

skissane 8y ago

From Mark Nottingham's email: > the unfortunate limitations of some DNS gateways/proxies With growth in public DNS services like 8.8.8.8 and 1.1.1.1, plus the advent of DNS-over-HTTPS, I wonder for how much longer that will be a problem.

floatingatoll 8y ago
TLS 1.3 (2006) was held up for months-to-years by the "unfortunate limitations of some TLS gateways/proxies", and PCI compliance only requires TLS 1.1 as of this year (2018 — 12 years later). What solution is available that avoids high-latency additional round-trip requests and would be compatible with today's "unfortunate" gateways and proxies? DNS-over-HTTPS failed for me constantly while traveling, due to captive wifi portals that try to force you into your browser so they can get your Facebook cookie. DNS-over-HTTPS does not necessarily address the round-trip concerns, as it is simply a transport layer for DNS requests and does not guarantee the browser's ability to coalesce plural DNS requests prior to sending them up for resolution. So in light of TLS slowness and DoH unfamiliarity to the marketplace, I personally would expect Mark's described limitations to remain applicable for at least another ten years.
- jupp0r 8y ago
  TLS 1.3 was finalized in August 2018, the first draft is from 2014. [1] [1]: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/ https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/00/
  - floatingatoll 8y ago
    Ugh, too late to fix, but thanks for pointing out the error. It should say TLS 1.1, not 1.3, there.
- deleted 8y ago
  [deleted]