< 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,
	<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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/