Some recent discussions about the proposed HTTP/3 standard:<p><a href="https://news.ycombinator.com/item?id=18427795" rel="nofollow">https://news.ycombinator.com/item?id=18427795</a><p><a href="https://news.ycombinator.com/item?id=18517047" rel="nofollow">https://news.ycombinator.com/item?id=18517047</a>
Still no SRV record support. Of course.<p><a href="https://news.ycombinator.com/item?id=15906664#15908696" rel="nofollow">https://news.ycombinator.com/item?id=15906664#15908696</a><p><a href="https://news.ycombinator.com/item?id=8549348#8550133" rel="nofollow">https://news.ycombinator.com/item?id=8549348#8550133</a>
For "why not SCTP" please see prior discussions [0]<p>0. <a href="https://hn.algolia.com/?query=%22quic%22%20%22sctp%22&type=all&dateRange=all&prefix&page=0&sort=byDate" rel="nofollow">https://hn.algolia.com/?query=%22quic%22%20%22sctp%22&type=a...</a>
Wow, just reading this RFC makes my more comfortable compare to reading RFC7540. Possibly because they hided a huge portion of technical details under the keyword QUIC.<p>I'm not sure I should continue to implement my HTTP/2 server now, as HTTP/3 will overlay almost (as far as I can tell) all the benefit that provided by HTTP/2.<p>One thing makes me confused though, since:<p>> The QUIC version being used MUST use TLS version 1.3 or greater as its handshake protocol.<p>And most TLS 1.3 implementation supports RFC6066, then why:<p>> .... This may be done using the Server Name Indication (SNI) [RFC6066] extension to TLS <bold>or using some other mechanism</bold>.<p>? I mean, why include any other mechanism while SNI can do the job?