| Internet-Draft | RFCPubFormats | May 2024 |
| Rossi | Expires 15 November 2024 | [Page] |
This document assigns responsibility for the code level implementation decisions for RFC publication formats (currently HTML, PDF, and TXT), the CSS file, and SVG files to the Tools 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, and RFC7996. This document makes no changes to the RFCXML format described in RFC7991 or subsequent documents.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://alexisannerossi.github.io/id-RFCPubFormats/draft-rossi-rfcpubformats.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rossi-rfcpubformats/.¶
Source for this draft and an issue tracker can be found at https://github.com/alexisannerossi/id-RFCPubFormats.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 November 2024.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The intent of this document is to allow the code level implementation of 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 code level implementation decisions will now be made by the Tools Team and the RFC Production Center (RPC). This document specifically does not change anything about the definitive RFCXML format described in RFC7991 or subsequent documents.¶
Changes to the HTML and PDF publication formats are expected in the near future to allow accessibility improvements, and a new HTML version will be used on rfc-editor.org at the RFC “info” pages after a planned site redesign. This document also allows for other implementation changes that may arise for other reasons.¶
The Tools 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 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 the Tools Team mailing list. They may also be announced on the rfc-interest and rswg mailing lists if there are changes that are likely to affect the whole community.¶
RFC7990bis obsoletes RFC7990, which contained some requirements for RFC publication formats. RFC7990bis does not specify code level implementation details that affect RFC publication formats, so that document does not affect the decisions in this RFC.¶
Section 2 of RFC7992 provides high level design requirements for the HTML format. These requirements remain in effect.¶
Sections 3 through 9 of RFC7992 provide more detailed 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.¶
Sections 2 and 3 of RFC7993 provide high level requirements for the CSS file. These requirements remain in effect.¶
Sections 4 through 7 of RFC7993 provide more detailed 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.¶
RFC7994 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.¶
RFC7995 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.¶
RFC7996 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. We expect, for example, that SVGs will be black and white only until or unless that is specifically changed by new design requirements.¶
This document makes a distinction between “high level” design requirements and “code level” 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 the line being drawn between “high level” and “code level.” 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 “code level” 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 RFC7992. 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 more code level description of implementation decisions that are meant to satisfy the design requirement.¶
The community is invited to participate in the Tools Team to work on the implementation of RFC publication formats. This team currently uses the tools-discuss@ietf.org mailing list 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 Tools Team may choose to provide documentation for publication format implementation details at Github or another location.¶
If there is disagreement among the community, the Tools Team, or the RPC about how an RFC publication format is implemented then this is considered a disagreement about interpretation of the relevant policy and should be addressed by the RFC Series Approval Board (RSAB) as set out in RFC9280. The matter should be brought to the RSAB by the RPC and the RSAB will evaluate the issue(s) and follow its processes documented in RFC9280 or subsequent relevant RFCs.¶
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 Team and the RPC are expected to identify, track, and actively mitigate risks introduced by this policy.¶
This document has no IANA actions.¶
The planning and work that went into the creation of RFC 7992, RFC 7993, RFC 7994, and RFC 7995 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, and Matthew Hardy. 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.¶