< draft-ietf-httpbis-bcp56bis-13.txt		draft-ietf-httpbis-bcp56bis-14.txt >
	HTTP M. Nottingham		HTTP M. Nottingham
	Internet-Draft 3 August 2021		Internet-Draft 17 August 2021
	Obsoletes: 3205 (if approved)		Obsoletes: 3205 (if approved)
	Intended status: Best Current Practice		Intended status: Best Current Practice
	Expires: 4 February 2022		Expires: 18 February 2022
	Building Protocols with HTTP		Building Protocols with HTTP
	draft-ietf-httpbis-bcp56bis-13		draft-ietf-httpbis-bcp56bis-14
	Abstract		Abstract
	Applications often use HTTP as a substrate to create HTTP-based APIs.		Applications often use HTTP as a substrate to create HTTP-based APIs.
	This document specifies best practices for writing specifications		This document specifies best practices for writing specifications
	that use HTTP to define new application protocols. It is written		that use HTTP to define new application protocols. It is written
	primarily to guide IETF efforts to define application protocols using		primarily to guide IETF efforts to define application protocols using
	HTTP for deployment on the Internet, but might be applicable in other		HTTP for deployment on the Internet, but might be applicable in other
	situations.		situations.
	skipping to change at page 2, line 10 ¶		skipping to change at page 2, line 10 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 4 February 2022.		This Internet-Draft will expire on 18 February 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Rich Functionality . . . . . . . . . . . . . . . . . . . 7		3.3. Rich Functionality . . . . . . . . . . . . . . . . . . . 7
	4. Best Practices for Specifying the Use of HTTP . . . . . . . . 8		4. Best Practices for Specifying the Use of HTTP . . . . . . . . 8
	4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8		4.1. Specifying the Use of HTTP . . . . . . . . . . . . . . . 8
	4.2. Specifying Server Behaviour . . . . . . . . . . . . . . . 9		4.2. Specifying Server Behaviour . . . . . . . . . . . . . . . 9
	4.3. Specifying Client Behaviour . . . . . . . . . . . . . . . 10		4.3. Specifying Client Behaviour . . . . . . . . . . . . . . . 10
	4.4. Specifying URLs . . . . . . . . . . . . . . . . . . . . . 11		4.4. Specifying URLs . . . . . . . . . . . . . . . . . . . . . 11
	4.4.1. Discovering an Application's URLs . . . . . . . . . . 11		4.4.1. Discovering an Application's URLs . . . . . . . . . . 11
	4.4.2. Considering URI Schemes . . . . . . . . . . . . . . . 12		4.4.2. Considering URI Schemes . . . . . . . . . . . . . . . 12
	4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 13		4.4.3. Transport Ports . . . . . . . . . . . . . . . . . . . 13
	4.5. Using HTTP Methods . . . . . . . . . . . . . . . . . . . 14		4.5. Using HTTP Methods . . . . . . . . . . . . . . . . . . . 13
	4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.5.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 15		4.5.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 15
	4.6. Using HTTP Status Codes . . . . . . . . . . . . . . . . . 16		4.6. Using HTTP Status Codes . . . . . . . . . . . . . . . . . 16
	4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 17		4.6.1. Redirection . . . . . . . . . . . . . . . . . . . . . 17
	4.7. Specifying HTTP Header Fields . . . . . . . . . . . . . . 18		4.7. Specifying HTTP Header Fields . . . . . . . . . . . . . . 18
	4.8. Defining Message Content . . . . . . . . . . . . . . . . 20		4.8. Defining Message Content . . . . . . . . . . . . . . . . 20
	4.9. Leveraging HTTP Caching . . . . . . . . . . . . . . . . . 20		4.9. Leveraging HTTP Caching . . . . . . . . . . . . . . . . . 20
	4.9.1. Freshness . . . . . . . . . . . . . . . . . . . . . . 20		4.9.1. Freshness . . . . . . . . . . . . . . . . . . . . . . 20
	4.9.2. Stale Responses . . . . . . . . . . . . . . . . . . . 21		4.9.2. Stale Responses . . . . . . . . . . . . . . . . . . . 21
	4.9.3. Caching and Application Semantics . . . . . . . . . . 21		4.9.3. Caching and Application Semantics . . . . . . . . . . 21
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	application. This effectively overlays special, application-specific		application. This effectively overlays special, application-specific
	semantics onto that space, precludes other applications from using		semantics onto that space, precludes other applications from using
	it.		it.
	As explained in [RFC8820], such "squatting" on a part of the URL		As explained in [RFC8820], such "squatting" on a part of the URL
	space by a standard usurps the server's authority over its own		space by a standard usurps the server's authority over its own
	resources, can cause deployment issues, and is therefore bad practice		resources, can cause deployment issues, and is therefore bad practice
	in standards.		in standards.
	Instead of statically defining URI components like paths, it is		Instead of statically defining URI components like paths, it is
	RECOMMENDED that applications using HTTP define and use links, to		RECOMMENDED that applications using HTTP define and use links
	allow flexibility in deployment.		[RFC8288] to allow flexibility in deployment.
	Using runtime links in this fashion has a number of other benefits --		Using runtime links in this fashion has a number of other benefits --
	especially when an application is to have multiple implementations		especially when an application is to have multiple implementations
	and/or deployments (as is often the case for those that are		and/or deployments (as is often the case for those that are
	standardised).		standardised).
	For example, navigating with a link allows a request to be routed to		For example, navigating with a link allows a request to be routed to
	a different server without the overhead of a redirection, thereby		a different server without the overhead of a redirection, thereby
	supporting deployment across machines well.		supporting deployment across machines well.
	skipping to change at page 7, line 46 ¶		skipping to change at page 7, line 46 ¶
	Using links also offers a form of cache invalidation that's seen on		Using links also offers a form of cache invalidation that's seen on
	the Web; when a resource's state changes, the application can change		the Web; when a resource's state changes, the application can change
	its link to it so that a fresh copy is always fetched.		its link to it so that a fresh copy is always fetched.
	3.3. Rich Functionality		3.3. Rich Functionality
	HTTP offers a number of features to applications, such as:		HTTP offers a number of features to applications, such as:
	* Message framing		* Message framing
	* Multiplexing (in HTTP/2)		* Multiplexing (in HTTP/2 [I-D.ietf-httpbis-http2bis] and HTTP/3
			[I-D.ietf-quic-http])
	* Integration with TLS		* Integration with TLS
	* Support for intermediaries (proxies, gateways, Content Delivery		* Support for intermediaries (proxies, gateways, Content Delivery
	Networks)		Networks)
	* Client authentication		* Client authentication
	* Content negotiation for format, language, and other features		* Content negotiation for format, language, and other features
	skipping to change at page 9, line 10 ¶		skipping to change at page 9, line 10 ¶
	However, if an application's deployment would benefit from the use of		However, if an application's deployment would benefit from the use of
	a particular version of HTTP (for example, HTTP/2's multiplexing),		a particular version of HTTP (for example, HTTP/2's multiplexing),
	this ought be noted.		this ought be noted.
	Applications using HTTP MUST NOT specify a maximum version, to		Applications using HTTP MUST NOT specify a maximum version, to
	preserve the protocol's ability to evolve.		preserve the protocol's ability to evolve.
	When specifying examples of protocol interactions, applications		When specifying examples of protocol interactions, applications
	should document both the request and response messages, with complete		should document both the request and response messages, with complete
	header sections, preferably in HTTP/1.1 format. For example:		header sections, preferably in HTTP/1.1 format
			[I-D.ietf-httpbis-messaging]. For example:
	GET /thing HTTP/1.1		GET /thing HTTP/1.1
	Host: example.com		Host: example.com
	Accept: application/things+json		Accept: application/things+json
	User-Agent: Foo/1.0		User-Agent: Foo/1.0
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Type: application/things+json		Content-Type: application/things+json
	Content-Length: 500		Content-Length: 500
	Server: Bar/2.2		Server: Bar/2.2
	skipping to change at page 17, line 15 ¶		skipping to change at page 17, line 15 ¶
	code; e.g., "499" can be safely handled as "400" by clients that		code; e.g., "499" can be safely handled as "400" by clients that
	don't recognise it). This is preferable to creating a "laundry list"		don't recognise it). This is preferable to creating a "laundry list"
	of potential status codes, since such a list won't be complete in the		of potential status codes, since such a list won't be complete in the
	foreseeable future.		foreseeable future.
	Applications using HTTP MUST NOT re-specify the semantics of HTTP		Applications using HTTP MUST NOT re-specify the semantics of HTTP
	status codes, even if it is only by copying their definition. It is		status codes, even if it is only by copying their definition. It is
	NOT RECOMMENDED they require specific reason phrases to be used; the		NOT RECOMMENDED they require specific reason phrases to be used; the
	reason phrase has no function in HTTP, is not guaranteed to be		reason phrase has no function in HTTP, is not guaranteed to be
	preserved by implementations, and is not carried at all in the HTTP/2		preserved by implementations, and is not carried at all in the HTTP/2
	[RFC7540] message format.		I-D.ietf-httpbis-http2bis message format.
	Applications MUST only use registered HTTP status codes. As with		Applications MUST only use registered HTTP status codes. As with
	methods, new HTTP status codes are rare, and required (by		methods, new HTTP status codes are rare, and required (by
	[I-D.ietf-httpbis-semantics]) to be registered with IETF Review.		[I-D.ietf-httpbis-semantics]) to be registered with IETF Review.
	Similarly, HTTP status codes are generic; they are required (by		Similarly, HTTP status codes are generic; they are required (by
	[I-D.ietf-httpbis-semantics]) to be potentially applicable to all		[I-D.ietf-httpbis-semantics]) to be potentially applicable to all
	resources, not just to those of one application.		resources, not just to those of one application.
	When authors believe that a new status code is required, they are		When authors believe that a new status code is required, they are
	encouraged to engage with the HTTP community early, and document		encouraged to engage with the HTTP community early, and document
	skipping to change at page 23, line 9 ¶		skipping to change at page 23, line 9 ¶
	When used, it is important to carefully specify the scoping and use		When used, it is important to carefully specify the scoping and use
	of cookies; if the application exposes sensitive data or capabilities		of cookies; if the application exposes sensitive data or capabilities
	(e.g., by acting as an ambient authority), exploits are possible.		(e.g., by acting as an ambient authority), exploits are possible.
	Mitigations include using a request-specific token to assure the		Mitigations include using a request-specific token to assure the
	intent of the client.		intent of the client.
	4.11. Making Multiple Requests		4.11. Making Multiple Requests
	Clients often need to send multiple requests to perform a task.		Clients often need to send multiple requests to perform a task.
	In HTTP/1, parallel requests are most often supported by opening		In HTTP/1 [I-D.ietf-httpbis-messaging], parallel requests are most
	multiple connections. Application performance can be impacted when		often supported by opening multiple connections. Application
	too many simultaneous connections are used, because connections'		performance can be impacted when too many simultaneous connections
	congestion control will not be coordinated. Furthermore, it can be		are used, because connections' congestion control will not be
	difficult for applications to decide when and to select which		coordinated. Furthermore, it can be difficult for applications to
	connection to use to issue a given request, further impacting		decide when and to select which connection to use to issue a given
	performance.		request, further impacting performance.
	HTTP/2 and HTTP/3 offer multiplexing to applications, removing the		HTTP/2 [I-D.ietf-httpbis-http2bis] and HTTP/3 I-D.ietf-quic-http
	need to use multiple connections. However, application performance		offer multiplexing to applications, removing the need to use multiple
	can still be significantly affected by how the server chooses to		connections. However, application performance can still be
	prioritize responses. Depending on the application, it might be best		significantly affected by how the server chooses to prioritize
	for the server to determine the priority of responses, or for the		responses. Depending on the application, it might be best for the
	client to hint its priorities to the server (see, e.g.,		server to determine the priority of responses, or for the client to
			hint its priorities to the server (see, e.g.,
	[I-D.ietf-httpbis-priority]).		[I-D.ietf-httpbis-priority]).
	In all versions of HTTP, requests are made independently -- you can't		In all versions of HTTP, requests are made independently -- you can't
	rely on the relative order of two requests to guarantee processing		rely on the relative order of two requests to guarantee processing
	order. This is because they might be sent over a multiplexed		order. This is because they might be sent over a multiplexed
	protocol by an intermediary, sent to different origin servers, or the		protocol by an intermediary, sent to different origin servers, or the
	server might even perform processing in a different order. If two		server might even perform processing in a different order. If two
	requests need strict ordering, the only reliable way to assure the		requests need strict ordering, the only reliable way to assure the
	outcome is to issue the second request when the final response to the		outcome is to issue the second request when the final response to the
	first has begun.		first has begun.
	skipping to change at page 23, line 46 ¶		skipping to change at page 23, line 47 ¶
	many of the assumptions of HTTP as a stateless protocol, and will		many of the assumptions of HTTP as a stateless protocol, and will
	cause problems in interoperability, security, operability and		cause problems in interoperability, security, operability and
	evolution.		evolution.
	4.12. Client Authentication		4.12. Client Authentication
	Applications can use HTTP authentication Section 11 of		Applications can use HTTP authentication Section 11 of
	[I-D.ietf-httpbis-semantics] to identify clients. As per [RFC7617],		[I-D.ietf-httpbis-semantics] to identify clients. As per [RFC7617],
	the Basic authentication scheme is not suitable for protecting		the Basic authentication scheme is not suitable for protecting
	sensitive or valuable information unless the channel is secure (e.g.,		sensitive or valuable information unless the channel is secure (e.g.,
	using the "HTTPS" URI scheme). Likewise, [RFC7617] requires the		using the "HTTPS" URI scheme). Likewise, [RFC7616] requires the
	Digest authentication scheme to be used over a secure channel.		Digest authentication scheme to be used over a secure channel.
	With HTTPS, clients might also be authenticated using certificates		With HTTPS, clients might also be authenticated using certificates
	[RFC5246].		[RFC5246].
	When used, it is important to carefully specify the scoping and use		When used, it is important to carefully specify the scoping and use
	of authentication; if the application exposes sensitive data or		of authentication; if the application exposes sensitive data or
	capabilities (e.g., by acting as an ambient authority), exploits are		capabilities (e.g., by acting as an ambient authority), exploits are
	possible. Mitigations include using a request-specific token to		possible. Mitigations include using a request-specific token to
	assure the intent of the client.		assure the intent of the client.
	skipping to change at page 26, line 24 ¶		skipping to change at page 26, line 24 ¶
	using their specified mechanisms for doing so.		using their specified mechanisms for doing so.
	Modern Web browsers constrain the ability of content from one origin		Modern Web browsers constrain the ability of content from one origin
	to access resources from another, to avoid leaking private		to access resources from another, to avoid leaking private
	information. As a result, applications that wish to expose cross-		information. As a result, applications that wish to expose cross-
	origin data to browsers will need to implement the CORS protocol; see		origin data to browsers will need to implement the CORS protocol; see
	[FETCH].		[FETCH].
	4.15. Using Server Push		4.15. Using Server Push
	HTTP/2 adds the ability for servers to "push" request/response pairs		HTTP/2 added the ability for servers to "push" request/response pairs
	to clients in [RFC7540], Section 8.2. While server push seems like a		to clients in [I-D.ietf-httpbis-http2bis], Section 8.4. While server
	natural fit for many common application semantics (e.g., "fanout" and		push seems like a natural fit for many common application semantics
	publish/subscribe), a few caveats should be noted:		(e.g., "fanout" and publish/subscribe), a few caveats should be
			noted:
	* Server push is hop-by-hop; that is, it is not automatically		* Server push is hop-by-hop; that is, it is not automatically
	forwarded by intermediaries. As a result, it might not work		forwarded by intermediaries. As a result, it might not work
	easily (or at all) with proxies, reverse proxies, and Content		easily (or at all) with proxies, reverse proxies, and Content
	Delivery Networks.		Delivery Networks.
	* Server push can have negative performance impact on HTTP when used		* Server push can have negative performance impact on HTTP when used
	incorrectly; in particular, if there is contention with resources		incorrectly; in particular, if there is contention with resources
	that have actually been requested by the client.		that have actually been requested by the client.
	skipping to change at page 27, line 11 ¶		skipping to change at page 27, line 11 ¶
	* Server push does not form part of the "core" semantics of HTTP,		* Server push does not form part of the "core" semantics of HTTP,
	and therefore might not be supported by future versions of the		and therefore might not be supported by future versions of the
	protocol.		protocol.
	Applications wishing to optimise cases where the client can perform		Applications wishing to optimise cases where the client can perform
	work related to requests before the full response is available (e.g.,		work related to requests before the full response is available (e.g.,
	fetching links for things likely to be contained within) might		fetching links for things likely to be contained within) might
	benefit from using the 103 (Early Hints) status code; see [RFC8297].		benefit from using the 103 (Early Hints) status code; see [RFC8297].
	Applications using server push directly need to enforce the		Applications using server push directly need to enforce the
	requirements regarding authority in [RFC7540], Section 8.2, to avoid		requirements regarding authority in [I-D.ietf-httpbis-http2bis],
	cross-origin push attacks.		Section 8.4, to avoid cross-origin push attacks.
	4.16. Allowing Versioning and Evolution		4.16. Allowing Versioning and Evolution
	It's often necessary to introduce new features into application		It's often necessary to introduce new features into application
	protocols, and change existing ones.		protocols, and change existing ones.
	In HTTP, backwards-incompatible changes are possible using a number		In HTTP, backwards-incompatible changes are possible using a number
	of mechanisms:		of mechanisms:
	* Using a distinct link relation type [RFC8288] to identify a URL		* Using a distinct link relation type [RFC8288] to identify a URL
	skipping to change at page 30, line 40 ¶		skipping to change at page 30, line 40 ¶
	[HTML] WHATWG, "HTML - Living Standard", n.d.,		[HTML] WHATWG, "HTML - Living Standard", n.d.,
	<https://html.spec.whatwg.org>.		<https://html.spec.whatwg.org>.
	[I-D.ietf-httpbis-cache]		[I-D.ietf-httpbis-cache]
	Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP		Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP
	Caching", Work in Progress, Internet-Draft, draft-ietf-		Caching", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-cache-17, 25 July 2021,		httpbis-cache-17, 25 July 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	cache-17>.		cache-17>.
			[I-D.ietf-httpbis-http2bis]
			Thomson, M. and C. Benfield, "Hypertext Transfer Protocol
			Version 2 (HTTP/2)", Work in Progress, Internet-Draft,
			draft-ietf-httpbis-http2bis-03, 12 July 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			http2bis-03>.
			[I-D.ietf-httpbis-messaging]
			Fielding, R. T., Nottingham, M., and J. Reschke,
			"HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf-
			httpbis-messaging-17, 25 July 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
			messaging-17>.
	[I-D.ietf-httpbis-priority]		[I-D.ietf-httpbis-priority]
	Oku, K. and L. Pardue, "Extensible Prioritization Scheme		Oku, K. and L. Pardue, "Extensible Prioritization Scheme
	for HTTP", Work in Progress, Internet-Draft, draft-ietf-		for HTTP", Work in Progress, Internet-Draft, draft-ietf-
	httpbis-priority-04, 11 July 2021,		httpbis-priority-04, 11 July 2021,
	<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-		<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
	priority-04>.		priority-04>.
			[I-D.ietf-quic-http]
			Bishop, M., "Hypertext Transfer Protocol Version 3
			(HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
			quic-http-34, 2 February 2021,
			<https://datatracker.ietf.org/doc/html/draft-ietf-quic-
			http-34>.
	[REFERRER-POLICY]		[REFERRER-POLICY]
	Eisinger, J. and E. Stark, "Referrer Policy", World Wide		Eisinger, J. and E. Stark, "Referrer Policy", World Wide
	Web Consortium CR CR-referrer-policy-20170126, 26 January		Web Consortium CR CR-referrer-policy-20170126, 26 January
	2017,		2017,
	<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.		<https://www.w3.org/TR/2017/CR-referrer-policy-20170126>.
	[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,		[RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56,
	RFC 3205, DOI 10.17487/RFC3205, February 2002,		RFC 3205, DOI 10.17487/RFC3205, February 2002,
	<https://www.rfc-editor.org/rfc/rfc3205>.		<https://www.rfc-editor.org/rfc/rfc3205>.
	skipping to change at page 32, line 5 ¶		skipping to change at page 32, line 23 ¶
	[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict		[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
	Transport Security (HSTS)", RFC 6797,		Transport Security (HSTS)", RFC 6797,
	DOI 10.17487/RFC6797, November 2012,		DOI 10.17487/RFC6797, November 2012,
	<https://www.rfc-editor.org/rfc/rfc6797>.		<https://www.rfc-editor.org/rfc/rfc6797>.
	[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	2014, <https://www.rfc-editor.org/rfc/rfc7258>.		2014, <https://www.rfc-editor.org/rfc/rfc7258>.
	[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
	Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
	DOI 10.17487/RFC7540, May 2015,
	<https://www.rfc-editor.org/rfc/rfc7540>.
	[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines		[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
	and Registration Procedures for URI Schemes", BCP 35,		and Registration Procedures for URI Schemes", BCP 35,
	RFC 7595, DOI 10.17487/RFC7595, June 2015,		RFC 7595, DOI 10.17487/RFC7595, June 2015,
	<https://www.rfc-editor.org/rfc/rfc7595>.		<https://www.rfc-editor.org/rfc/rfc7595>.
	[RFC7605] Touch, J., "Recommendations on Using Assigned Transport		[RFC7605] Touch, J., "Recommendations on Using Assigned Transport
	Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,		Port Numbers", BCP 165, RFC 7605, DOI 10.17487/RFC7605,
	August 2015, <https://www.rfc-editor.org/rfc/rfc7605>.		August 2015, <https://www.rfc-editor.org/rfc/rfc7605>.
			[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
			Digest Access Authentication", RFC 7616,
			DOI 10.17487/RFC7616, September 2015,
			<https://www.rfc-editor.org/rfc/rfc7616>.
	[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",		[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
	RFC 7617, DOI 10.17487/RFC7617, September 2015,		RFC 7617, DOI 10.17487/RFC7617, September 2015,
	<https://www.rfc-editor.org/rfc/rfc7617>.		<https://www.rfc-editor.org/rfc/rfc7617>.
	[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP		[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
	APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,		APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
	<https://www.rfc-editor.org/rfc/rfc7807>.		<https://www.rfc-editor.org/rfc/rfc7807>.
	[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", STD 90, RFC 8259,		Interchange Format", STD 90, RFC 8259,
End of changes. 18 change blocks.
	35 lines changed or deleted		60 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/