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 " "> | <!ENTITY nbsp " "> | |||
<!ENTITY zwsp "​"> | <!ENTITY zwsp "​"> | |||
<!ENTITY nbhy "‑"> | <!ENTITY nbhy "‑"> | |||
<!ENTITY wj "⁠"> | <!ENTITY wj "⁠"> | |||
]> | ]> | |||
<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"/> | <!-- [rfced] Please insert any keywords (beyond those that appear in | |||
the title) for use on https://www.rfc-editor.org/search. --> | ||||
<keyword>Internet-Draft</keyword> | <keyword>example</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 | ||||
ge over time as the community and the RFC Production Center (RPC) gain further e | ||||
xperience 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> | ||||
<section anchor="changes-to-rfc-7990"> | ||||
<name>Changes to RFC 7990</name> | ||||
<!-- [rfced] We wonder about trimming this sentence down for simplicity. | ||||
<t>The details described in this document are expected to continue to change ove | Original: | |||
r time as the community and the RFC Production Center (RPC) gains further experi | [RFC7990] defined a framework for how RFCs would be published after | |||
ence implementing the policies described here.</t> | that document was published, including new formats and a new | |||
"canonical format" for archiving RFCs. | ||||
<t>Implementors of those components are advised to avoid assuming that all such | Perhaps A: | |||
changes will be backwards-compatible.</t> | [RFC7990] defined a framework for how RFCs would be published. | |||
<section anchor="changes-to-rfc-7990"><name>Changes to RFC 7990</name> | Or perhaps B: | |||
[RFC7990] defined a framework for how RFCs would be published, | ||||
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. | <t><xref target="RFC7990"/> defined a framework for how RFCs would be pub lished after that document was published, including new formats and a new "canon ical format" 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 F derived from the "canonical format".</t> | It also talked about "publication formats" as the versions of HTML, text, and PD F 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"> | <!-- [rfced] If no objections, we will use a definition list under the first | |||
<t>It defines four terms that replace the use of the term "canonical" and clar | bullet in Section 1.1. | |||
ifies "format": | ||||
<list style="symbols"> | ||||
<t>The "definitive format", which is RFCXML</t> | ||||
<t>The "definitive version", which is a published RFC in the definitive fo | ||||
rmat</t> | ||||
<t>A "publication format", which is currently one of PDF, plain text, or H | ||||
TML</t> | ||||
<t>A "publication version", which is a published RFC in one of the publica | ||||
tion formats</t> | ||||
</list></t> | ||||
<t>It defines a policy governing how the RFCXML format changes.</t> | ||||
<t>It defines a policy for when the definitive version of an RFC can be update | ||||
d and older definitive versions archived.</t> | ||||
<t>It defines a policy for when the publication versions of an RFC can be upda | ||||
ted and older publication versions archived.</t> | ||||
</list></t> | ||||
<t>When using the new terminology, it is important to note that <xref target="RF | Original: | |||
C7990"/> used the term "canonical format" to mean two very different things. Quo | * It defines four terms that replace the use of the term "canonical" | |||
ting from RFC 7990:</t> | and clarifies "format": | |||
<ul empty="true"><li> | - The "definitive format", which is RFCXML | |||
<t>Canonical format: the authorized, recognized, accepted, and archived versio | ||||
n of the document</t> | ||||
</li></ul> | ||||
<t>and</t> | - The "definitive version", which is a published RFC in the | |||
definitive format | ||||
<ul empty="true"><li> | - A "publication format", which is currently one of PDF, plain | |||
<t>At the highest level, the changes being made to the RFC format involve brea | text, or HTML | |||
king away from solely ASCII plain text and moving to a canonical format that inc | ||||
ludes all the information required for rendering a document into a wide variety | ||||
of publication formats.</t> | ||||
</li></ul> | ||||
<t>This document uses two terms, "definitive version" and "definitive format", f | - A "publication version", which is a published RFC in one of the | |||
or the earlier term "canonical format".</t> | publication formats | |||
<t>Other terminology changes made by this document are the following: | Perhaps: | |||
- It changes the phrase "xml2rfc version 3" to "RFCXML". | * It defines four terms that replace the use of the term "canonical" | |||
- It changes the name of the body that publishes RFCs from "RFC Editor" to "RFC | and clarifies "format": | |||
Production Center" (RPC).</t> | ||||
<t>Historical text from <xref target="RFC7990"/> such as Section 2 ("Problem Sta | definitive format: RFCXML | |||
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> | definitive version: a published RFC in the definitive format | |||
<section anchor="changes-to-9280"><name>Changes to RFC 9280</name> | ||||
<t>Section 7.6 of <xref target="RFC9280"/> currently says:</t> | publication format: currently one of PDF, plain text, or HTML | |||
<ul empty="true"><li> | publication version: a published RFC in one of the publication formats | |||
<t>Once published, RFC Series documents are not changed.</t> | --> | |||
</li></ul> | ||||
<t>This document replaces that sentence with:</t> | <ul spacing="normal"> | |||
<li> | ||||
<t>It defines four terms that replace the use of the term "canonical | ||||
" and clarifies "format": | ||||
</t> | ||||
<ul spacing="normal"> | ||||
<li> | ||||
<t>The "definitive format", which is RFCXML</t> | ||||
</li> | ||||
<li> | ||||
<t>The "definitive version", which is a published RFC in the def | ||||
initive format</t> | ||||
</li> | ||||
<li> | ||||
<t>A "publication format", which is currently one of PDF, plain | ||||
text, or HTML</t> | ||||
</li> | ||||
<li> | ||||
<t>A "publication version", which is a published RFC in one of t | ||||
he publication formats</t> | ||||
</li> | ||||
</ul> | ||||
</li> | ||||
<li> | ||||
<t>It defines a policy governing how the RFCXML format changes.</t> | ||||
</li> | ||||
<li> | ||||
<t>It defines a policy for when the definitive version of an RFC can | ||||
be updated and older definitive versions archived.</t> | ||||
</li> | ||||
<li> | ||||
<t>It defines a policy for when the publication versions of an RFC c | ||||
an be updated and older publication versions archived.</t> | ||||
</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 | ||||
ngs. Quoting from RFC 7990:</t> | ||||
<ul empty="true"><li> | <blockquote> | |||
<t>Once published, RFCs may be re-issued, but the semantic content of publicat | <t>Canonical format: the authorized, recognized, accepted, and archi | |||
ion versions shall be preserved to the greatest extent possible.</t> | ved version of the document</t> | |||
</li></ul> | </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>This document also creates a new policy that would exist in Section 7 of <xre | <ul spacing="normal"> | |||
f target="RFC9280"/>:</t> | <li>It changes the phrase "xml2rfc version 3" to "RFCXML".</li> | |||
<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 Sections <xref | ||||
target="RFC7990" section="2" sectionFormat="bare"/> ("Problem Statement"), <xre | ||||
f target="RFC7990" section="4" sectionFormat="bare"/> ("Overview of the Decision | ||||
-Making Process"), and <xref target="RFC7990" section="10" sectionFormat="bare"/ | ||||
> ("Transition Plan"), was purposely omitted from this document. | ||||
Text from <xref target="RFC7990"/> that repeated what was in other RFCs, particu | ||||
larly Sections <xref target="RFC7990" section="8" sectionFormat="bare" /> ("Figu | ||||
res and Artwork") and <xref target="RFC7990" section="9" sectionFormat="bare" /> | ||||
("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> | ||||
<ul empty="true"><li> | <!-- [rfced] Does "to maintain a consistent presentation" apply to all verbs (in | |||
<t>7.8. Consistency</t> | which case, "published" seems odd)? Please review. | |||
<t>RFCs are copyedited, formatted, published, and may be reissued to maintain | Original: | |||
a consistent presentation.</t> | 7.8. Consistency | |||
</li></ul> | ||||
<t><xref target="updating"/> and <xref target="pub-versions"/> in this document | RFCs are copyedited, formatted, published, and may be reissued to | |||
are based on this updated policy in <xref target="RFC9280"/>.</t> | maintain a consistent presentation. | |||
</section> | Perhaps A (two sentences): | |||
<section anchor="key-changes-from-the-earlier-rfc-process"><name>Key Changes fro | 7.8. Consistency | |||
m the Earlier RFC Process</name> | ||||
<t>The first RFC to be published following the guidance of the group of RFCs des | RFCs are copyedited, formatted, and then published. They may be reissued t | |||
cribed in <xref target="RFC7990"/> was <xref target="RFC8651"/>, published in Oc | o | |||
tober 2019. | maintain a consistent presentation. | |||
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 to the R | Perhaps B (remove "published"): | |||
FC format involved breaking away from solely ASCII <xref target="RFC20"/> plain | RFCs are copyedited and formatted and may be reissued to maintain | |||
text and moving to a definitive format that includes all the information require | a consistent presentation. | |||
d for rendering a document into a wide variety of publication formats. | --> | |||
<blockquote> | ||||
<t>7.8. Consistency</t> | ||||
<t indent="3">RFCs are copyedited, formatted, published, and may be | ||||
reissued to maintain a consistent presentation.</t> | ||||
</blockquote> | ||||
<!-- [rfced] Should "updated policy" here be updated to "new policy"? | ||||
Original: | ||||
Section 2.1 and Section 3 in this document are based on this updated | ||||
policy in [RFC9280]. | ||||
Perhaps: | ||||
Sections 2.1 and 3 in this document are based on this new | ||||
policy in [RFC9280]. | ||||
--> | ||||
<t>Sections <xref target="updating" format="counter"/> and <xref target="pub-ver | ||||
sions" format="counter"/> in this document are based on this updated policy in < | ||||
xref target="RFC9280"/>.</t> | ||||
</section> | ||||
<section anchor="key-changes-from-the-earlier-rfc-process"> | ||||
<name>Key Changes from the Earlier RFC Process</name> | ||||
<!-- [rfced] Please review "following the guidance of the group of RFCs | ||||
described in [RFC7990]". Are any updates needed for clarity? | ||||
Original: | ||||
The first RFC to be published following the guidance of the group of | ||||
RFCs described in [RFC7990] was [RFC8651], published in October 2019. | ||||
Perhaps: | ||||
The first RFC to be published following the guidance | ||||
in [RFC7990] was [RFC8651], published in October 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> | ||||
<t>At the highest level, the changes that <xref target="RFC7990"/> made | ||||
to the RFC format involved breaking away from solely ASCII <xref target="RFC0020 | ||||
"/> plain text and moving to a definitive format that includes all the informati | ||||
on required 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> | |||
<!-- [rfced] Is "publication formats" correct here? We ask because Section 3 is | ||||
titled "Publication Versions". Also, would it be helpful to include references | ||||
for the other RFCs that specify these? | ||||
Original: | ||||
The publication formats are described in | ||||
Section 3 and fully specified in other RFCs. | ||||
--> | ||||
<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 y the RPC. | Additional publication versions (HTML, PDF, and plain text) are also published b y the RPC. | |||
The publication formats are described in <xref target="pub-versions"/> and fully specified in other RFCs.</t> | The publication formats are described in <xref target="pub-versions"/> and fully specified in other RFCs.</t> | |||
</section> | ||||
</section> | ||||
<section anchor="definitive-version-of-an-rfc"> | ||||
<name>Definitive Version of an RFC</name> | ||||
</section> | <!-- [rfced] Please review "The definitive version...is the publication | |||
</section> | version". Should this be updated as follows? | |||
<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 | Original: | |||
lds all the information intended for an RFC. | The definitive version produced by the RPC is the publication version | |||
that holds all the information intended for an RFC. | ||||
Perhaps: | ||||
The definitive version produced by the RPC | ||||
holds all the information intended for an RFC. | ||||
--> | ||||
<t>The definitive version produced by the RPC is the publication version t | ||||
hat holds all the information intended for an RFC. | ||||
The RPC may change the definitive version of an RFC over time (that is, change t he XML file), as described in <xref target="updating"/>. | The RPC may change the definitive version of an RFC over time (that is, change t he XML file), as described in <xref target="updating"/>. | |||
See <xref target="RFC7991"/> for the original complete description of RFCXML.</t > | See <xref target="RFC7991"/> for the original complete description of RFCXML.</t > | |||
<!-- [rfced] Should "HTML publication versions" be singular? | ||||
Original: | ||||
That SVG will also appear in the HTML publication | ||||
versions. | ||||
--> | ||||
<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 versions. | |||
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 <artwork> or <sourcecode> ele ments. | It does not contain src attributes for <artwork> or <sourcecode> 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> | |||
<!-- [rfced] To avoid personifying "updates" (updates consider, take steps, limi t), we suggest the following. | ||||
<t>This policy does not require that updates to RFCXML avoid all risk of introdu | Original: | |||
cing semantic changes to existing RFCs. | Instead, it only | |||
Instead, it only requires that such updates consider the potential for semantic | requires that such updates consider the potential for semantic | |||
changes, take steps to understand the risk of a semantic change (either delibera | changes, take steps to understand the risk of a semantic change | |||
te or inadvertent), and to limit those risks.</t> | (either deliberate or inadvertent), and to limit those risks. | |||
</section> | ||||
</section> | ||||
<section anchor="pub-versions"><name>Publication Versions</name> | ||||
<t>The RPC is permitted but not required to re-issue publication versions of an | ||||
RFC, as described in <xref target="changes-to-9280"/>. | ||||
In deciding whether to update the publication versions of an RFC, the RPC will 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 | Original: | |||
nity since the first RFCs were published using the RFCXML format. | Instead, it only | |||
requires that the potential for semantic | ||||
changes be considered, steps to understand the risk of a semantic change | ||||
(either deliberate or inadvertent) be taken, and associated risks be limited. | ||||
--> | ||||
<t>This policy does not require that updates to RFCXML avoid all risk of | ||||
introducing semantic changes to existing RFCs. | ||||
Instead, it only requires that such updates consider the potential for semantic | ||||
changes, take steps to understand the risk of a semantic change (either delibera | ||||
te or inadvertent), and limit those risks.</t> | ||||
</section> | ||||
</section> | ||||
<section anchor="pub-versions"> | ||||
<name>Publication Versions</name> | ||||
<t>The RPC is permitted but not required to reissue publication versions o | ||||
f an RFC, as described in <xref target="changes-to-9280"/>. | ||||
In deciding whether to update the publication versions of an RFC, the RPC will 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 | ||||
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> | <!-- [rfced] Should "definitive versions" here be singular (i.e., "definitive | |||
<section anchor="iana-considerations"><name>IANA Considerations</name> | version")? | |||
<t>This document has no IANA considerations.</t> | Original: | |||
Allowing changes to the definitive versions and publication versions | ||||
of RFCs introduces risks. | ||||
</section> | Perhaps: | |||
<section anchor="security-considerations"><name>Security Considerations</name> | Allowing changes to the definitive version and publication versions | |||
of RFCs introduces risks. | ||||
--> | ||||
<t>Allowing changes to the definitive versions and publication versions of RFCs | <!-- [rfced] Would it be helpful to either add numbers or use two sentences | |||
introduces risks. | here to improve clarity? | |||
A significant risk is that unintended changes could occur in either the definiti | ||||
ve version or publication versions of an RFC as a result of an editing error, or | ||||
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 | Original: | |||
d by this new policy.</t> | A significant risk is that unintended | |||
changes could occur in either the definitive version or publication | ||||
versions of an RFC as a result of an editing error, or may be | ||||
introduced into a publication version when it is regenerated from the | ||||
definitive version. | ||||
</section> | Perhaps (add numbers): | |||
<section anchor="acknowledgments"><name>Acknowledgments</name> | A significant risk is that unintended | |||
changes could 1) occur in either the definitive version or publication | ||||
versions of an RFC as a result of an editing error or 2) be | ||||
introduced into a publication version when it is regenerated from the | ||||
definitive version. | ||||
<t>Martin Thomson wrote a great deal of the significant text here as part of dra | Or (split into two sentences): | |||
ft-thomson-rswg-syntax-change.</t> | A significant risk is that unintended | |||
changes could occur in either the definitive version or publication | ||||
versions of 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 the | ||||
definitive version. | ||||
--> | ||||
<t>This document has greatly benefited from the input of the RSWG. | <!-- [rfced] To improve clarity, may we update the text starting with "and | |||
In particular, | harm" as follows? | |||
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> | Original: | |||
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. | ||||
</middle> | Perhaps: | |||
This may result in the corruption of a 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 introduces risks. | ||||
A significant risk is that unintended changes could occur in either the definiti | ||||
ve version or publication versions of an RFC as a result of an editing error, or | ||||
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 int | ||||
roduced by this new policy.</t> | ||||
</section> | ||||
</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> | |||
<references title='Informative References' anchor="sec-informative-reference | <section anchor="acknowledgments" numbered="false"> | |||
s"> | <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> | ||||
<reference anchor="RFC20"> | <!-- [rfced] Would you like to use a consistent ordering when referring to the | |||
<front> | publication formats? We see the following (also note "text" and "plain | |||
<title>ASCII format for network interchange</title> | text"): | |||
<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> | HTML, text, and PDF | |||
</references> | PDF, plain text, or HTML | |||
</back> | HTML, PDF, and plain text | |||
--> | ||||
<!-- ##markdown-source: | <!-- [rfced] Please review the "Inclusive Language" portion of the online | |||
H4sIAAAAAAAAA71aa4/byLH9zl/RkIGbMSDp2pPEXo+BRSZjO55kvevr8W7y | Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> | |||
7aJFtqTOUGymmxxZMfzf76mq7ib1sp0vF1hjOVQ/qutx6lQ1Z7NZ0dmuNlfq | and let us know if any changes are needed. Updates of this nature typically | |||
w5sb9cb5je6C0k2lfjM+WNeEQi8W3jx8ZUDlykZvsETl9bKb+bBdzfyyfP7i | result in more precise language, which is helpful for readers. | |||
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= | ||||
Note that our script did not flag any words in particular, but this should | ||||
still be reviewed as a best practice. | ||||
--> | --> | |||
</back> | ||||
</rfc> | </rfc> | |||
End of changes. 77 change blocks. | ||||
451 lines changed or deleted | 410 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |