diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml
index 8fef60c11..39bf7d104 100644
--- a/draft-ietf-httpbis-semantics-latest.xml
+++ b/draft-ietf-httpbis-semantics-latest.xml
@@ -9728,9 +9728,32 @@ Content-Type: text/plain
 </section>
 </section>
 
-<section title="Field Name Extensibility" anchor="field-extensibility">
+<section title="Field Extensibility" anchor="field-extensibility">
   <x:anchor-alias value="header.extensibility"/>
 
+<t>
+  HTTP's most widely used extensibility point is the definition of new header and
+  trailer fields.
+</t>
+<t>
+  New fields can be defined such that, when they are understood by a
+  recipient, they override or enhance the interpretation of previously
+  defined fields, define preconditions on request evaluation, or
+  refine the meaning of responses.
+</t>
+<t>
+   However, defining a field doesn't guarantee its deployment or recognition
+   by recipients. Most fields are designed with the expectation that a recipient
+   can safely ignore (but forward downstream) any field not recognized.
+   In other cases, the sender's ability to understand a given field might be
+   indicated by its prior communication, perhaps in the protocol version
+   or fields that it sent in prior messages, or its use of a specific media type.
+   Likewise, direct inspection of support might be possible through an
+   OPTIONS request or by interacting with a defined well-known URI
+   <xref target="RFC8615"/> if such inspection is defined along with
+   the field being introduced.
+</t>
+
 <section title="Field Name Registry" anchor="field-name.registry">
   <x:anchor-alias value="header.name.registry"/>
 <t>
@@ -9809,16 +9832,6 @@ Content-Type: text/plain
 </section>
 
 <section title="Considerations for New Field Names" anchor="considerations.for.new.field.names">
-<t>
-   There is no limit on the introduction of new field names, each presumably
-   defining new semantics.
-</t>
-<t>
-   New fields can be defined such that, when they are understood by a
-   recipient, they might override or enhance the interpretation of previously
-   defined fields, define preconditions on request evaluation, or
-   refine the meaning of responses.
-</t>
 <t>
    Authors of specifications defining new fields are advised to choose a short
    but descriptive field name. Short names avoid needless data transmission;
@@ -12540,6 +12553,15 @@ Content-Type: text/plain
   <seriesInfo name="RFC" value="8336"/>
 </reference>
 
+<reference anchor="RFC8615">
+   <front>
+      <title>Well-Known Uniform Resource Identifiers (URIs)</title>
+      <author initials="M." surname="Nottingham" fullname="M. Nottingham"/>
+      <date year="2019" month="May"/>
+   </front>
+   <seriesInfo name="RFC" value="8615"/>
+</reference>
+
 <reference anchor="HTTP3">
   <front>
     <title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>
@@ -13439,6 +13461,7 @@ transfer-coding = &lt;transfer-coding, see <xref target="Messaging" x:fmt="," x:
 
 <section title="Since draft-ietf-httpbis-semantics-12" anchor="changes.since.12">
 <ul x:when-empty="None yet.">
+  <li>In <xref target="field-extensibility"/>, explain why new fields need to be backwards-compatible (<eref target="https://github.com/httpwg/http-core/issues/448"/>)</li>
   <li>In <xref target="field-order"/>, constrain field combination to be within a section (<eref target="https://github.com/httpwg/http-core/issues/454"/>)</li>
   <li>In <xref target="http.date"/>, mention that caching relaxes date sensitivity (<eref target="https://github.com/httpwg/http-core/issues/473"/>)</li>
   <li>In <xref target="field.name.registration"/>, moved "*" field registration into main table (<eref target="https://github.com/httpwg/http-core/issues/476"/>)</li>