]> RFC Series Consulting Editor

rsce@rfc-editor.org

RFC Publication Formats This document assigns responsibility for implementation decisions for RFC publication formats (currently HTML, PDF, and TXT), the CSS file, and SVG files to a tools implementation team and the RPC. It assigns responsibility for defining high level design requirements for the RFC publication formats, CSS, and SVG files to the RSWG. This document updates RFC7992, RFC7993, RFC7994, RFC7995, RFC7996 and RFC9280. This document makes no changes to the RFCXML format described in RFC7991 or subsequent documents. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction The intent of this document is to allow the implementation decisions for RFC publication formats to evolve without requiring the publication of new RFCs. High level design requirements for publication formats are determined by the RFC Series Working Group (RSWG), but implementation decisions will now be made by a tools implementation team and the RFC Production Center (RPC). The difference between design requirements and implementation decisions are addressed in the next section. This document specifically does not change anything about the definitive RFCXML format described in or subsequent documents. We expect changes to the HTML and PDF publication formats in the future to allow accessibility improvements and to update the design of RFC "info" pages after a planned redesign of rfc-editor.org. This document also allows for other publication format implementation changes that may arise for other reasons, including the creation of new publication formats. The tools implementation team and the RPC are expected to abide by the design requirements set out by the RSWG, to seek expert input before making any changes to the publication formats, and to take community needs, recommendations, and requests into account. The tools implementation team will maintain public documentation of the currently implemented formal grammar and any other rule sets related to the publication formats, as well as a public space for implementation updates (these may be the same space). They will also maintain a public mailing list for discussion. Changes to the implementation of publication formats will be announced via appropriate public mailing lists, as determined by the tools implementation team and the RPC.

Relation to RFC 7990bis RFC7990bis obsoletes , which contained some requirements for RFC publication formats. RFC7990bis does not specify implementation details that affect RFC publication formats, so that document does not affect the decisions in this RFC.

Changes to RFC 7992 Section 2 of provides high level design requirements for the HTML format. These requirements remain in effect. Sections 3 through 9 of RFC7992 provide implementation decisions for the HTML publication format. These are now considered to be recommendations from the community, and will be treated as such by the implementers of the HTML publication format in the future.

Changes to RFC 7993 Sections 2 and 3 of provide high level design requirements for the CSS file. These requirements remain in effect. Sections 4 through 7 of RFC7993 provide implementation decisions for the CSS file. These are now considered to be recommendations from the community, and will be treated as such by the implementers of the CSS file in the future.

Changes to RFC 7994 outlines requirements for the TXT publication format. This document is now considered to be implementation recommendations from the community, and will be treated as such by the implementers of the TXT publication format in the future. It is not expected that there will be much change to the TXT publication format over time, but if any changes are needed extra care should be taken as those changes may affect tools used by the author community.

Changes to RFC 7995 outlines requirements for the PDF publication format. This document is now considered to be implementation recommendations from the community, and will be treated as such by the implementers of the PDF publication format in the future.

Changes to RFC 7996 outlines requirements for SVG files. This document is now considered to be implementation recommendations from the community, and will be treated as such by the implementers of the SVG tools in the future. It is recommended that the RSWG define the design requirements (not implementation details) for SVGs in a future RFC in consultation with technical and accessibility experts. Until that time, the RPC may choose at their discretion to continue to view some elements of RFC7996 as requirements if needed. For example, we expect that SVGs will be black and white only until or unless that is specifically changed by new design requirements.

Changes to RFC 9280 Section 4.4 is updated to reflect the additional responsibility for resolution of publication format implementation and tooling disagreements. The title of Section 4.4 of RFC 9280 is currently: This document replace that title with: The first paragraph of Section 4.4 of RFC 9280 is currently: This document replaces that paragraph with: An additional bullet point is added to Section 4.4 of RFC 9280 that states:

Design Requirements vs Implementation Decisions This document makes a distinction between high level design requirements and implementation decisions. The line between these may not be obvious, so this section tries to describe that difference. Sections 1.2 and 1.3 of this document provide examples of that line being drawn. In both cases, the high level design requirements are written entirely as prose (no markup language or code is used) and are meant to guide the implementation decisions made in subsequent sections of those documents. The implementation decisions are characterized by specifying particular tags to be used, or the values of those tags, the order in which the tags must be used, etc. As a specific example to illustrate this difference further, we can look at . Section 2 lists a high level design requirement for the HTML this way: "All sections, subsections, figures, and paragraphs should have stable numbered link anchors. Additionally, anchors expressed in the source XML should be exposed as anchors in the HTML output as well." Section 5.2 of that same document is a description of implementation decisions that are meant to satisfy the design requirement.

Community Participation in implementation of publication formats The community is invited to participate in the implementation of RFC publication formats. As of this writing, the tools implementation team currently uses a mailing list at tools-discuss@ietf.org and Github at https://github.com/ietf-tools for communication and implementation, but may move to another public space as needed in the future. The RSWG may decide in the future to establish a more formal design team or other mechanism to provide community input to the tool implementors.

Security Considerations Changes to the publication formats of RFCs introduce risk. A risk is that unintended changes could occur in publication versions of an RFC as a result of an unintentional bug. 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. However, nothing in this document changes the definitive RFCXML format, so risk is limited to the publication formats and versions. The tools implementation team and the RPC are expected to identify, track, and actively mitigate risks introduced by this policy.

IANA Considerations This document has no IANA actions.

References Normative References In order to meet the evolving needs of the Internet community, the canonical format for RFCs is changing from a plain-text, ASCII-only format to an XML format that will, in turn, be rendered into several publication formats. This document defines the HTML format that will be rendered for an RFC or Internet-Draft. The HTML format for RFCs assigns style guidance to a Cascading Style Sheet (CSS) specifically defined for the RFC Series. The embedded, default CSS as included by the RFC Editor is expected to take into account accessibility needs and to be built along a responsive design model. This document describes the requirements for the default CSS used by the RFC Editor. The class names are based on the classes defined in "HTML for RFCs" (RFC 7992). In 2013, after a great deal of community discussion, the decision was made to shift from the plain-text, ASCII-only canonical format for RFCs to XML as the canonical format with more human-readable formats rendered from that XML. The high-level requirements that informed this change were defined in RFC 6949, "RFC Series Format Requirements and Future Development". Plain text remains an important format for many in the IETF community, and it will be one of the publication formats rendered from the XML. This document outlines the rendering requirements for the plain-text RFC publication format. These requirements do not apply to plain-text RFCs published before the format transition. This document discusses options and requirements for the PDF rendering of RFCs in the RFC Series, as outlined in RFC 6949. It also discusses the use of PDF for Internet-Drafts, and available or needed software tools for producing and working with PDF. This document specifies SVG 1.2 RFC -- an SVG profile for use in diagrams that may appear in RFCs -- and considers some of the issues concerning the creation and use of such diagrams. 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. Informative References 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. 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.

Acknowledgments The planning and work that went into the creation of RFC7992, RFC7993, RFC7994, RFC7995, and RFC7996 was invaluable and will continue to be the basis of how publication formats are created moving forward. Thank you to the authors and editors of these documents: Heather Flanagan, Joe Hildebrand, Paul Hoffman, Tony Hansen, Larry Masinter, Matthew Hardy, and Nevil Brownlee. Also, thanks are owed to the RFC Format Design Team for their efforts: Nevil Brownlee (ISE), Tony Hansen, Joe Hildebrand, Paul Hoffman, Ted Lemon, Julian Reschke, Adam Roach, Alice Russo, Robert Sparks (Tools Team liaison), and Dave Thaler.