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

Re: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc as a normative reference in http/2

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Wed, 19 Mar 2014 13:23:45 -0700
Message-ID: <CAA4WUYh1N8xHOeBe5Whf2wVwyjYjMbckEinerG6ph1k4gaWNwA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Mar 19, 2014 at 1:11 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 19 March 2014 12:52, Julian Reschke <julian.reschke@gmx.de> wrote:
> > I believe we had reached rough consensus to include the header field as
> > well; but it's good that you are bringing this up now.
>
> I don't believe that we need to make a normative dependency on a
> header field definition.  The existence (or absence) of a header field
> shouldn't block progress on the frame definition.
>
> That said, it's unclear to me whether a decoupling like this will have
> any material impact on anything.  The hardest part of this work is in
> defining what it means to add a new route to a given
> origin/authority/server; the mechanical process of representing that
> on the wire is pretty trivial.
>

I agree that we don't need to make a normative dependency on a header field
definition. My interest in removing this as a normative dependency is
because many people are confused about the HTTP/2 spec explicitly defining
how to do TLS for http:// URIs. Yet, my feeling is that some/many/dunno of
us don't want to block the HTTP/2 spec on this, and want to decouple that.
Therefore, I think we should discuss explicitly decoupling that from what
we're depending on in HTTP/2.


>
> I guess the concern here is the larger one: what is permitted to
> re-route to what.  I would have thought that to be largely client
> policy controlled, but I'm happy to have that discussion if people
> feel like a standard should be setting this policy.
>
Received on Wednesday, 19 March 2014 20:24:13 UTC

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