RE: draft-ietf-httpbis-alt-svc-12.txt

I agree.  For example, if the proposal of using a .well-known URI to delegate to an Alt-Svc gets traction and becomes an RFC, it could just update Alt-Svc to define that as having assurance as well.

Note that h2c on the same port doesn't need Alt-Svc, since the Upgrade: header from the server is already defined.  So what we're really talking about is h2c *on a different port*.  Honestly, I think if we put it on a different port and publish an Alt-Svc pointing to it, we might as well go direct (i.e. don't Upgrade from HTTP/1.1 on the new connection), which would need a new token anyway.

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, February 10, 2016 12:31 AM
To: Mark Nottingham <mnot@mnot.net>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>; HTTP WG <ietf-http-wg@w3.org>; Patrick McManus <mcmanus@ducksong.com>; Julian F. Reschke <julian.reschke@greenbytes.de>
Subject: Re: draft-ietf-httpbis-alt-svc-12.txt

On 10 February 2016 at 14:31, Mark Nottingham <mnot@mnot.net> wrote:
> This is difficult to specify; one way we could do it is to specify the way we know here (using HTTPS with a strong cert), and require other ways to update this specification (with an Updates: field on the Standards Track).


This seems reasonable.  If h2c starts to see wider deployment, then a good definition for that that assurance might look like will have to emerge (or alt-svc won't be used there).

Received on Wednesday, 10 February 2016 21:32:03 UTC