draft-ietf-httpbis-alt-svc-10.txt   draft-ietf-httpbis-alt-svc-11.txt 
HTTP Working Group M. Nottingham HTTP Working Group M. Nottingham
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track P. McManus Intended status: Standards Track P. McManus
Expires: June 17, 2016 Mozilla Expires: August 6, 2016 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
December 15, 2015 February 3, 2016
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-10 draft-ietf-httpbis-alt-svc-11
Abstract Abstract
This document specifies "Alternative Services" for HTTP, which allow This document specifies "Alternative Services" for HTTP, which allow
an origin's resources to be authoritatively available at a separate an origin's resources to be authoritatively available at a separate
network location, possibly accessed with a different protocol network location, possibly accessed with a different protocol
configuration. configuration.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at Working Group information can be found at <http://httpwg.github.io/>;
<https://tools.ietf.org/wg/httpbis/> and <http://httpwg.github.io/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-extensions>. <https://github.com/httpwg/http-extensions>.
The changes in this draft are summarized in Appendix A. The changes in this draft are summarized in Appendix A.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 17, 2016. This Internet-Draft will expire on August 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 39 skipping to change at page 3, line 39
9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17 9.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 17
9.4. Tracking Clients Using Alternative Services . . . . . . . 18 9.4. Tracking Clients Using Alternative Services . . . . . . . 18
9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18 9.5. Confusion Regarding Request Scheme . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 20 10.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 20 publication) . . . . . . . . . . . . . . . . . . . . 20
A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 20
A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20 A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 20
A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 20 A.3. Since draft-ietf-httpbis-alt-svc-01 . . . . . . . . . . . 21
A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21 A.4. Since draft-ietf-httpbis-alt-svc-02 . . . . . . . . . . . 21
A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21 A.5. Since draft-ietf-httpbis-alt-svc-03 . . . . . . . . . . . 21
A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21 A.6. Since draft-ietf-httpbis-alt-svc-04 . . . . . . . . . . . 21
A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 21 A.7. Since draft-ietf-httpbis-alt-svc-05 . . . . . . . . . . . 22
A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22 A.8. Since draft-ietf-httpbis-alt-svc-06 . . . . . . . . . . . 22
A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22 A.9. Since draft-ietf-httpbis-alt-svc-07 . . . . . . . . . . . 22
A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23 A.10. Since draft-ietf-httpbis-alt-svc-08 . . . . . . . . . . . 23
A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 24 A.11. Since draft-ietf-httpbis-alt-svc-09 . . . . . . . . . . . 24
A.12. Since draft-ietf-httpbis-alt-svc-10 . . . . . . . . . . . 24
Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
HTTP [RFC7230] conflates the identification of resources with their HTTP [RFC7230] conflates the identification of resources with their
location. In other words, "http://" (and "https://") URIs are used location. In other words, "http://" (and "https://") URIs are used
to both name and find things to interact with. to both name and find things to interact with.
In some cases, it is desirable to separate identification and In some cases, it is desirable to separate identification and
location in HTTP; keeping the same identifier for a resource, but location in HTTP; keeping the same identifier for a resource, but
skipping to change at page 4, line 50 skipping to change at page 4, line 50
(Section 6) that origin servers (or their nominated alternatives) can (Section 6) that origin servers (or their nominated alternatives) can
use to indicate that they are not authoritative for a given origin, use to indicate that they are not authoritative for a given origin,
in cases where the wrong location is used. in cases where the wrong location is used.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the Augmented BNF defined in [RFC5234] along with This document uses the Augmented BNF defined in [RFC5234] and updated
the "#rule" extension defined in Section 7 of [RFC7230]. The rules by [RFC7405] along with the "#rule" extension defined in Section 7 of
below are defined in [RFC5234], [RFC7230], and [RFC7234]: [RFC7230]. The rules below are defined in [RFC5234], [RFC7230], and
[RFC7234]:
DIGIT = <DIGIT, see [RFC5234], Appendix B.1>
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [RFC7230], Section 3.2.3>
delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1> delta-seconds = <delta-seconds; see [RFC7234], Section 1.2.1>
port = <port, see [RFC7230], Section 2.7> port = <port, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
uri-host = <uri-host, see [RFC7230], Section 2.7> uri-host = <uri-host, see [RFC7230], Section 2.7>
2. Alternative Services Concepts 2. Alternative Services Concepts
This specification defines a new concept in HTTP, the "Alternative This specification defines a new concept in HTTP, the "Alternative
skipping to change at page 7, line 8 skipping to change at page 7, line 8
service(s) associated with an origin. This document describes two service(s) associated with an origin. This document describes two
such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the such mechanisms: the "Alt-Svc" HTTP header field (Section 3) and the
"ALTSVC" HTTP/2 frame type (Section 4). "ALTSVC" HTTP/2 frame type (Section 4).
The remainder of this section describes requirements that are common The remainder of this section describes requirements that are common
to alternative services, regardless of how they are discovered. to alternative services, regardless of how they are discovered.
2.1. Host Authentication 2.1. Host Authentication
Clients MUST NOT use alternative services with a host that is Clients MUST NOT use alternative services with a host that is
different than the origin's without strong server authentication; different from the origin's without strong server authentication;
this mitigates the attack described in Section 9.2. One way to this mitigates the attack described in Section 9.2. One way to
achieve this is for the alternative to use TLS with a certificate achieve this is for the alternative to use TLS with a certificate
that is valid for that origin. that is valid for that origin.
For example, if the origin's host is "www.example.com" and an For example, if the origin's host is "www.example.com" and an
alternative is offered on "other.example.com" with the "h2" protocol, alternative is offered on "other.example.com" with the "h2" protocol,
and the certificate offered is valid for "www.example.com", the and the certificate offered is valid for "www.example.com", the
client can use the alternative. However, if "other.example.com" is client can use the alternative. However, if "other.example.com" is
offered with the "h2c" protocol, the client cannot use it, because offered with the "h2c" protocol, the client cannot use it, because
there is no mechanism in that protocol to establish strong server there is no mechanism in that protocol to establish strong server
skipping to change at page 8, line 14 skipping to change at page 8, line 14
conservation of IP addresses on the alternative service host. conservation of IP addresses on the alternative service host.
Note that the SNI information provided in TLS by the client will be Note that the SNI information provided in TLS by the client will be
that of the origin, not the alternative (as will the Host HTTP header that of the origin, not the alternative (as will the Host HTTP header
field value). field value).
2.4. Using Alternative Services 2.4. Using Alternative Services
By their nature, alternative services are OPTIONAL: clients do not By their nature, alternative services are OPTIONAL: clients do not
need to use them. However, it is advantageous for clients to behave need to use them. However, it is advantageous for clients to behave
in a predictable way when they are used by servers (e.g., for load in a predictable way when alternative services are used by servers
balancing). (e.g., for load balancing).
Therefore, if a client becomes aware of an alternative service, the Therefore, if a client becomes aware of an alternative service, the
client SHOULD use that alternative service for all requests to the client SHOULD use that alternative service for all requests to the
associated origin as soon as it is available, provided the associated origin as soon as it is available, provided the
alternative service information is fresh (Section 2.2) and the alternative service information is fresh (Section 2.2) and the
security properties of the alternative service protocol are security properties of the alternative service protocol are
desirable, as compared to the existing connection. A viable desirable, as compared to the existing connection. A viable
alternative service is then treated in every way as the origin; this alternative service is then treated in every way as the origin; this
includes the ability to advertise alternative services. includes the ability to advertise alternative services.
If a client becomes aware of multiple alternative services, it MAY If a client becomes aware of multiple alternative services, it
choose the most suitable according to its own criteria (again, chooses the most suitable according to its own criteria (again,
keeping security properties in mind). For example, an origin might keeping security properties in mind). For example, an origin might
advertise multiple alternative services to notify clients of support advertise multiple alternative services to notify clients of support
for multiple versions of HTTP. for multiple versions of HTTP.
A client configured to use a proxy for a given request SHOULD NOT A client configured to use a proxy for a given request SHOULD NOT
directly connect to an alternative service for this request, but directly connect to an alternative service for this request, but
instead route it through that proxy. instead route it through that proxy.
When a client uses an alternative service for a request, it can When a client uses an alternative service for a request, it can
indicate this to the server using the Alt-Used header field indicate this to the server using the Alt-Used header field
skipping to change at page 9, line 16 skipping to change at page 9, line 16
the connection to the alternative service MUST be considered to have the connection to the alternative service MUST be considered to have
failed. failed.
3. The Alt-Svc HTTP Header Field 3. The Alt-Svc HTTP Header Field
An HTTP(S) origin server can advertise the availability of An HTTP(S) origin server can advertise the availability of
alternative services to clients by adding an Alt-Svc header field to alternative services to clients by adding an Alt-Svc header field to
responses. responses.
Alt-Svc = clear / 1#alt-value Alt-Svc = clear / 1#alt-value
clear = %x63.6C.65.61.72; "clear", case-sensitive clear = %s"clear"; "clear", case-sensitive
alt-value = alternative *( OWS ";" OWS parameter ) alt-value = alternative *( OWS ";" OWS parameter )
alternative = protocol-id "=" alt-authority alternative = protocol-id "=" alt-authority
protocol-id = token ; percent-encoded ALPN protocol name protocol-id = token ; percent-encoded ALPN protocol name
alt-authority = quoted-string ; containing [ uri-host ] ":" port alt-authority = quoted-string ; containing [ uri-host ] ":" port
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
The field value consists either of a list of values, each of which The field value consists either of a list of values, each of which
indicating one alternative service, or the keyword "clear". indicates one alternative service, or the keyword "clear".
A field value containing the special value "clear" indicates that the A field value containing the special value "clear" indicates that the
origin requests all alternatives for that origin to be invalidated origin requests all alternatives for that origin to be invalidated
(including those specified in the same response, in case of an (including those specified in the same response, in case of an
invalid reply containing both "clear" and alternative services). invalid reply containing both "clear" and alternative services).
ALPN protocol names are octet sequences with no additional ALPN protocol names are octet sequences with no additional
constraints on format. Octets not allowed in tokens ([RFC7230], constraints on format. Octets not allowed in tokens ([RFC7230],
Section 3.2.6) MUST be percent-encoded as per Section 2.1 of Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
[RFC3986]. Consequently, the octet representing the percent [RFC3986]. Consequently, the octet representing the percent
skipping to change at page 12, line 23 skipping to change at page 12, line 23
By default, cached alternative services will be cleared when the By default, cached alternative services will be cleared when the
client detects a network change. Alternative services that are client detects a network change. Alternative services that are
intended to be longer-lived (e.g., those that are not specific to the intended to be longer-lived (e.g., those that are not specific to the
client access network) can carry the "persist" parameter with a value client access network) can carry the "persist" parameter with a value
"1" as a hint that the service is potentially useful beyond a network "1" as a hint that the service is potentially useful beyond a network
configuration change. configuration change.
Syntax: Syntax:
persist = 1DIGIT persist = "1"
For example: For example:
Alt-Svc: h2=":443"; ma=2592000; persist=1 Alt-Svc: h2=":443"; ma=2592000; persist=1
This specification only a defines a single value for "persist"; This specification only a defines a single value for "persist".
others can be defined in future specifications. Clients MUST ignore Clients MUST ignore "persist" parameters with values other than "1".
"persist" parameters with unknown values.
See Section 2.2 for general requirements on caching alternative See Section 2.2 for general requirements on caching alternative
services. services.
4. The ALTSVC HTTP/2 Frame 4. The ALTSVC HTTP/2 Frame
The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the The ALTSVC HTTP/2 frame ([RFC7540], Section 4) advertises the
availability of an alternative service to an HTTP/2 client. availability of an alternative service to an HTTP/2 client.
The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints The ALTSVC frame is a non-critical extension to HTTP/2. Endpoints
skipping to change at page 18, line 13 skipping to change at page 18, line 13
end users) are met. end users) are met.
9.4. Tracking Clients Using Alternative Services 9.4. Tracking Clients Using Alternative Services
Choosing an alternative service implies connecting to a new, server- Choosing an alternative service implies connecting to a new, server-
supplied host name. By using many different (potentially unique) supplied host name. By using many different (potentially unique)
host names, servers could conceivably track client requests. Such host names, servers could conceivably track client requests. Such
tracking could follow users across multiple networks, when the tracking could follow users across multiple networks, when the
"persist" flag is used. "persist" flag is used.
Clients concerned by the additional fingerprinting can choose to Clients that wish to prevent requests from being correlated (such as
ignore alternative service advertisements. those that offer modes aimed at providing improved privacy) can
decide not to use alternative services for multiple requests that
would not otherwise be allowed to be correlated.
In a user agent, any alternative service information MUST be removed In a user agent, any alternative service information MUST be removed
when origin-specific data is cleared (for instance, when cookies are when origin-specific data is cleared (for instance, when cookies are
cleared). cleared).
9.5. Confusion Regarding Request Scheme 9.5. Confusion Regarding Request Scheme
Some server-side HTTP applications make assumptions about security Some server-side HTTP applications make assumptions about security
based upon connection context; for example, equating being served based upon connection context; for example, equating being served
upon port 443 with the use of an "https://" URI (and the various upon port 443 with the use of an "https://" URI (and the various
skipping to change at page 18, line 47 skipping to change at page 18, line 49
is intended for a secure context (e.g., an "https://" URI) to a is intended for a secure context (e.g., an "https://" URI) to a
client that is not treating it as one. client that is not treating it as one.
This risk can be mitigated in servers by using the URI scheme This risk can be mitigated in servers by using the URI scheme
explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the explicitly carried by the protocol (e.g., ":scheme" in HTTP/2 or the
"absolute form" of the request target in HTTP/1.1) as an indication "absolute form" of the request target in HTTP/1.1) as an indication
of security context, instead of other connection properties of security context, instead of other connection properties
([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2). ([RFC7540], Section 8.1.2.3 and [RFC7230], Section 5.3.2).
When the protocol does not explicitly carry the scheme (e.g., as is When the protocol does not explicitly carry the scheme (e.g., as is
usually the case for HTTP/1.1 over TLS, servers can, mitigate this usually the case for HTTP/1.1 over TLS, servers can mitigate this
risk by either assuming that all requests have an insecure context, risk by either assuming that all requests have an insecure context,
or by refraining from advertising alternative services for insecure or by refraining from advertising alternative services for insecure
schemes (such as HTTP). schemes (such as HTTP).
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
skipping to change at page 19, line 21 skipping to change at page 19, line 24
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
RFC5234, January 2008, RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, DOI 10.17487/RFC5890, August 2010, RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
skipping to change at page 20, line 6 skipping to change at page 20, line 8
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <http://www.rfc-editor.org/info/rfc7234>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile, [RFC7301] Friedl, S., Popov, A., Langley, A., and S. Emile,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>. July 2014, <http://www.rfc-editor.org/info/rfc7301>.
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF",
RFC 7405, DOI 10.17487/RFC7405, December 2014,
<http://www.rfc-editor.org/info/rfc7405>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol version 2", RFC 7540, DOI 10.17487/ Transfer Protocol version 2", RFC 7540, DOI 10.17487/
RFC7540, May 2015, RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>. <http://www.rfc-editor.org/info/rfc7540>.
10.2. Informative References 10.2. Informative References
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004, <http://www.rfc-editor.org/info/bcp90>. September 2004, <http://www.rfc-editor.org/info/bcp90>.
skipping to change at page 24, line 17 skipping to change at page 24, line 20
Editorial improvements Editorial improvements
(<https://github.com/httpwg/http-extensions/issues/118>, (<https://github.com/httpwg/http-extensions/issues/118>,
<https://github.com/httpwg/http-extensions/issues/119>, <https://github.com/httpwg/http-extensions/issues/119>,
<https://github.com/httpwg/http-extensions/issues/120>, <https://github.com/httpwg/http-extensions/issues/120>,
<https://github.com/httpwg/http-extensions/issues/121>, <https://github.com/httpwg/http-extensions/issues/121>,
<https://github.com/httpwg/http-extensions/issues/122>, <https://github.com/httpwg/http-extensions/issues/122>,
<https://github.com/httpwg/http-extensions/issues/123>, <https://github.com/httpwg/http-extensions/issues/123>,
<https://github.com/httpwg/http-extensions/issues/125>, <https://github.com/httpwg/http-extensions/issues/125>,
<https://github.com/httpwg/http-extensions/issues/126>). <https://github.com/httpwg/http-extensions/issues/126>).
A.12. Since draft-ietf-httpbis-alt-svc-10
Editorial improvements
(<https://github.com/httpwg/http-extensions/issues/130>).
Use RFC 7405 ABNF extension
(<https://github.com/httpwg/http-extensions/issues/131>).
Appendix B. Acknowledgements Appendix B. Acknowledgements
Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy Thanks to Adam Langley, Bence Beky, Eliot Lear, Erik Nygren, Guy
Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew Podjarny, Herve Ruellan, Lucas Pardue, Martin Thomson, Matthew
Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury, Kerwin, Mike Bishop, Paul Hoffman, Richard Barnes, Richard Bradbury,
Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and Stephen Farrell, Stephen Ludin, and Will Chan for their feedback and
suggestions. suggestions.
The Alt-Svc header field was influenced by the design of the The Alt-Svc header field was influenced by the design of the
Alternate-Protocol header field in SPDY. Alternate-Protocol header field in SPDY.
 End of changes. 24 change blocks. 
28 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/