]> ICANN

paul.hoffman@icann.org

Internet-Draft This document updates RFC 7990 by changing the word "canonical" to "definitive" and defining what it means to the series. It also updates RFC 7990 by defining the relationship of the publication formats to the series and the expectation of archiving both the definitive and publication formats of RFCs. A policy governing how the RFCXML format changes is described. An open question for the RSWG is whether this document should be an update patch to RFC 7990 (which is the current form of the document) or a complete rewrite done to obsolete RFC 7990. This draft is part of the RFC Series Working Group (RSWG); see https://datatracker.ietf.org/edwg/rswg/documents/. There is a repository for this draft at https://github.com/paulehoffman/draft-rswg-rfc7990-updates. Issues can be raised there, but probably should be on the mailing list instead.

Introduction defines a framework for how RFCs would be published after that document was published, including new formats and a new "canonical format" for archiving RFCs. It talks about "the XML file" as if there will only be one XML file for an RFC because this was the expectation at the time was published. It also talks about "publication formats" as the versions of HTML, text, and PDF versions derived from the canonical format. The first RFC to be published using the group of RFCs described in was , published in October 2019. In the time since then, all published RFCs have followed the general plan from . After extensive experience with publishing RFCs in the RFCXML format (defined in , it has been decided that an RFC's XML file can be updated for narrowly limited purposes. This document updates in a few significant ways: It changes the phrase "canonical format" to "definitive version" and defines the use of the definitive version in the series. It changes the phrase "publication format" to "publication versions" and defines the use of the publication versions in the series. It defines a policy governing how the RFCXML format changes. It defines a policy for when the definitive version of an RFC can be updated and older versions archived. It defines a policy for when the publication versions of an RFC can be updated and older versions archived. This document explicitly does not update the other documents referenced in .

Updated Definition of "Canonical Format" and "Archive" Section 3 of defines the canonical format as:

• Canonical format: the authorized, recognized, accepted, and archived version of the document

This paragraph in is replaced with:

• Definitive version: the authorized, recognized, accepted, and most recent version of the document published by the RFC Editor

Section 5 of says:

• The final XML file produced by the RFC Editor will be considered the canonical format for RFCs; it is the lowest common denominator that holds all the information intended for an RFC.

This wording does not take into account later changes to the definitive version. As noted in , "publication formats may be republished as needed". XML format errors, and better design choices, have been discovered by the community since the first RFCs were published using the RFCXML format. As the RFC XML format of a document changes, publication formats can change, even if this might not result in observable differences. Similarly, as production tools change, publication formats can be regenerated to ensure a consistent presentation across the series. Publication formats and the contexts in which they are displayed can optionally provide additional details of the specific RFCXML version that they were generated from, or provide a means to discover alternative renderings. In order to allow the RFC Editor to publish new definitive versions and associated publication versions of RFCs, Section 5 of is replaced with:

• The definitive version produced by the RFC Editor is the version that holds all the information intended for an RFC. The RFC Editor may change the definitive version of an RFC over time to incorporate changes in the RFCXML format.

• The RFC Editor will keep archived set of all definitive versions of RFCs as well as archived sets of the publication versions for an RFC that were published. These archived sets must be available using the same access methods as for the XML and the published publication formats. Every archived set shall record the date that a document was created or revised.

• This document does not specify how archives are maintained or how archived RFC might be located or identified.

[[[ The paragraphs immediately above specifies policy for updating publication formats. There is not yet consensus in the RSWG about whether that should or should not be policy. ]]]

Rationale The format for published RFCs is RFCXML . Historically, the published version of an RFC has been immutable. says "Once published, RFC Series documents are not changed." The RFCXML format is not able to address use cases that were not originally anticipated during its design. It might also be possible to improve the format to better capture meaning. Though it might be possible to evolve the format and only use the new format for the publication of new RFCs, this would mean that there would be no single format across the series. Tools that seek to process RFCXML would need to understand all iterations of the format.

Syntax Change Policy The RFC Series Working Group (RSWG), constituted by , acts as custodian for the RFCXML format. If the RSWG reaches consensus, they can propose a revision to . The RSWG can publish RFCs in the Editorial stream that describe how the RFCXML format changes. An updated XML format is used for the publication of new RFCs. Some time after the publication of an update to might be necessary to implement changes in tools and active documents. Existing RFCs can be updated to use the new format. The RFC that describes format changes can also describe how the XML of existing RFCs could be updated. Updates to the RFCXML format that are applied to existing RFCs should preserve to the greatest extent possible the semantics expressed in the original RFC. The goal of limiting changes only to syntax is to preserve the semantic meaning encoded in the RFC XML document. This process does not require that updates to RFCXML avoid all risk of introducing semantic changes to existing RFCs. Instead, it only requires that the RSWG carefully consider the potential for semantic changes, take steps to understand the risk of a semantic change (either deliberate or inadvertent), and to limit those risks.

Reasons for Updating the XML Files The XML file can be updated for the following limited reasons: The XML vocabulary, originally defined in , changes An error is discovered in the format XML for an RFC Existing RFCs can be updated to use the new format. The RFC that describes format changes can also describe how the XML of existing RFCs will be updated. The intent behind limiting changes to syntax and XML errors is that the goal is to preserve the semantic meaning encoded in the RFC XML document. [[[ The above sets a new policy. Another option is to say that the policy will be set later. ]]] During the development of this document, many other reasons for updating the XML file were suggested. Those reasons are not in scope for this document, and may be adopted later after the community has experience with the updating mechanisms described in this document.

Archived Documents When the RFC Editor archives documents, it does so in a manner that allows them to be found by people who want the historical (as compared to current) versions of those files. This document does not specify how archives are maintained or how archived RFC XML might be located or identified. The methods for storage and access will be determined by the RFC Editor in consultation with the technical community.

IANA Considerations This document has no IANA considerations.

Security Considerations This document has the same security considerations as . Those are:

• Changing the format for RFCs involves modifying a great number of components to publication. Understanding those changes and the implications for the entire tool chain is critical so as to avoid unintended bugs that would allow unintended changes to text. Unintended changes to text could in turn corrupt a standard, practice, or critical piece of information about a protocol.

The RSWG are responsible for managing the risk of semantic changes that would affect the interpretation of existing and future RFCs. Changes to content that has security implications would have security-relevant consequences.

Acknowledgments Martin Thomson wrote a great deal of the significant text here as part of draft-thomson-rswg-syntax-change. This document has greatly benefitted from the input or the RSWG. In particular, Alexis Rossi, Brian Carpenter, Eliot Lear, Jay Daley, John Levine, and Pete Resnick, gave significant input on the early drafts of this document.

In order to improve the readability of RFCs while supporting their archivability, the canonical format of the RFC Series will be transitioning from plain-text ASCII to XML using the xml2rfc version 3 vocabulary; different publication 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. This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749. This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables a modem to use DLEP messages to pause and resume data traffic coming from its peer router. This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). In addition, various responsibilities of 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 document establishes the Editorial Stream for publication of future policy definition documents produced through the processes defined herein. This document obsoletes RFC 8728. This document updates RFCs 7841, 8729, and 8730.

Advice on Regenerating Publication Formats This document does not include specific guidance regarding the generation of publication formats from the RFCXML source for the definitive version of an RFC. Decisions about how to maintain publication formats are not a matter governed by policy as specified in . This appendix contains advice and considerations for the process of regeneration that came out of discussions of the policy changes in this document. Changes to the RFCXML for existing RFCs might result in changes to the documents rendered from that XML. At the same time, the tools used to generate renderings are under active maintenance. Making it possible for a fresh rendering to replace existing publication formats is a goal supported by the policy changes in this document. This creates a risk that a rerendered documents change in unexpected ways when they are regenerated. This risk of unintentional change can be managed by implementing validation processes: Tools can be continuously checked by producing renderings for existing RFCs. Any change in the rendered document can then be compared with previous outputs and validated. This will ensure that changes in tooling are deliberate and understood. When a change to the XML format occurs, rendered documents can be regenerated and any change in the rendering can be validated. Validation should be aided by automated tooling that is able to disregard inconsequential changes in renderings, like changes in timestamps and other annotations. Validation of tooling can be continuous, for which automation is essential. The decision to make renderings available as the publication format for an RFC is a decision that can be made on a case-by-case basis. Making fresh renderings available more often could mean a greater risk that people seeking to read RFCs will obtain a copy that contains accidental errors. However, errors in publication formats might persist if they are not replaced as tool quality and reliability improves. Old copies of replaced publication formats will be retained to provide the ability to isolate changes and understand the evolution of documents.