Session Date/Time: 28 Sep 2023 21:00

RSWG

Summary

The RSWG session focused on the stability of RFC formats, particularly the interplay between the authoritative XML source and various presentation formats (e.g., HTML, PDF). The discussion revolved around the extent to which presentation formats can and should change, the implications of re-rendering, and the working group's role in setting policy versus operational practices. A general consensus emerged favoring an incremental approach to allow changes for error correction and enhancement in presentation formats, while distinguishing these from semantic changes to the XML. There was also a strong desire to frame policy from the consumer's perspective, rather than solely the producer's.

Key Discussion Points

Note Well: The chair reminded participants of the IETF Note Well in effect for the session.
Initial Questions Framework: Pete's initial hypothetical questions regarding re-rendering prompted discussion. Jay and Joel noted that the questions, while thought-provoking, felt framed from a "producer's" rather than a "consumer's" perspective, potentially leading to misdirected discussions.
XML vs. Presentation Format Stability:
- Martin's initial proposal focused on XML stability, considering presentation formats as day-to-day readability that might not require the same level of stability.
- Ecker asserted that people primarily consume presentation formats, not the raw XML, making their stability important. He posited that the notion of XML as the sole authoritative version is "applied fiction" and hypothetical defects in rendering would be seen as issues with the rendered content.
- Rich questioned whether HTML5 could become the definitive version of an RFC instead of XML, which was noted as a significant policy change requiring a new RFC and broad community buy-in.
Re-rendering and Change Management:
- Alexis emphasized that re-rendering of access formats (not XML) is already done and necessary for error correction, accessibility updates, and presentation enhancements. She believes dating versions of these formats can mitigate concerns.
- Jay categorized reasons for changing presentation formats: 1) error in underlying XML, 2) error in the specific rendering, 3) deliberate enhancement unique to that rendering (e.g., adding metadata). He suggested these reasons drive the frequency of changes.
- Ecker introduced a spectrum of changes: bit-for-bit identical, non-semantic rendering changes (e.g., page breaks, punctuation fixes), content changes not affecting semantics (e.g., author names), and semantic changes. He suggested a line could be drawn at various points for what's permissible, with current policy being highly restrictive.
Working Group Scope and Incrementalism:
- Martin raised the question of whether RSWG should set policy for rendering or leave it to the RPC (RFC Production Center), providing only broad guidance. His interpretation of RFC 7990.x was that rendering decisions largely fall outside the WG's direct purview.
- Joel concurred that the WG should largely remain hands-off on rendering policy, provided the XML content remains the definition of the RFC. He added that the WG shouldn't micromanage RPC testing procedures.
- Elliot supported broad guidance but suggested the WG initially review significant changes to gain operational experience with the new structure and processes. He strongly advocated for an incremental approach, starting with smaller changes and gradually expanding scope as experience is gained.
Risks and Testing of Re-rendering:
- Jay described re-rendering as a "high-risk operation" due to the difficulty of automatically verifying correctness and the potential for introducing undetected bugs (e.g., missing content). He suggested it should be avoided unless necessary.
- Joel echoed this, stating the community shouldn't be "beta testers" for rendering changes, and claims of avoiding technical debt by re-rendering are unfounded if full verification isn't possible.
- Ecker differentiated between re-rendering for testing and publishing re-renders. He suggested continuous integration should re-render all RFCs against previous versions to detect unintended changes, which is standard software engineering practice (like web browser regression testing). This testing wouldn't necessarily lead to republication but would ensure tools are stable. If changes are detected, they must be examined.
- Elliot noted that if automation can reliably spot de minimis changes, many concerns would be alleviated.

Decisions and Action Items

There were no formal decisions made, but a strong sense of those present indicates the following:
- The group generally agrees that presentation formats can and should be changed for reasons such as error correction, accessibility, and non-semantic enhancements.
- The working group's role is primarily to provide broad guidance on policy for the stability of RFC formats, leaving detailed operational and testing practices to the RPC.
- Any changes to policy regarding RFC format stability or the canonical representation should be approached incrementally to build operational experience.
- The distinction between re-rendering for internal testing/regression and re-rendering for republication is important.

Next Steps

Continue the discussion in the follow-up session (tomorrow at 1300 UTC).
Further refine the common understanding of what constitutes "good" stability and permissible changes in RFC formats.
Consider how Martin's draft might be revised to incorporate the principle of incremental change and operational learning.
Chart a path for potential future policy changes, starting with easily manageable steps and gradually addressing more complex scenarios.