Re: [quicwg/base-drafts] HTTP/QUIC without Alt-Svc? (#253)

[Mike Bishop <[e-mail]>]

@mcmanus, I'd agree that we don't need to update 7230 to allow QUIC.  The *authoritative* endpoint for an https origin is a TCP port, and Alt-Svc allows that authoritative endpoint to delegate to different endpoints -- other hosts, other ports, other protocols.  But the authoritative endpoint is always TCP to the port given in the URL.  That's why we're able to use the same scheme and avoid all the branching of stuff underneath it; the origin hasn't changed.

But when there's a service in which the authoritative endpoint is over QUIC -- a device-to-device REST API, or a device's configuration page -- then that requires a different way to express it.  I'd be fine with something like https://www.example.com:q443/, except that RFC 2396 restricts the port number to digits only.  (It's a little odd, in retrospect, that 2396 describes things in terms of IP and port, with no notion of ports being specific to their transport.)  @hardie is right that we're not defining a different name-delegation process here.

I'm leary of saying that clients should (or SHOULD, or even MAY) guess that an origin might be available elsewhere without a way to know that.  That's a proposition we rejec

Sure, we could put a checkbox in the UI or a parameter in the config file that says "'https' doesn't mean what you think it means," then couple that with "prior knowledge" language in the spec.  But it just seems *cleaner* to designate a scheme that's semantically equivalent to 'https' except that the ports in the URI are relative to a different transport protocol.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/253#issuecomment-277391289