rfc9720.original   rfc9720.txt 
Network Working Group P. Hoffman Editorial Stream P. Hoffman
Internet-Draft ICANN Request for Comments: 9720 ICANN
Obsoletes: 7990 (if approved) H. Flanagan Obsoletes: 7990 H. Flanagan
Updates: 9280 (if approved) Spherical Cow Consulting Updates: 9280 Spherical Cow Consulting
Intended status: Informational 6 August 2024 Category: Informational January 2025
Expires: 7 February 2025 ISSN: 2070-1721
RFC Formats and Versions RFC Formats and Versions
draft-rswg-rfc7990-updates-12
Abstract Abstract
In order to improve the readability of RFCs while supporting their In order to improve the readability of RFCs while supporting their
archivability, the definitive version of the RFC Series transitioned archivability, the definitive version of the RFC Series transitioned
from plain-text ASCII to XML using the RFCXML vocabulary; different from plain-text ASCII to XML using the RFCXML vocabulary; different
publication versions are rendered from that base document. This publication versions are rendered from that base document. This
document describes how RFCs are published. document describes how RFCs are published.
This document obsoletes RFC 7990. This document also updates the This document obsoletes RFC 7990. This document also updates the
stability policy in RFC 9280. stability policy in RFC 9280.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the RFC Series Policy Definition
and may be updated, replaced, or obsoleted by other documents at any Process. It represents the consensus of the RFC Series Working Group
time. It is inappropriate to use Internet-Drafts as reference approved by the RFC Series Approval Board. Such documents are not
material or to cite them other than as "work in progress." candidates for any level of Internet Standard; see Section 2 of RFC
7841.
This Internet-Draft will expire on 7 February 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9720.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
1.1. Changes to RFC 7990 . . . . . . . . . . . . . . . . . . . 3 1.1. Changes to RFC 7990
1.2. Changes to RFC 9280 . . . . . . . . . . . . . . . . . . . 4 1.2. Changes to RFC 9280
1.3. Key Changes from the Earlier RFC Process . . . . . . . . 5 1.3. Key Changes from the Earlier RFC Process
2. Definitive Version of an RFC . . . . . . . . . . . . . . . . 5 2. Definitive Version of an RFC
2.1. Updating the Definitive Version of an RFC . . . . . . . . 6 2.1. Updating the Definitive Version of an RFC
2.2. Expected Updates to RFCXML . . . . . . . . . . . . . . . 6 2.2. Expected Updates to RFCXML
3. Publication Versions . . . . . . . . . . . . . . . . . . . . 6 3. Publication Versions
4. Archived Documents . . . . . . . . . . . . . . . . . . . . . 6 4. Archived Documents
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. References
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.2. Informative References
8.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses
1. Introduction 1. Introduction
"RFC Series Format Requirements and Future Development" [RFC6949] "RFC Series Format Requirements and Future Development" [RFC6949]
discussed the need to improve the display of items such as author discussed the need to improve the display of items such as author
names and artwork in RFCs as well as the need to improve the ability names and artwork in RFCs as well as the need to improve the ability
of RFCs to be displayed properly on various devices. Based on the of RFCs to be displayed properly on various devices. Based on
discussions with communities of interest, such as the IETF, the RFC discussions with communities of interest, such as the IETF, the RFC
Series Editor decided to explore a change to the format of the Series Editor decided to explore a change to the format of the
Series. [RFC7990] was the culmination of that exploration. Series. [RFC7990] was the culmination of that exploration.
This document is concerned with the production of RFCs, focusing on This document is concerned with the production of RFCs, focusing on
the published documents. It does not address any changes to the the published documents. It does not address any changes to the
processes each stream uses to develop and review their submissions processes each stream uses to develop and review their submissions
(specifically, how Internet-Drafts will be developed). While I-Ds (specifically, how Internet-Drafts are developed). While I-Ds have a
have a similar set of issues and concerns, directly addressing those similar set of issues and concerns, directly addressing those issues
issues for I-Ds should be discussed within each document stream. for I-Ds should be discussed within each document stream.
The details described in this document are expected to continue to The details described in this document are expected to continue to
change over time as the community and the RFC Production Center (RPC) change over time as the community and the RFC Production Center (RPC)
gains further experience implementing the policies described here. gain further experience implementing the policies described here.
Implementors of those components are advised to avoid assuming that Implementors of these components are advised to avoid assuming that
all such changes will be backwards-compatible. all such changes will be backwards compatible.
1.1. Changes to RFC 7990 1.1. Changes to RFC 7990
[RFC7990] defined a framework for how RFCs would be published after [RFC7990] defined a framework for how RFCs would be published after
that document was published, including new formats and a new that document was published, including new formats and a new
"canonical format" for archiving RFCs. It talked about "the XML "canonical format" for archiving RFCs. It talked about "the XML
file" as if there would only be one XML file for an RFC because that file" as if there would only be one XML file for an RFC because that
was the expectation at the time [RFC7990] was published. It also was the expectation at the time [RFC7990] was published. It also
talked about "publication formats" as the versions of HTML, text, and talked about "publication formats" as the versions of HTML, text, and
PDF derived from the "canonical format". PDF derived from the "canonical format".
skipping to change at page 3, line 46 skipping to change at line 133
* It defines a policy for when the definitive version of an RFC can * It defines a policy for when the definitive version of an RFC can
be updated and older definitive versions archived. be updated and older definitive versions archived.
* It defines a policy for when the publication versions of an RFC * It defines a policy for when the publication versions of an RFC
can be updated and older publication versions archived. can be updated and older publication versions archived.
When using the new terminology, it is important to note that When using the new terminology, it is important to note that
[RFC7990] used the term "canonical format" to mean two very different [RFC7990] used the term "canonical format" to mean two very different
things. Quoting from RFC 7990: things. Quoting from RFC 7990:
Canonical format: the authorized, recognized, accepted, and | Canonical format: the authorized, recognized, accepted, and
archived version of the document | archived version of the document
and and
At the highest level, the changes being made to the RFC format
involve breaking away from solely ASCII plain text and moving to a | At the highest level, the changes being made to the RFC format
canonical format that includes all the information required for | involve breaking away from solely ASCII plain text and moving to a
rendering a document into a wide variety of publication formats. | canonical format that includes all the information required for
| rendering a document into a wide variety of publication formats.
This document uses two terms, "definitive version" and "definitive This document uses two terms, "definitive version" and "definitive
format", for the earlier term "canonical format". format", for the earlier term "canonical format".
Other terminology changes made by this document are the following: - This document also makes the following terminology changes:
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).
Historical text from [RFC7990] such as Section 2 ("Problem * It changes the phrase "xml2rfc version 3" to "RFCXML".
Statement"), Section 4 ("Overview of the Decision-Making Process"),
and Section 10 ("Transition Plan") were purposely omitted from this * It changes the name of the body that publishes RFCs from "RFC
document. Text from [RFC7990] that repeated what was in other RFCs, Editor" to "RFC Production Center" (RPC).
particularly Section 8 (Figures and Artwork) and Section 9 (Content
and Page Layout) were also removed. Historical text from [RFC7990], such as Sections 2 ("Problem
Statement"), 4 ("Overview of the Decision-Making Process"), and 10
("Transition Plan"), was purposely omitted from this document. Text
from [RFC7990] that repeated what was in other RFCs, particularly
Sections 8 ("Figures and Artwork") and 9 ("Content and Page Layout"),
was also removed.
1.2. Changes to RFC 9280 1.2. Changes to RFC 9280
Section 7.6 of [RFC9280] currently says: Section 7.6 of [RFC9280] says:
Once published, RFC Series documents are not changed. | Once published, RFC Series documents are not changed.
This document replaces that sentence with: This document replaces that sentence with:
Once published, RFCs may be re-issued, but the semantic content of | Once published, RFCs may be reissued, but the semantic content of
publication versions shall be preserved to the greatest extent | publication versions shall be preserved to the greatest extent
possible. | possible.
This document also creates a new policy that would exist in Section 7
of [RFC9280]:
7.8. Consistency This document also adds a new policy to Section 7 of [RFC9280]:
RFCs are copyedited, formatted, published, and may be reissued to | 7.8. Consistency
maintain a consistent presentation. |
| RFCs are copyedited, formatted, published, and may be reissued
| to maintain a consistent presentation.
Section 2.1 and Section 3 in this document are based on this updated Sections 2.1 and 3 in this document are based on this updated policy
policy in [RFC9280]. in [RFC9280].
1.3. Key Changes from the Earlier RFC Process 1.3. Key Changes from the Earlier RFC Process
The first RFC to be published following the guidance of the group of The first RFC to be published following the guidance of the group of
RFCs described in [RFC7990] was [RFC8651], published in October 2019. RFCs described in [RFC7990] was [RFC8651], published in October 2019.
In the time since then, all published RFCs have followed the general In the time since then, all published RFCs have followed the general
plan from [RFC7990]. plan from [RFC7990].
At the highest level, the changes that [RFC7990] made to the RFC At the highest level, the changes that [RFC7990] made to the RFC
format involved breaking away from solely ASCII [RFC20] plain text format involved breaking away from solely ASCII [RFC20] plain text
skipping to change at page 6, line 7 skipping to change at line 230
render the specified publication versions; any question about what render the specified publication versions; any question about what
was intended in the publication will be answered from this file. It was intended in the publication will be answered from this file. It
is self-contained with all the semantic content known at publication is self-contained with all the semantic content known at publication
time. For instance, all features that reference externally defined time. For instance, all features that reference externally defined
input are expanded. It does not contain src attributes for <artwork> input are expanded. It does not contain src attributes for <artwork>
or <sourcecode> elements. It does not contain comments or processing or <sourcecode> elements. It does not contain comments or processing
instructions. instructions.
2.1. Updating the Definitive Version of an RFC 2.1. Updating the Definitive Version of an RFC
RFCs may be re-issued, as described in Section 1.2. Such changes RFCs may be reissued, as described in Section 1.2. Such changes must
must preserve the semantics expressed in the original RFC. Reasons preserve the semantics expressed in the original RFC. Reasons to
to make such changes include updates to the RFCXML schema, errors make such changes include updates to the RFCXML schema, errors
discovered in the XML, and changes to the tooling used to generate discovered in the XML, and changes to the tooling used to generate
the publication versions of the definitive version of the RFC. The the publication versions of the definitive version of the RFC. The
RPC will keep a public record of when it re-issues any RFC, and give RPC will keep a public record of when it reissues any RFC and give a
a short description of its reasoning for each change. short description of its reasoning for each change.
2.2. Expected Updates to RFCXML 2.2. Expected Updates to RFCXML
It is anticipated that [RFC7991] will be updated. Updates to the It is anticipated that [RFC7991] will be updated. Updates to the
RFCXML specification that are applied to existing RFCs should RFCXML specification that are applied to existing RFCs should
preserve to the greatest extent possible the semantics expressed in preserve the semantics expressed in the original RFC to the greatest
the original RFC. The goal of limiting changes only to syntax is to extent possible. The goal of limiting changes only to syntax is to
preserve the semantic meaning encoded in the published document. preserve the semantic meaning encoded in the published document.
This policy does not require that updates to RFCXML avoid all risk of This policy does not require that updates to RFCXML avoid all risk of
introducing semantic changes to existing RFCs. Instead, it only introducing semantic changes to existing RFCs. 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 changes, take steps to understand the risk of a semantic change
(either deliberate or inadvertent), and to limit those risks. (either deliberate or inadvertent), and limit those risks.
3. Publication Versions 3. Publication Versions
The RPC is permitted but not required to re-issue publication The RPC is permitted but not required to reissue publication versions
versions of an RFC, as described in Section 1.2. In deciding whether of an RFC, as described in Section 1.2. In deciding whether to
to update the publication versions of an RFC, the RPC will take into update the publication versions of an RFC, the RPC will take into
account both the risk of semantic changes and consistency of the account both the risk of semantic changes and consistency of the
series. Series.
XML format errors and better design choices have been discovered by XML format errors and better design choices have been discovered by
the community since the first RFCs were published using the RFCXML the community since the first RFCs were published using the RFCXML
format. When the XML in a definitive version changes, the format. When the XML in a definitive version changes, the
publication versions may change, even if this might not result in publication versions may change, even if this might not result in
observable differences. Similarly, as production tools change, observable differences. Similarly, as production tools change,
publication versions may be regenerated to ensure a consistent publication versions may be regenerated to ensure a consistent
presentation. presentation.
4. Archived Documents 4. Archived Documents
skipping to change at page 7, line 16 skipping to change at line 288
in a manner that allows them to be found by people who want the in a manner that allows them to be found by people who want the
historical (as compared to current) files. historical (as compared to current) files.
This document does not specify how archives are maintained or how This document does not specify how archives are maintained or how
archived documents might be located or identified. The methods for archived documents might be located or identified. The methods for
storage and access will be determined by the RPC in consultation with storage and access will be determined by the RPC in consultation with
the technical community. the technical community.
5. IANA Considerations 5. IANA Considerations
This document has no IANA considerations. This document has no IANA actions.
6. Security Considerations 6. Security Considerations
Allowing changes to the definitive versions and publication versions Allowing changes to the definitive versions and publication versions
of RFCs introduces risks. A significant risk is that unintended of RFCs introduces risks. A significant risk is that unintended
changes could occur in either the definitive version or publication changes could occur in either the definitive version or publication
versions of an RFC as a result of an editing error, or may be 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 introduced into a publication version when it is regenerated from the
definitive version. This may result in the corruption of a standard, definitive version. This may result in the corruption of a standard,
practice, or critical piece of information about a protocol, and harm practice, or critical piece of information about a protocol, and harm
to the reputation of the RFC series. to the reputation of the RFC Series.
The RPC is expected to identify, track, and actively mitigate risks The RPC is expected to identify, track, and actively mitigate risks
introduced by this new policy. introduced by this new policy.
7. Acknowledgments 7. References
Martin Thomson wrote a great deal of the significant text here as
part of draft-thomson-rswg-syntax-change.
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.
8. References
8.1. Normative References 7.1. Normative References
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", [RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
RFC 7991, DOI 10.17487/RFC7991, December 2016, RFC 7991, DOI 10.17487/RFC7991, December 2016,
<https://www.rfc-editor.org/rfc/rfc7991>. <https://www.rfc-editor.org/info/rfc7991>.
[RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC", [RFC7996] Brownlee, N., "SVG Drawings for RFCs: SVG 1.2 RFC",
RFC 7996, DOI 10.17487/RFC7996, December 2016, RFC 7996, DOI 10.17487/RFC7996, December 2016,
<https://www.rfc-editor.org/rfc/rfc7996>. <https://www.rfc-editor.org/info/rfc7996>.
[RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in [RFC7997] Flanagan, H., Ed., "The Use of Non-ASCII Characters in
RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016, RFCs", RFC 7997, DOI 10.17487/RFC7997, December 2016,
<https://www.rfc-editor.org/rfc/rfc7997>. <https://www.rfc-editor.org/info/rfc7997>.
[RFC9280] Saint-Andre, P., Ed., "RFC Editor Model (Version 3)", [RFC9280] Saint-Andre, P., Ed., "RFC Editor Model (Version 3)",
RFC 9280, DOI 10.17487/RFC9280, June 2022, RFC 9280, DOI 10.17487/RFC9280, June 2022,
<https://www.rfc-editor.org/rfc/rfc9280>. <https://www.rfc-editor.org/info/rfc9280>.
8.2. Informative References 7.2. Informative References
[RFC20] Cerf, V., "ASCII format for network interchange", STD 80, [RFC20] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/rfc/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format [RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format
Requirements and Future Development", RFC 6949, Requirements and Future Development", RFC 6949,
DOI 10.17487/RFC6949, May 2013, DOI 10.17487/RFC6949, May 2013,
<https://www.rfc-editor.org/rfc/rfc6949>. <https://www.rfc-editor.org/info/rfc6949>.
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, [RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990,
DOI 10.17487/RFC7990, December 2016, DOI 10.17487/RFC7990, December 2016,
<https://www.rfc-editor.org/rfc/rfc7990>. <https://www.rfc-editor.org/info/rfc7990>.
[RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link [RFC8651] Cheng, B., Wiggins, D., and L. Berger, Ed., "Dynamic Link
Exchange Protocol (DLEP) Control-Plane-Based Pause Exchange Protocol (DLEP) Control-Plane-Based Pause
Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019, Extension", RFC 8651, DOI 10.17487/RFC8651, October 2019,
<https://www.rfc-editor.org/rfc/rfc8651>. <https://www.rfc-editor.org/info/rfc8651>.
Acknowledgments
Martin Thomson wrote a great deal of the significant text here as
part of draft-thomson-rswg-syntax-change-01.
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 provided significant
input on the early draft versions of this document.
Authors' Addresses Authors' Addresses
Paul Hoffman Paul Hoffman
ICANN ICANN
Email: paul.hoffman@icann.org Email: paul.hoffman@icann.org
Heather Flanagan Heather Flanagan
Spherical Cow Consulting Spherical Cow Consulting
Email: hlf@sphericalcowconsulting.com Email: hlf@sphericalcowconsulting.com
 End of changes. 41 change blocks. 
111 lines changed or deleted 111 lines changed or added

This html diff was produced by rfcdiff 1.48.