Shepherd writeup
rfc7838-14

# Shepherd Writeup for Alt-Svc

## 1. Summary

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. 

## 2. Review and Consensus 

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.

## 3. Intellectual Property 

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.

## 4. Other Points 

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