rfc9720xml2.original.xml   rfc9720.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.
3.4) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="trust200902" docName="draft-rswg-rfc7990-updates-12" category="info" s <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
ubmissionType="editorial" obsoletes="7990" updates="9280" tocInclude="true" sort -rswg-rfc7990-updates-12" number="9720" category="info" submissionType="editoria
Refs="true" symRefs="true"> l" obsoletes="7990" updates="9280" tocInclude="true" sortRefs="true" symRefs="tr
ue" version="3" xml:lang="en">
<front> <front>
<title abbrev="RFC Formats and Versions">RFC Formats and Versions</title> <title abbrev="RFC Formats and Versions">RFC Formats and Versions</title>
<seriesInfo name="RFC" value="9720"/>
<author initials="P." surname="Hoffman" fullname="Paul Hoffman"> <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
<organization>ICANN</organization> <organization>ICANN</organization>
<address> <address>
<email>paul.hoffman@icann.org</email> <email>paul.hoffman@icann.org</email>
</address> </address>
</author> </author>
<author initials="H." surname="Flanagan" fullname="Heather Flanagan"> <author initials="H." surname="Flanagan" fullname="Heather Flanagan">
<organization>Spherical Cow Consulting</organization> <organization>Spherical Cow Consulting</organization>
<address> <address>
<email>hlf@sphericalcowconsulting.com</email> <email>hlf@sphericalcowconsulting.com</email>
</address> </address>
</author> </author>
<date year="2025" month="January"/>
<date year="2024" month="August" day="06"/>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<?line 40?>
<t>In order to improve the readability of RFCs while supporting their archivabil ity, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document. <t>In order to improve the readability of RFCs while supporting their archivabil ity, the definitive version of the RFC Series transitioned from plain-text ASCII to XML using the RFCXML vocabulary; different publication versions are rendered from that base document.
This document describes how RFCs are published.</t> This document describes how RFCs are published.</t>
<t>This document obsoletes RFC 7990.
<t>This document obsoletes RFC 7990.
This document also updates the stability policy in RFC 9280.</t> This document also updates the stability policy in RFC 9280.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 49?> <section anchor="introduction">
<name>Introduction</name>
<section anchor="introduction"><name>Introduction</name>
<t>"RFC Series Format Requirements and Future Development" <xref target="RFC6949 <t>"RFC Series Format Requirements and Future Development" <xref target="R
"/> discussed the need to improve the display of items such as author names and FC6949"/> discussed the need to improve the display of items such as author name
artwork in RFCs as well as the need to improve the ability of RFCs to be display s and artwork in RFCs as well as the need to improve the ability of RFCs to be d
ed properly on various devices. isplayed properly on various devices.
Based on the discussions with communities of interest, such as the IETF, the RFC Based on discussions with communities of interest, such as the IETF, the RFC Ser
Series Editor decided to explore a change to the format of the Series. ies Editor decided to explore a change to the format of the Series.
<xref target="RFC7990"/> was the culmination of that exploration.</t> <xref target="RFC7990"/> was the culmination of that exploration.</t>
<t>This document is concerned with the production of RFCs, focusing on the
<t>This document is concerned with the production of RFCs, focusing on the publi published documents.
shed documents. It does not address any changes to the processes each stream uses to develop and
It does not address any changes to the processes each stream uses to develop and review their submissions (specifically, how Internet-Drafts are developed).
review their submissions (specifically, how Internet-Drafts will be developed).
While I-Ds have a similar set of issues and concerns, directly addressing those issues for I-Ds should be discussed within each document stream.</t> While I-Ds have a similar set of issues and concerns, directly addressing those issues for I-Ds should be discussed within each document stream.</t>
<t>The details described in this document are expected to continue to chan
<t>The details described in this document are expected to continue to change ove ge over time as the community and the RFC Production Center (RPC) gain further e
r time as the community and the RFC Production Center (RPC) gains further experi xperience implementing the policies described here.</t>
ence implementing the policies described here.</t> <t>Implementors of these components are advised to avoid assuming that all
such changes will be backwards compatible.</t>
<t>Implementors of those components are advised to avoid assuming that all such <section anchor="changes-to-rfc-7990">
changes will be backwards-compatible.</t> <name>Changes to RFC 7990</name>
<t><xref target="RFC7990"/> defined a framework for how RFCs would be pub
<section anchor="changes-to-rfc-7990"><name>Changes to RFC 7990</name> lished,
including new "publication formats" and a new "canonical format".
<t><xref target="RFC7990"/> defined a framework for how RFCs would be published
after that document was published, including new formats and a new "canonical fo
rmat" for archiving RFCs.
It talked about "the XML file" as if there would only be one XML file for an RFC because that was the expectation at the time <xref target="RFC7990"/> was publi shed. It talked about "the XML file" as if there would only be one XML file for an RFC because that was the expectation at the time <xref target="RFC7990"/> was publi shed.
It also talked about "publication formats" as the versions of HTML, text, and PD It also talked about "publication formats" as the versions of HTML, plain text,
F derived from the "canonical format".</t> and PDF derived from the "canonical format".</t>
<t>After extensive experience with publishing RFCs in the RFCXML format
<t>After extensive experience with publishing RFCs in the RFCXML format <xref ta <xref target="RFC7991"/>, it has been decided that an RFC's XML file can be upda
rget="RFC7991"/>, it has been decided that an RFC's XML file can be updated for ted for narrowly limited purposes.
narrowly limited purposes.
This document changes <xref target="RFC7990"/> in significant ways:</t> This document changes <xref target="RFC7990"/> in significant ways:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>It defines four terms that replace the use of the term "canonical" and clar <li>
ifies "format": <t>It defines four terms that replace the use of the term "canonical
<list style="symbols"> " and clarifies "format":
<t>The "definitive format", which is RFCXML</t> </t>
<t>The "definitive version", which is a published RFC in the definitive fo <ul spacing="normal">
rmat</t> <li>
<t>A "publication format", which is currently one of PDF, plain text, or H <t>The "definitive format", which is RFCXML</t>
TML</t> </li>
<t>A "publication version", which is a published RFC in one of the publica <li>
tion formats</t> <t>The "definitive version", which is a published RFC in the def
</list></t> initive format</t>
<t>It defines a policy governing how the RFCXML format changes.</t> </li>
<t>It defines a policy for when the definitive version of an RFC can be update <li>
d and older definitive versions archived.</t> <t>A "publication format", which is currently one of HTML, plain
<t>It defines a policy for when the publication versions of an RFC can be upda text, and PDF</t>
ted and older publication versions archived.</t> </li>
</list></t> <li>
<t>A "publication version", which is a published RFC in one of t
<t>When using the new terminology, it is important to note that <xref target="RF he publication formats</t>
C7990"/> used the term "canonical format" to mean two very different things. Quo </li>
ting from RFC 7990:</t> </ul>
</li>
<ul empty="true"><li> <li>
<t>Canonical format: the authorized, recognized, accepted, and archived versio <t>It defines a policy governing how the RFCXML format changes.</t>
n of the document</t> </li>
</li></ul> <li>
<t>It defines a policy for when the definitive version of an RFC can
<t>and</t> be updated and older definitive versions archived.</t>
</li>
<ul empty="true"><li> <li>
<t>At the highest level, the changes being made to the RFC format involve brea <t>It defines a policy for when the publication versions of an RFC c
king away from solely ASCII plain text and moving to a canonical format that inc an be updated and older publication versions archived.</t>
ludes all the information required for rendering a document into a wide variety </li>
of publication formats.</t> </ul>
</li></ul> <t>When using the new terminology, it is important to note that <xref ta
rget="RFC7990"/> used the term "canonical format" to mean two very different thi
<t>This document uses two terms, "definitive version" and "definitive format", f ngs. Quoting from RFC 7990:</t>
or the earlier term "canonical format".</t>
<t>Other terminology changes made by this document are the following:
- It changes the phrase "xml2rfc version 3" to "RFCXML".
- It changes the name of the body that publishes RFCs from "RFC Editor" to "RFC
Production Center" (RPC).</t>
<t>Historical text from <xref target="RFC7990"/> such as Section 2 ("Problem Sta
tement"), Section 4 ("Overview of the Decision-Making Process"), and Section 10
("Transition Plan") were purposely omitted from this document.
Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particu
larly Section 8 (Figures and Artwork) and Section 9 (Content and Page Layout) we
re also removed.</t>
</section>
<section anchor="changes-to-9280"><name>Changes to RFC 9280</name>
<t>Section 7.6 of <xref target="RFC9280"/> currently says:</t>
<ul empty="true"><li>
<t>Once published, RFC Series documents are not changed.</t>
</li></ul>
<t>This document replaces that sentence with:</t>
<ul empty="true"><li>
<t>Once published, RFCs may be re-issued, but the semantic content of publicat
ion versions shall be preserved to the greatest extent possible.</t>
</li></ul>
<t>This document also creates a new policy that would exist in Section 7 of <xre
f target="RFC9280"/>:</t>
<ul empty="true"><li> <blockquote>
<t>7.8. Consistency</t> <t>Canonical format: the authorized, recognized, accepted, and archi
ved version of the document</t>
</blockquote>
<t>and</t>
<blockquote>
<t>At the highest level, the changes being made to the RFC format in
volve breaking away from solely ASCII plain text and moving to a canonical forma
t that includes all the information required for rendering a document into a wid
e variety of publication formats.</t>
</blockquote>
<t>This document uses two terms, "definitive version" and "definitive fo
rmat", for the earlier term "canonical format".</t>
<t>This document also makes the following terminology changes:</t>
<t>RFCs are copyedited, formatted, published, and may be reissued to maintain <ul spacing="normal">
a consistent presentation.</t> <li>It changes the phrase "xml2rfc version 3" to "RFCXML".</li>
</li></ul> <li>It changes the name of the body that publishes RFCs from "RFC Editor"
to "RFC Production Center" (RPC).</li>
</ul>
<t>Historical text from <xref target="RFC7990"/>, such as Section <xref
target="RFC7990" section="2" sectionFormat="bare"/> ("Problem Statement"), Secti
on <xref target="RFC7990" section="4" sectionFormat="bare"/> ("Overview of the D
ecision-Making Process"), and Section <xref target="RFC7990" section="10" sectio
nFormat="bare"/> ("Transition Plan"), was purposely omitted from this document.
Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particu
larly Section <xref target="RFC7990" section="8" sectionFormat="bare"/> ("Figure
s and Artwork") and Section <xref target="RFC7990" section="9" sectionFormat="ba
re"/> ("Content and Page Layout"), was also removed.</t>
</section>
<section anchor="changes-to-9280">
<name>Changes to RFC 9280</name>
<t><xref target="RFC9280" sectionFormat="of" section="7.6" /> says:</t>
<blockquote>
<t>Once published, RFC Series documents are not changed.</t>
</blockquote>
<t>This document replaces that sentence with:</t>
<blockquote>
<t>Once published, RFCs may be reissued, but the semantic content of
publication versions shall be preserved to the greatest extent possible.</t>
</blockquote>
<t>This document also adds a new policy to <xref target="RFC9280" sectio
nFormat="of" section="7"/>:</t>
<t><xref target="updating"/> and <xref target="pub-versions"/> in this document <blockquote>
are based on this updated policy in <xref target="RFC9280"/>.</t> <t>7.8. Consistency</t>
<t indent="3">RFCs are copyedited, formatted, and then published. Th
ey may be
reissued to maintain a consistent presentation.</t>
</blockquote>
</section> <t>Sections <xref target="updating" format="counter"/> and <xref target="pub-ver
<section anchor="key-changes-from-the-earlier-rfc-process"><name>Key Changes fro sions" format="counter"/> in this document are based on this policy in <xref tar
m the Earlier RFC Process</name> get="RFC9280"/>.</t>
</section>
<section anchor="key-changes-from-the-earlier-rfc-process">
<name>Key Changes from the Earlier RFC Process</name>
<t>The first RFC to be published following the guidance of the group of RFCs des cribed in <xref target="RFC7990"/> was <xref target="RFC8651"/>, published in Oc tober 2019. <t>The first RFC to be published following the guidance of the group of R FCs described in <xref target="RFC7990"/> was <xref target="RFC8651"/>, publishe d in October 2019.
In the time since then, all published RFCs have followed the general plan from < xref target="RFC7990"/>.</t> In the time since then, all published RFCs have followed the general plan from < xref target="RFC7990"/>.</t>
<t>At the highest level, the changes that <xref target="RFC7990"/> made
<t>At the highest level, the changes that <xref target="RFC7990"/> made to the R to the RFC format involved breaking away from solely ASCII <xref target="RFC0020
FC format involved breaking away from solely ASCII <xref target="RFC20"/> plain "/> plain text and moving to a definitive format that includes all the informati
text and moving to a definitive format that includes all the information require on required for rendering a document into a wide variety of publication formats.
d for rendering a document into a wide variety of publication formats.
The RPC became responsible for more than just the plain-text file and a PDF rend ering that was created from the plain text at the time of publication; the RPC n ow creates the definitive version and three publication versions of the RFC in o rder to meet the diverse requirements of the community.</t> The RPC became responsible for more than just the plain-text file and a PDF rend ering that was created from the plain text at the time of publication; the RPC n ow creates the definitive version and three publication versions of the RFC in o rder to meet the diverse requirements of the community.</t>
<t>The final RFCXML file produced by the RPC is the definitive version for RFCs; it holds all the information intended for an RFC. <t>The final RFCXML file produced by the RPC is the definitive version for RFCs; it holds all the information intended for an RFC.
Additional publication versions (HTML, PDF, and plain text) are also published b Additional publication versions (HTML, plain text, and PDF) are also published b
y the RPC. y the RPC.
The publication formats are described in <xref target="pub-versions"/> and fully The publication formats are fully specified in other RFCs.</t>
specified in other RFCs.</t> </section>
</section>
</section> <section anchor="definitive-version-of-an-rfc">
</section> <name>Definitive Version of an RFC</name>
<section anchor="definitive-version-of-an-rfc"><name>Definitive Version of an RF
C</name>
<t>The definitive version produced by the RPC is the publication version that ho <t>The definitive version produced by the RPC holds all the information
lds all the information intended for an RFC. intended for an RFC. The RPC may change the definitive version of an
The RPC may change the definitive version of an RFC over time (that is, change t RFC over time (that is, change the XML file), as described in <xref
he XML file), as described in <xref target="updating"/>. target="updating"/>. See <xref target="RFC7991"/> for the original
See <xref target="RFC7991"/> for the original complete description of RFCXML.</t complete description of RFCXML.</t>
>
<t>The XML may contain SVG line art, as originally described in <xref target="RF C7996"/>. <t>The XML may contain SVG line art, as originally described in <xref target="RF C7996"/>.
That SVG will also appear in the HTML publication versions. That SVG will also appear in the HTML publication version.
The XML may contain non-ASCII characters, as originally described in <xref targe t="RFC7997"/>. The XML may contain non-ASCII characters, as originally described in <xref targe t="RFC7997"/>.
These characters will appear in all the publication versions.</t> These characters will appear in all the publication versions.</t>
<t>The definitive version must contain all information necessary to render
<t>The definitive version must contain all information necessary to render the s the specified publication versions; any question about what was intended in the
pecified publication versions; any question about what was intended in the publi publication will be answered from this file.
cation will be answered from this file.
It is self-contained with all the semantic content known at publication time. It is self-contained with all the semantic content known at publication time.
For instance, all features that reference externally defined input are expanded. For instance, all features that reference externally defined input are expanded.
It does not contain src attributes for &lt;artwork&gt; or &lt;sourcecode&gt; ele ments. It does not contain src attributes for &lt;artwork&gt; or &lt;sourcecode&gt; ele ments.
It does not contain comments or processing instructions.</t> It does not contain comments or processing instructions.</t>
<section anchor="updating">
<section anchor="updating"><name>Updating the Definitive Version of an RFC</name <name>Updating the Definitive Version of an RFC</name>
> <t>RFCs may be reissued, as described in <xref target="changes-to-9280"/
>.
<t>RFCs may be re-issued, as described in <xref target="changes-to-9280"/>.
Such changes must preserve the semantics expressed in the original RFC. Such changes must preserve the semantics expressed in the original RFC.
Reasons to make such changes include updates to the RFCXML schema, errors discov ered in the XML, and changes to the tooling used to generate the publication ver sions of the definitive version of the RFC. Reasons to make such changes include updates to the RFCXML schema, errors discov ered in the XML, and changes to the tooling used to generate the publication ver sions of the definitive version of the RFC.
The RPC will keep a public record of when it re-issues any RFC, and give a short The RPC will keep a public record of when it reissues any RFC and give a short d
description of its reasoning for each change.</t> escription of its reasoning for each change.</t>
</section>
</section> <section anchor="expected-updates-to-rfcxml">
<section anchor="expected-updates-to-rfcxml"><name>Expected Updates to RFCXML</n <name>Expected Updates to RFCXML</name>
ame> <t>It is anticipated that <xref target="RFC7991"/> will be updated.
Updates to the RFCXML specification that are applied to existing RFCs should pre
<t>It is anticipated that <xref target="RFC7991"/> will be updated. serve the semantics expressed in the original RFC to the greatest extent possibl
Updates to the RFCXML specification that are applied to existing RFCs should pre e.
serve to the greatest extent possible the semantics expressed in the original RF
C.
The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the published document.</t> The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the published document.</t>
<t>This policy does not require that updates to RFCXML avoid all risk of introdu <t>This policy does not require that updates to RFCXML avoid all risk
cing semantic changes to existing RFCs. of introducing semantic changes to existing RFCs. Instead,
Instead, it only requires that such updates consider the potential for semantic considering the potential for semantic changes, taking steps to
changes, take steps to understand the risk of a semantic change (either delibera understand the risk of a semantic change (either deliberate or
te or inadvertent), and to limit those risks.</t> inadvertent), and limiting associated risks are the only
requirements.
</section> </t>
</section> </section>
<section anchor="pub-versions"><name>Publication Versions</name> </section>
<section anchor="pub-versions">
<t>The RPC is permitted but not required to re-issue publication versions of an <name>Publication Versions</name>
RFC, as described in <xref target="changes-to-9280"/>. <t>The RPC is permitted but not required to reissue publication versions o
In deciding whether to update the publication versions of an RFC, the RPC will t f an RFC, as described in <xref target="changes-to-9280"/>.
ake into account both the risk of semantic changes and consistency of the series In deciding whether to update the publication versions of an RFC, the RPC will t
.</t> ake into account both the risk of semantic changes and consistency of the Series
.</t>
<t>XML format errors and better design choices have been discovered by the commu <t>XML format errors and better design choices have been discovered by the
nity since the first RFCs were published using the RFCXML format. community since the first RFCs were published using the RFCXML format.
When the XML in a definitive version changes, the publication versions may chang e, even if this might not result in observable differences. When the XML in a definitive version changes, the publication versions may chang e, even if this might not result in observable differences.
Similarly, as production tools change, publication versions may be regenerated t o ensure a consistent presentation.</t> Similarly, as production tools change, publication versions may be regenerated t o ensure a consistent presentation.</t>
</section>
</section> <section anchor="archived-documents">
<section anchor="archived-documents"><name>Archived Documents</name> <name>Archived Documents</name>
<t>The RPC will keep an archived set of all definitive versions of RFCs as
<t>The RPC will keep an archived set of all definitive versions of RFCs as well well as archived sets of the publication versions for an RFC that were previous
as archived sets of the publication versions for an RFC that were previously pub ly published.
lished.
These archived sets must be available using the same access methods as for curre nt definitive and publication versions. These archived sets must be available using the same access methods as for curre nt definitive and publication versions.
Every archived set shall record the date that a definitive and/or publication ve rsion was created or reissued.</t> Every archived set shall record the date that a definitive and/or publication ve rsion was created or reissued.</t>
<t>When the RPC archives definitive and publication versions, it does so i
<t>When the RPC archives definitive and publication versions, it does so in a ma n a manner that allows them to be found by people who want the historical (as co
nner that allows them to be found by people who want the historical (as compared mpared to current) files.</t>
to current) files.</t> <t>This document does not specify how archives are maintained or how archi
ved documents might be located or identified.
<t>This document does not specify how archives are maintained or how archived do
cuments might be located or identified.
The methods for storage and access will be determined by the RPC in consultation with the technical community.</t> The methods for storage and access will be determined by the RPC in consultation with the technical community.</t>
</section>
<section anchor="iana-considerations">
<name>IANA Considerations</name>
<t>This document has no IANA actions.</t>
</section>
<section anchor="security-considerations">
<name>Security Considerations</name>
</section> <t>Allowing changes to the definitive version and publication versions
<section anchor="iana-considerations"><name>IANA Considerations</name> of RFCs introduces risks. A significant risk is that unintended changes
could occur in either the definitive version or publication versions of
<t>This document has no IANA considerations.</t> an RFC as a result of an editing error. In addition, unintended changes
may be introduced into a publication version when it is regenerated from
</section> the definitive version. This may result in the corruption of a
<section anchor="security-considerations"><name>Security Considerations</name> standard, practice, or critical piece of information about a protocol,
which may harm the reputation of the RFC Series.
<t>Allowing changes to the definitive versions and publication versions of RFCs </t>
introduces risks. <t>The RPC is expected to identify, track, and actively mitigate risks int
A significant risk is that unintended changes could occur in either the definiti roduced by this new policy.</t>
ve version or publication versions of an RFC as a result of an editing error, or </section>
may be introduced into a publication version when it is regenerated from the de
finitive version.
This may result in the corruption of a standard, practice, or critical piece of
information about a protocol, and harm to the reputation of the RFC series.</t>
<t>The RPC is expected to identify, track, and actively mitigate risks introduce
d by this new policy.</t>
</section>
<section anchor="acknowledgments"><name>Acknowledgments</name>
<t>Martin Thomson wrote a great deal of the significant text here as part of dra
ft-thomson-rswg-syntax-change.</t>
<t>This document has greatly benefited from the input of the RSWG.
In particular,
Alexis Rossi,
Brian Carpenter,
Eliot Lear,
Jay Daley,
Jean Mahoney,
John Levine,
and Pete Resnick,
gave significant input on the early drafts of this document.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="RFC0020" to="RFC20"/>
<references title='References' anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name>
<references title='Normative References' anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name>
<reference anchor="RFC7991"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 991.xml"/>
<title>The "xml2rfc" Version 3 Vocabulary</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/> 996.xml"/>
<date month="December" year="2016"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 997.xml"/>
<t>This document defines the "xml2rfc" version 3 vocabulary: an XML-based <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
language used for writing RFCs and Internet-Drafts. It is heavily derived from t 280.xml"/>
he version 2 vocabulary that is also under discussion. This document obsoletes t </references>
he v2 grammar described in RFC 7749.</t> <references anchor="sec-informative-references">
</abstract> <name>Informative References</name>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
<seriesInfo name="RFC" value="7991"/> 020.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7991"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</reference> 949.xml"/>
<reference anchor="RFC7996"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<front> 990.xml"/>
<title>SVG Drawings for RFCs: SVG 1.2 RFC</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname="N. Brownlee" initials="N." surname="Brownlee"/> 651.xml"/>
<date month="December" year="2016"/> </references>
<abstract>
<t>This document specifies SVG 1.2 RFC -- an SVG profile for use in diagra
ms that may appear in RFCs -- and considers some of the issues concerning the cr
eation and use of such diagrams.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7996"/>
<seriesInfo name="DOI" value="10.17487/RFC7996"/>
</reference>
<reference anchor="RFC7997">
<front>
<title>The Use of Non-ASCII Characters in RFCs</title>
<author fullname="H. Flanagan" initials="H." role="editor" surname="Flanagan
"/>
<date month="December" year="2016"/>
<abstract>
<t>In order to support the internationalization of protocols and a more di
verse Internet community, the RFC Series must evolve to allow for the use of non
-ASCII characters in RFCs. While English remains the required language of the Se
ries, the encoding of future RFCs will be in UTF-8, allowing for a broader range
of characters than typically used in the English language. This document descri
bes the RFC Editor requirements and gives guidance regarding the use of non-ASCI
I characters in RFCs.</t>
<t>This document updates RFC 7322. Please view this document in PDF form t
o see the full text.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7997"/>
<seriesInfo name="DOI" value="10.17487/RFC7997"/>
</reference>
<reference anchor="RFC9280">
<front>
<title>RFC Editor Model (Version 3)</title>
<author fullname="P. Saint-Andre" initials="P." role="editor" surname="Saint
-Andre"/>
<date month="June" year="2022"/>
<abstract>
<t>This document specifies version 3 of the RFC Editor Model. The model de
fines two high-level tasks related to the RFC Series. First, policy definition i
s the joint responsibility of the RFC Series Working Group (RSWG), which produce
s policy proposals, and the RFC Series Approval Board (RSAB), which approves suc
h proposals. Second, policy implementation is primarily the responsibility of th
e RFC Production Center (RPC) as contractually overseen by the IETF Administrati
on Limited Liability Company (IETF LLC). In addition, various responsibilities o
f the RFC Editor function are now performed alone or in combination by the RSWG,
RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC. Finally, this doc
ument establishes the Editorial Stream for publication of future policy definiti
on documents produced through the processes defined herein.</t>
<t>This document obsoletes RFC 8728. This document updates RFCs 7841, 8729
, and 8730.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9280"/>
<seriesInfo name="DOI" value="10.17487/RFC9280"/>
</reference>
</references>
<references title='Informative References' anchor="sec-informative-reference
s">
<reference anchor="RFC20">
<front>
<title>ASCII format for network interchange</title>
<author fullname="V.G. Cerf" initials="V.G." surname="Cerf"/>
<date month="October" year="1969"/>
</front>
<seriesInfo name="STD" value="80"/>
<seriesInfo name="RFC" value="20"/>
<seriesInfo name="DOI" value="10.17487/RFC0020"/>
</reference>
<reference anchor="RFC6949">
<front>
<title>RFC Series Format Requirements and Future Development</title>
<author fullname="H. Flanagan" initials="H." surname="Flanagan"/>
<author fullname="N. Brownlee" initials="N." surname="Brownlee"/>
<date month="May" year="2013"/>
<abstract>
<t>This document describes the current requirements and requests for enhan
cements for the format of the canonical version of RFCs. Terms are defined to he
lp clarify exactly which stages of document production are under discussion for
format changes. The requirements described in this document will determine what
changes will be made to RFC format. This document updates RFC 2223.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6949"/>
<seriesInfo name="DOI" value="10.17487/RFC6949"/>
</reference>
<reference anchor="RFC7990">
<front>
<title>RFC Format Framework</title>
<author fullname="H. Flanagan" initials="H." surname="Flanagan"/>
<date month="December" year="2016"/>
<abstract>
<t>In order to improve the readability of RFCs while supporting their arch
ivability, the canonical format of the RFC Series will be transitioning from pla
in-text ASCII to XML using the xml2rfc version 3 vocabulary; different publicati
on formats will be rendered from that base document. With these changes comes an
increase in complexity for authors, consumers, and the publisher of RFCs. This
document serves as the framework that provides the problem statement, lays out a
road map of the documents that capture the specific requirements, and describes
the transition plan.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7990"/>
<seriesInfo name="DOI" value="10.17487/RFC7990"/>
</reference>
<reference anchor="RFC8651">
<front>
<title>Dynamic Link Exchange Protocol (DLEP) Control-Plane-Based Pause Exten
sion</title>
<author fullname="B. Cheng" initials="B." surname="Cheng"/>
<author fullname="D. Wiggins" initials="D." surname="Wiggins"/>
<author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
<date month="October" year="2019"/>
<abstract>
<t>This document defines an extension to the Dynamic Link Exchange Protoco
l (DLEP) that enables a modem to use DLEP messages to pause and resume data traf
fic coming from its peer router.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8651"/>
<seriesInfo name="DOI" value="10.17487/RFC8651"/>
</reference>
</references> </references>
</references> <section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t><contact fullname="Martin Thomson"/> wrote a great deal of the signific
ant text here as part of draft-thomson-rswg-syntax-change-01.</t>
<t>This document has greatly benefited from the input of the RSWG.
In particular,
<contact fullname="Alexis Rossi"/>,
<contact fullname="Brian Carpenter"/>,
<contact fullname="Eliot Lear"/>,
<contact fullname="Jay Daley"/>,
<contact fullname="Jean Mahoney"/>,
<contact fullname="John Levine"/>,
and <contact fullname="Pete Resnick"/>
provided significant input on the early draft versions of this document.</t>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA71aa4/byLH9zl/RkIGbMSDp2pPEXo+BRSZjO55kvevr8W7y
7aJFtqTOUGymmxxZMfzf76mq7ib1sp0vF1hjOVQ/qutx6lQ1Z7NZ0dmuNlfq
w5sb9cb5je6C0k2lfjM+WNeEQi8W3jx8ZUDlykZvsETl9bKb+bBdzfyyfP7i
xZNZ31a6M2H29LIoQodp/6tr12Bs53tTYNXfF24RXG0w6ErRlCJOuVIvLn94
UhS29Tw6dJdPnrx4clncb6/UbdMZ35hu9oq2LErdXSnbLF0R+sXGBpLr467F
NqaynfNW10Wh+27t/FWhZoVSGI0d3s/VW7dcbnRDr+QQ73Vfj986v8J+N9c/
/0x/mY229ZVqMWi+lkF/sqVumjnGjZd+O1dvat3o1Xjtt0Z3a+P3fuH171q8
xjq1unFb/GtCX3e2WY22XNfLP4U0rHTbMg+al25TFA2bxj4YnJBsBV0+HR6f
DY/P4yOp9wr6hdr2Z14+iQ/PXvzhxTAvvf3h2R+xcDGbzZRehM7rsiuK2wYH
qXC0zim7ab17MApHVd7oSi9sbbudckuaHtR2bWujQt+2zpP8NNB6pX25tg9x
8JRnV2ZpG0uiqQfxNlqEfiFnvIMuTIBv6CZgENyqUkvvNqqttW1mnfnUqeu7
m9tbEuof735SfYi70XR68eBKvehr7XcvVWWXS+NN06m2X9RQMq2YtoXHezpM
gyOmXbq17tRCB4jpyn6DmfPi49qG/CfED6W3C8i4hlX57LQMrx/WppoXBxNy
KPD5SOeHS+o6OBUjhE+CoIrqbR2k3sH7eDJZF+uzmTa2qmpTFI8obryr+pLO
VhSTkRYlstUH86/eekN7SZS/6bseMr8yD6Z2Lb2fqM+fo3N8+QK1hbIPAUoh
aRpDD/sugBEwCJvfdmYTYPlyrTSW54Dk0JC9tO+2zt/HIwQaszV1Tf8/t/ih
b+HnRd4SwzGyNb7GANhSe+t6KNM82NKEefFnTXLjlygmHYSNvbXdWiGqNj15
H6Qj2QlyTOimWX6adfv645vpoUe+ZtDBPqWtRGTzqa0d1KhVudbNytA7miSh
l5xaps8L1i9ZH/rdxo3Kvt7YRpySh2OarMrvjlwJz0CIklCykvPQKm22ftLY
FDKUEhhREdk982IQ6Rbe7HC0xsEHqwqKIJPt4nFCOg/Wh2YDXhgNJQEdjN4g
7mREJU7EtkZKsWYbQ39A7aAuQgu9LQnlasAARc4+2pN54BRkZlnPVI/nxd8Z
VG5nrxBs+oE0HezGIrRVMKxgrN9HP4uKwdkr+HrZwT3imQQfHGI6DoeBZNGw
dn1dReeKHk9qha/yUbPi5cxsD5KwA3iHjAQV+Xa3H9FwCxgSYoirQDiAYs8u
Ep0Fzg5gtRuTvC655o6Pk7zv/WDcG0MqUxcf3t88ViugIU7Se849tBfcDBqg
QKo51BMsMoSQBw/yYorBYW7TUOeD+B8pCXK0gF3GCvLu6sEGOYV+cBYBDSVu
ZHFN2FVL7CSnSXZc6PJ+q30VZrQg/HlR056PHqmbwb0SIhZ74cEZAltqYDJw
hOGDbJYBd5vMNrg1fIj0SSJlK1CY5RFTWKms+4okb+CkyxHr0fxmgpTvGk7Y
8uOEd5UURtNob46aTtf3tOfC9Z2akJIp8SzhrBOypuXIh+5ETtfAFyEslJrH
ycqC6gtTakSTCJ+gQbxHoAGv6RU7yyGMjPLObcwk+9KNE1888yS5XE6EMP7b
j+9+Aughv05ZJ+9fvYEhPNJ0To3mhIpg0mtWPSYapOwHM3ZGxqgoYtKgREtO
1xEt07mefvkCS3WI9wDFmGYAXPY21tjvwqBHCES6lexZsVob7b3bQuc1wIJe
tr1v4dnhMO8mlx3rFMIFu2oYq9iFdoF4kSKsZLck+OjhacZvggjlDfJSKamL
7BiBn0aMFDYRlAJ4YW2sMokKJAKm1EwRskxG3Cj+PCVmhfCyISrszPBoyvF4
PQoP8rOo96M94orXp3xlvF7Ze6JSnHf5lHCRqfCy6DdQPrnR6QW/T8K4dM5Z
+567bwid6NGKwLQhByOIOHauaOj5menkNNu1OVLPiJ7GUD3wNrKoq4khH88K
ETgoMr9j25P89Ds2PsNr085Iodhg4MiEc+SYtnG1W+041GAIJA3QdnJ4gDLo
QASjcWD0iQ4e+HXGSszcGIgJukeS7EbkmzLqKszV//SO0xLjScJ+hNeP6uZg
uSshgkwm7b8JvZHTHeKSn3VZmrbjJ2aYctrDciLFOarEpqJNrgVH13a1BudT
NTEN4XkJCRaGxNvoKpM5kjJ6kW0eXA0Do3LW9zROAx3kLMTwERdSmAwRweJt
HCcPyp/qUGuiZklM5BpInbRpLt9wGC/kXaBNihXee8QKG157C5hkOmyEOp8I
nyNCKSQOBmM4m55EFD7ESWQiiThXaV9b4895Bnb9hVnKyPGyxlnXi90J/iRU
uq7dFue9khjKzJQiZu2pTpt82tSXfllm6/+eXXEiCDCZH0+k2iT5yMJVOzFC
QqIgSYrNyrWUEP+86DEjmwglwzHf2kCNCTo7m58XGQdRqjLujCxwqS4mWA/U
aKPukO2ZjU0eT/OAP2DALzgZ8+oo8ytkRDrp7J244Xvh5zSNTJWmPn2CuR9z
Ha3e17qZPEbxxdUqZ0SCcqTIbkjxIyMgW548Q8p5hpFom0gLYTdbWQqQFnWf
LakMxyZJpB/UxRu7QukptOtaSsPHe2K/UBc3YMvsBURDNLjyT3oHLhNlZ46D
atYJwJ1glFQmq8+Pos1nnZvRmy9FkfZ4Pn9GyuRT8U9fRsktSMr/Uf1CDGbE
H0fFYC6i2FOpfpLNjqv/SA4iVQjkMIkYnduEgoIJozczrljwetELdgWzAUrb
kisK7i4sT6eAsNbCw1toG/4jDJ6WWHmyXOiEscHxHUokIecn2hKljI4UOWYu
YapMbs0n+DwZP+v2QLN8yufzH+aKW2AYDQXs8A7/5e5J6doddfXoqIIa/DjS
CyNpUotohTMOoLYjuNWkEVm9kzM3XSqiP3/mvIlYgaFpoc+fsfIs6UpY3zEA
LYZOAn5KqXfoyIwOKYXN38wuu2KmzK8jOEbooEiVMnJpPTRHr6W/MVChjHpi
r95Wmrwkhv/Ku77NvZG9IvSwOOC/qbVHpHpYHyN/KTu3gFSXT56+mFOjLxcY
oArCZZsp56M9hhbrcBEw8oGVaYwH4sHPmyO0oPLgm1n3iGt8PQFX38zAvNYl
rfSVXHyU0f7fkzF5ATIHF4Ab8uvQkg8vYnm4cZwFodV/9kGUOGqCcvUjxSuV
aoMwuYyU0B1Vb2NljErKffFeitYhVgMuncL/DDOWToU35/lrMqEd9ZI3xnSx
PUdDTVKrIGqclNsh8xQuDZws8Xo6vPS9yB12WWZ7VlTSKHnwS64uQZ5PW5g6
gk0VLSzke15cVxXnUF2fPueFFM9cD5FKBkU/lh4KIekQSIO84gMnnIOnHcT2
AWbRRsu+powlzTUZNyRhTo5gC1kVvx3WM6mfdaSsr6j2hALE5f5DnSbnJ1BP
/dNvlV9Dz+xCYhVEYzQ3eQYRoSNkHFLAHDzAjBsOmciCu63YzahlRT37uEg7
aq5ik+iRtB1L7yQF3f32F1WjxKOWN0uQloOJTsL0M5LlIx2EpnLjjD1FtyBX
PtXr5Fsn3W5+UgqQ75mgIDRD9zgY/V3SPBdpTDCjmVGqLFAy72l5zrnThvAr
CUhLjL2jMZQTNQrGzkUYE6qTvfrUZi+5U/2vHimFgYibXSMyGj3OHlfXqUEJ
YrwdX/zAv8l5uI+GZ7Dj5SzKnLrt6fRHLOweWMl9uvFG5Kjz4o0jxdE1aWkk
oy4BqcyBI5PmIrk0zMd8MpB0QG3T9rmbrOlE+137pNPgS+zewaZ9Fxvc/1V3
L+Pdy48q/h1c70vU0ZX5URlp/UpD83hFgl+BY58uACi50Em8VD9BSM+vMa5i
aXIebMDIcwwWxRmeexy3hyyewnfcb2bfSiR3zzqBlEYXAIMf5ABnCPpgdCD4
Zh55b/b72JEHDPdymY5QxIVyjV2mynhPzXO6PiBwGnb6ByUE7vjtX6Z0DvwR
2upjT13YU2e+2gT65rXpAKfs3ffGtKm5VnLnxFc0mrtNtssKl+sezBdRV1bu
WNbOd4fIZ+EKnvXFDRx4Bd+QyOnEE16nC49fB5XFnmWMKTaLbZmV7JE+AuEU
l5Foz4tfT2s+3SR1OfNwim3b2qZ7OZQBudsc73gGD/l6FfSfeRBpfeXwFzTE
3WbaNlmc+/7YLuwQUp84f7rTnsqNM5oKHHCHsLV3a5eKtFiF5LCNDEr00R/q
P93cQMHehvt488k5nnYd4Gzw1T0lUoWAykpX3C/kc8UNU11LkZO25UIsoXjr
SL1WukFHO6EO4MDrTMu79oT+/EkJT07C6sOJ6sJY5jmVqQEVHECMs7pCcNCO
sRmCNdku8W6LFoy86P0o1tJXL4CoPZJV5LAilVP3inslVIyPlF5J4pKQ+kYj
9zsR7jbee5ABELTSPUvfCHxHv3iaWRtHFStZKpOydD3cfeHi5XFS8ZEPxDvV
VLAnsAnxOrsYtdcjCNKMhek6NgtdomAtR5fyUjTKbc4AlJFaDteeufIcSuOQ
2lUpDo6+9hAR5tLnTiSQ+wEnAHPwunMaHNgosP2B0HIp1GCD8jVZnT7RYaq9
oFDWhBqp182fINzJJTXddNMN3dAvJPAPef2zAnBKTIlBIK0JvXxpcLbJ8Uhd
pz74q9SdKk6lhWZomMdbdMKFUxcYqccw+mRjPDWnppMHGV1wSkXKhqQvBFwf
ACCji0shnftLc1onlvagoUtS8WD6QNUy3QEEjENwuIplpB1jG298HC7ITtLV
13xNsacNaZvFjMlpV6fLEH2w6H+7k7cve6U3dwmE26S7mBSYcdvwPaIy7DLW
ozpg50awNum+W1MzhouzTWwlLRHjHGCtcahjACEOYjWpEZOb1BckKt3ORxCL
2nvMRPj4tiBnG8nBO75ty+egLJzacXL00c+j705iKEHM2pVJS8gXQB9i+5JU
k1k5aUBc6gJzs0OsPnwsIncKB5Vqo+KHdInxR7DrTLmWq4lxd4E+obr++Vra
k5WRb2/C4eHpQrpxMrLcGylL3Bloj2DscJnr1Mw7YIInrwzPOEAOxZS2sUzM
Zdd799UM5zZmZRww1UFp71K+SCghK6kpZtFz/PLM9eJA6QkREiDKW+riMpOh
nMA3whHRsuRV6pGdDJ7IUG3Yg8DcwjqWMl7q0y4DMkti8b7P/FUrphXaU1uZ
iltL5RghBozGLtFaI03WcXEqdaUmEO9c6WphFSiPN8mM3qBEG33CJe2unCZH
BGL8QVD0d/okEsLcx4vMkg4GbCQiuSLgYRuPVZduyoZm/FwpBv+SatDaVKuI
/O/oAqZRH9duE0ixnm51tfBeqFE4K6PpyH24N8ifrlDiwgo0SL4A7mQh+RJY
KO0ss//jUOF9+LuXBibbs6EUtUlZd3//C/Od4cJoipAh+qk+ECefFn/2Fo51
o33L123T4nVtAUI/GRr6V9j9la7NDo90+/xOr13Df7l1gzEPAIdpwTdJ1M/5
YAIA4H5arIiSjI8epWryjeZODh6z3N7FGH+ASR84Ff8Hbje5NGwtAAA=
</rfc> </rfc>
 End of changes. 39 change blocks. 
496 lines changed or deleted 251 lines changed or added

This html diff was produced by rfcdiff 1.48.