Session Date/Time: 18 Oct 2023 19:00

RSWG

Summary

The RSWG session focused on the contentious topic of allowing changes to the RFC XML format and associated tooling, particularly regarding whether such changes necessitate retroactive updates to existing RFC XML documents and their republication in various formats. Participants discussed the purpose of RFC XML, the sustainability of large-scale retroactive changes, and the perceived risks and benefits of regenerating and republishing output formats. No consensus was reached, but key areas of disagreement were identified for further discussion.

Key Discussion Points

Session Focus Clarification: The chairs clarified that the discussion's focus was on whether changes to the XML schema and tooling, including bug fixes, are acceptable.
Initial Positive Outlook: Elliot expressed a positive view on the document proposing changes, setting a stretch goal for completion by Prague, and suggesting that a list of issues be incorporated for tracking.
Multiple XML Documents (Jay): Jay proposed considering the possibility of multiple XML documents rather than solely replacement, suggesting an "informational format" approach. Examples included adding Dublin Core metadata or providing versions in different languages, questioning the "always replacing" mindset.
Purpose of XML and Consistency (John): John emphasized that the purpose of XML is to enable more semantic content and support various future rendered versions (e.g., ePub, future reader formats). He argued for maintaining a consistent XML grammar, ideally by retroactively updating older XML documents with mechanical changes. He suggested limiting changes to those that can be automatically updated (e.g., postal addresses, draft names).
Incremental vs. Waterfall Changes (Robert): Robert questioned the idea of tightly coupling grammar changes with republishing all RFCs. He advocated for incremental improvements rather than large, infrequent "waterfall" changes.
Low Concern for XML Changes (Paul): Paul stated that few consumers care about XML changing over time, and for those who do, archiving and diffs suffice. He suggested that PDF is considered a "mime format" compared to HTML for developers.
Binding to the Future (Russ): Russ discussed options for future changes: applying only to new RFCs (e.g., mathematical symbols) or retroactively applying fixes (e.g., address tags). He questioned why the discussion was abstract rather than focused on specific examples.
Sustainability of Retroactive Updates (Jay): Jay raised concerns about the long-term sustainability of retroactively updating thousands of RFC XML documents for every change. He questioned the feasibility of maintaining tools for indefinitely old XML versions and argued against regenerating output formats if the XML change does not affect content, citing the high risk of unintended changes in PDFs.
Stability and Reprinting (Elliot): Elliot suggested borrowing concepts from the publication industry (e.g., printing numbers) for stability. He supported a "crawl, walk, run" approach and using operational experience to guide future decisions. He also distinguished between continuous integration/continuous delivery (CI/CD) for rendering and the act of mass republication.
Promise of PDF Reflecting XML (Paul, Jay, Martin, Julian): A significant point of contention was whether changing the XML without regenerating and republishing the PDF output breaks an implicit "promise" that the PDF accurately reflects the XML.
- Paul strongly disagreed with editing PDFs without regeneration, considering it "horribly risky" and a breach of promise.
- Jay argued against regeneration due to the high risk and difficulty of formally verifying that nothing else changed in complex formats like PDF.
- Julian strongly advocated for always regenerating and republishing everything when XML changes to detect breakage early and prevent technical debt, likening it to dependency management in software. He cited past V2-V3 changes (lists, tables) that required conversion.
- Martin agreed with Paul on the low risk associated with PDF changes and disagreed with Jay's "zero tolerance" approach, suggesting tools can manage the risk.
New Rendering Formats (Pete): Pete asked what a new output format (e.g., audiobook) implies for XML: recreating tools for old XML, generating only for new XML, or adjusting old XML to support a single toolchain.
Pragmatic Approach (John): John suggested a pragmatic, two-stage approach:
1. In the short term, fix existing grammar mistakes and mechanistically update all existing XML to a clean, extensible 3.1 version.
2. Going forward, allow backwards-compatible additions to the grammar without requiring re-rendering or changing old XML, as has been done historically. A more significant V4 might be needed much later.
RFC 7990 Update Options (Paul, Martin): Paul and Martin discussed three ways to update RFC 7990:
1. Full rewrite and replacement (Paul's preference, despite the work, to provide a clear, current understanding given past confusion).
2. Specific text patches (Paul's initial approach, but deemed incomplete).
3. A new document describing specific changes and stating its authoritative nature where it disagrees with 7990 (Martin's preference).

Decisions and Action Items

No formal decisions were made regarding changes to the XML or publication process.
Action Item: The chairs (Russ and Pete) will formulate a specific question for the mailing list, ahead of the Prague meeting, to gauge the group's feeling on the principle of whether all publication formats must always be regenerated and republished when the underlying XML changes. This aims to clarify whether there is a fundamental disagreement on this principle or merely on the circumstances and policy of its application.
Action Item: Martin volunteered to create a list of issues related to the RFC 7990 updates for discussion.

Next Steps

The chairs will post meeting notes to the mailing list, along with a specific question for further discussion, to better prepare for the Prague meeting.
The discussion on RFC XML changes, retroactive updates, and republication will continue at the Prague IETF meeting.