W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2014

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

From: Eliot Lear <lear@cisco.com>
Date: Thu, 20 Feb 2014 17:26:59 +0100
Message-ID: <53062CD3.2040205@cisco.com>
To: Mark Nottingham <mnot@mnot.net>
CC: IETF HTTP WG <ietf-http-wg@w3.org>

On 2/20/14, 10:23 AM, Mark Nottingham wrote:
> On 18 Feb 2014, at 8:52 pm, Eliot Lear <lear@cisco.com> wrote:
>> Replying to myself, I'd like to make one point clear:
>> It is ABSOLUTELY okay to use SRV so long as we accept that in some
>> circumstances there will be some performance degradation, and that we
>> will need to sort versioning beyond h2.  That latter issue implies some
>> IN BAND upgrade mechanism for h2->hN.  In the case of TLS, we might
>> simply handle this with ALPN, but someone from the TLS side should think
>> about this in the context of a fast restart.
> This is what’s concerned me in the past. We’ve made a lot of decisions based upon the assumption that introducing h3…hn (as well as other protocol identifiers) won’t require adding more round trips.
> Now, with ALPN, that may be OK, but it doesn’t help for non-TLS deployments, such as they are.

Well, the round trip is hidden in a TLS capabilities exchange and I
really would like to hear how it plays in the context of fast restart. 
An Upgrade header can accomplish the same goal in non-TLS. 

But let's remember how we got here: we got here because we wanted to NOT
have to have exchanges for ANY of this.  SRV doesn't solve that problem,
but the WG thus far has not decided that it is a problem they want to
solve.  Okay by me.  I put the first draft out there because of the
initial expression of interest.  Maybe there's interest now?  I don't know.

Received on Thursday, 20 February 2014 16:27:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:24 UTC