Mike Bishop is the document shepherd; Barry Leiba is the responsible Area Director.
This document specifies a method to provide clients authoritative access to HTTP origins at a different network location and/or using a different protocol stack.
The requested publication type is Proposed Standard.
The document started as an individual draft which provided a potential solution to several related problems in the HTTP space, helping clients become aware of multiple network or protocol endpoints for an origin that could serve the same content in different ways. It drew inspiration from an existing proprietary solution, Alternate-Protocol, used by Chromium during SPDY development.
There was implementation interest from Mozilla Firefox and Akamai, along with willingness from Google Chrome to migrate from Alternate-Protocol to Alt-Svc. Other implementers were less interested, but as the behavior is fully optional for clients, the consensus was to adopt the document. During the HTTP/2 standardization process, the Alt-Svc document was discussed and worked on in parallel; HTTP/2-specific pieces were originally added to the HTTP/2 specification at the time of adoption, but were moved into this document after HTTP/2's extension story was agreed upon.
There has been some interest in defining additional ways to discover Alternative Services, and this document intentionally does not close the door on that. It discusses client behavior when dealing with Alternatives of which it is aware, and defines two possible ways a client can learn about Alternatives. Future drafts may define additional ways, such as DNS.
Technical discussions involved a broad section of the working group, with the most focus from a few client and proxy implementers. There has been some back and forth about the right balance between utility and security, but the document now reflects general consensus. This is reflected by a thoroughly-discussed Security Considerations section, which covers ways in which Alt-Svc could be used to track clients or persist attacks, and gives guidance to implementations on ways to minimize the potential impacts.
Each author has stated that their direct, personal knowledge of any IPR related to this document has already been disclosed, in conformance with BCPs 78 and 79.
No disclosures have been submitted regarding prior work in this space.
There are no downward references. The IANA Considerations are clear, and the Expert Reviewers for the existing registries have been actively involved in the draft process. A new registry is also created for parameters modifying properties of Alt-Svc listings.
There was some discussion over whether parameters would be mandatory-to-understand (ignoring the entire entry otherwise), or always optional. In the end, parameters were made optional-to-understand in all cases, to avoid exploding the list of alternatives when multiple optional parameters were used.