- From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
- Date: Fri, 25 May 2018 17:46:05 +0000
- To: Martin Thomson <martin.thomson@gmail.com>, patrick mcmanus <pmcmanus@mozilla.com>
- CC: QUIC WG <quic@ietf.org>, Mike Bishop <mbishop@evequefou.be>, "HTTP Working Group" <ietf-http-wg@w3.org>
If we assume that HTTP/QUIC will be bootstrapped by Alt-Svc on TCP, then a QPACK Alt-Svc entry is mainly about refreshing liveliness. So ":port" appears as a reasonable option to refresh to self, plus omission of the "ma" parameter implies a freshness of 24 hours (RFC 7838). Anecdotally, I would expect the same Alt-Svc to be sent on every response. However, I don't think that there is any Alt-Svc reasonable general value that can be picked. We've previously discussed the use of UDP port 443. Some of that was punted to the applicability document (https://github.com/quicwg/ops-drafts/issues/26). The HTTP doc kind of skirts this by saying that any port can be used. Is there any danger in optimising for v1 when it is anticipated that QUIC will rev quickly? To summarise, I think a simple Alt-Svc default could cause more harm than good. Lucas ________________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Martin Thomson [martin.thomson@gmail.com] Sent: 24 May 2018 01:50 To: patrick mcmanus Cc: QUIC WG; Mike Bishop; HTTP Working Group Subject: Re: QPACK and the Static Table On Thu, May 24, 2018 at 10:46 AM Patrick McManus <pmcmanus@mozilla.com> wrote:> iirc alt-svc requires a colon and a port (and an alpn) but not a hostname. so quic=":443" would make sense. Ahh, right, then carry on. That's not the interesting case, but it is certainly a good default. I think that it's hq=":443";quic=1 or something like that though. ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. -----------------------------
Received on Friday, 25 May 2018 17:46:39 UTC