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

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.
>