Jul 9, 2020 · Jun 11, 2020 · Jun 11, 2020 · Jun 11, 2020 · Jun 11, 2020 · Jun 22, 2020
diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml
   <xref target="idempotent.methods"/>.
 </t>
 </section>
 </section>

 <section title="Extending and Versioning HTTP" anchor="extending.versioning">

 <t>
   While HTTP's core semantics don't change between protocol versions, the
   expression of them "on the wire" can change, and so the
   HTTP version number changes when incompatible changes are made to the wire
   format. Additionally, HTTP allows incremental, backwards-compatible
   changes to be made to the protocol without changing its version through
   the use of defined extension points.
 </t>

 <section title="Extending HTTP" anchor="extending">
 <t>
   HTTP defines a number of generic extension points that can be used to
   introduce capabilities to the protocol without introducing a new version,
   including methods (<xref target="method.extensibility"/>), status codes
   (<xref target="status.code.extensibility"/>), header and trailer fields
   (<xref target="considerations.for.new.header.fields"/>), and further
   extensibility points within defined fields (such as Cache-Control in <xref
   target="cache.control.extensions"/>). Because the semantics of HTTP are
   not versioned, these extension points are constant; the version of the
   protocol in use does not affect their semantics.
 </t>
 <t>
   Version-independent extensions are discouraged from depending on or
   interacting with the specific version of the protocol in use. When this is
   unavoidable, careful consideration needs to be given to how the extension
   can interoperate across versions.
 </t>
 <t>
   Additionally, specific versions of HTTP might have their own extensibility
   points, such as transfer-codings in HTTP/1.1 (<xref
   target="field.transfer-encoding"/>) and HTTP/2 (<xref target="RFC7540"/>)
   SETTINGS or frame types. These extension points are specific to the
   version of the protocol they occur within.
 </t>
 <t>
   Version-specific extensions are cannot override or modify the semantics of
   a version-independent mechanism or extension point (like a method or
   header) without explicitly being allowed by that protocol element. For
   example, the CONNECT method (<xref target="CONNECT"/>) allows this.
 </t>
 <t>
   These guidelines assure that the protocol operates correctly and
   predictably, even when parts of the path implement different versions of
   HTTP.
 </t>
 </section>

 <section title="Protocol Versioning" anchor="protocol.version">
 <t>
   through one or more proxies, which can then be secured using TLS
   (Transport Layer Security, <xref target="RFC8446"/>).
 </t>
 <t>
   Because CONNECT changes the request/response nature of a HTTP connection,
   specific HTTP versions might have different ways of mapping its semantics
   into the protocol's wire format.
 </t>
 <t>
   CONNECT is intended only for use in requests to a proxy.
   An origin server that receives a CONNECT request for itself &MAY;
  <x:source href="draft-ietf-httpbis-cache-latest.xml" basename="draft-ietf-httpbis-cache-latest">
    <x:has anchor="constructing.responses.from.caches"/>
    <x:has anchor="cache-response-directive.private"/>
    <x:has anchor="cache.control.extensions"/>
    <x:has anchor="caching.authenticated.responses"/>
    <x:has anchor="caching.negotiated.responses"/>
    <x:has anchor="caching.overview"/>
  <seriesInfo name='RFC' value='4918' />
 </reference>

 <reference anchor="RFC7540">
   <front>
      <title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
      <author initials="M." surname="Belshe" fullname="M. Belshe">
         <organization/>
      </author>
      <author initials="R." surname="Peon" fullname="R. Peon">
         <organization/>
      </author>
      <author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
         <organization/>
      </author>
      <date year="2015" month="May"/>
   </front>
   <seriesInfo name="RFC" value="7540"/>
 </reference>

 <reference anchor="RFC8446">
   <front>
      <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
Original file line number	Diff line number	Diff line change
Expand Up		@@ -1067,6 +1067,56 @@ Content-Type: text/plain
		<xref target="idempotent.methods"/>.
		</t>
		</section>
		</section>

		<section title="Extending and Versioning HTTP" anchor="extending.versioning">

		<t>
		While HTTP's core semantics don't change between protocol versions, the
		expression of them "on the wire" can change, and so the
		HTTP version number changes when incompatible changes are made to the wire
		format. Additionally, HTTP allows incremental, backwards-compatible
		changes to be made to the protocol without changing its version through
		the use of defined extension points.
		</t>

		<section title="Extending HTTP" anchor="extending">
		<t>
		HTTP defines a number of generic extension points that can be used to
		introduce capabilities to the protocol without introducing a new version,
		including methods (<xref target="method.extensibility"/>), status codes
		(<xref target="status.code.extensibility"/>), header and trailer fields
		(<xref target="considerations.for.new.header.fields"/>), and further
		extensibility points within defined fields (such as Cache-Control in <xref
		target="cache.control.extensions"/>). Because the semantics of HTTP are
		not versioned, these extension points are constant; the version of the
mnot marked this conversation as resolved. OutdatedShow resolvedHide resolved
		protocol in use does not affect their semantics.
		</t>
		<t>
		Version-independent extensions are discouraged from depending on or
		interacting with the specific version of the protocol in use. When this is
		unavoidable, careful consideration needs to be given to how the extension
		can interoperate across versions.
		</t>
		<t>
		Additionally, specific versions of HTTP might have their own extensibility
		points, such as transfer-codings in HTTP/1.1 (<xref
		target="field.transfer-encoding"/>) and HTTP/2 (<xref target="RFC7540"/>)
		SETTINGS or frame types. These extension points are specific to the
		version of the protocol they occur within.
		</t>
		<t>
		Version-specific extensions are cannot override or modify the semantics of
mnot marked this conversation as resolved. OutdatedShow resolvedHide resolved
		a version-independent mechanism or extension point (like a method or
		header) without explicitly being allowed by that protocol element. For
reschke marked this conversation as resolved. OutdatedShow resolvedHide resolved
		example, the CONNECT method (<xref target="CONNECT"/>) allows this.
		</t>
		<t>
		These guidelines assure that the protocol operates correctly and
		predictably, even when parts of the path implement different versions of
		HTTP.
		</t>
		</section>

		<section title="Protocol Versioning" anchor="protocol.version">
		<t>
Expand DownExpand Up		@@ -5032,6 +5082,11 @@ Content-Range: exampleunit 11.2-14.3/25
		through one or more proxies, which can then be secured using TLS
		(Transport Layer Security, <xref target="RFC8446"/>).
		</t>
		<t>
		Because CONNECT changes the request/response nature of a HTTP connection,
mnot marked this conversation as resolved. OutdatedShow resolvedHide resolved
		specific HTTP versions might have different ways of mapping its semantics
		into the protocol's wire format.
		</t>
		<t>
		CONNECT is intended only for use in requests to a proxy.
		An origin server that receives a CONNECT request for itself &MAY;
Expand DownExpand Up		@@ -10969,6 +11024,7 @@ Content-Encoding: gzip
		<x:source href="draft-ietf-httpbis-cache-latest.xml" basename="draft-ietf-httpbis-cache-latest">
		<x:has anchor="constructing.responses.from.caches"/>
		<x:has anchor="cache-response-directive.private"/>
		<x:has anchor="cache.control.extensions"/>
		<x:has anchor="caching.authenticated.responses"/>
		<x:has anchor="caching.negotiated.responses"/>
		<x:has anchor="caching.overview"/>
Expand DownExpand Up		@@ -11658,6 +11714,23 @@ Content-Encoding: gzip
		<seriesInfo name='RFC' value='4918' />
		</reference>

		<reference anchor="RFC7540">
		<front>
		<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
		<author initials="M." surname="Belshe" fullname="M. Belshe">
		<organization/>
		</author>
		<author initials="R." surname="Peon" fullname="R. Peon">
		<organization/>
		</author>
		<author initials="M." surname="Thomson" fullname="M. Thomson" role="editor">
		<organization/>
		</author>
		<date year="2015" month="May"/>
		</front>
		<seriesInfo name="RFC" value="7540"/>
		</reference>

		<reference anchor="RFC8446">
		<front>
		<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
Expand Down