Session Date/Time: 29 Sep 2023 13:00

RSWG

Summary

The RSWG continued its discussion from the previous session, focusing on the policy for presentation formats, particularly regarding re-rendering, distribution, and stability when tooling or XML source changes. Key points included the necessity of distributing re-rendered documents if the embedded XML changes, the importance of versioning and change transparency, and prioritizing reader needs when providing guidance to the RFC Production Center (RPC). The group decided to defer complex discussions about content changes (Errata) and the IETF's status as a "standards body" versus an "implementation specification business" to first establish policy around presentation and rendering. A consensus emerged that a robust and transparent change record system is critical.

Key Discussion Points

Note Well: The session opened with the standard IETF Note Well reminder.
Continuation from Previous Session: The chair, Pete, summarized the previous session's progress, noting general agreement that RSWG policy should not significantly limit which presentation formats exist or how RPC manages them. However, presentation formats should remain stable even with tooling or XML source changes.
Re-rendering and Distribution:
- There was discussion about whether re-rendering documents (due to tooling or XML source changes) for testing purposes necessitates their re-distribution.
- Paul and Jay indicated that if the XML embedded within a PDF does not match the XML on the RFC Editor's website, it constitutes an error. Therefore, re-rendering must lead to re-distribution.
- John emphasized that even bitwise invisible changes in PDFs create issues for authoritative copies and verification (e.g., bitwise comparison), requiring proper documentation and dating.
Marking and Versioning: A need was identified to properly mark and version presentation formats and the underlying XML source whenever modifications occur, regardless of whether they affect visual presentation.
Focus on Future vs. Existing Documents: Elliot raised a point about dedicating more time to defining the future of RFC documents rather than being "tripped up" by backward compatibility concerns for existing series. Pete acknowledged that backward compatibility issues tend to be more complex.
Reader Priorities for RPC Guidance:
- Paul suggested that when advising the RPC, the primary readers to prioritize are implementers and those writing related RFCs. For these groups, consistency of content is more important than minute visual changes (e.g., line wrapping, page breaks) that might occur from re-rendering. He believes these readers would want robust information about actual content changes (like Errata).
- John countered by advocating for the needs of "librarians," product managers, marketing, and legal professionals, who highly value stability and predictability for reasons related to conformance, liability, and the IETF's role as a "standards body." He argued that disregarding these groups would negatively affect contributions and the perception of RFCs.
- Jay proposed that a "robust and very transparent change system" would largely address the concerns raised by John regarding stability and predictability. Paul agreed this would be beneficial for all user groups.
IETF's Role and WG Scope: A significant discussion arose regarding the IETF's fundamental identity – whether it acts as a "standards body" (implying strict stability) or primarily an "implementation specification business."
- Paul argued that this fundamental question is outside the RSWG's charter, which is to deal with the existing RFC series.
- John maintained that as long as the IETF identifies as a "standards body," the WG is constrained by the implications of that status, and decisions incompatible with it would be out of scope.
- The chairs confirmed that while the WG cannot unilaterally change the IETF's status, it should listen to input from stream heads and the IESG on reader priorities.
Separation of Concerns: Pete clarified that the current discussion focuses on changes to rendering engines or XML source that might produce different presentation (e.g., visual layout), intentionally excluding content changes like Errata for now, as those are a "much bigger can of worms." Paul strongly supported deferring Errata discussions until presentation policy is established.
Principles for Change (Jay's further thoughts): Jay elaborated on the need for principles regarding:
- Frequency of Change: How often should something like a PDF change, and what expectations does that set?
- Authoritative Version: Whether HTML is becoming the "expected authoritative rendered version" due to its less noticeable changes compared to PDFs with many versions.
- Thresholds for Change: What level of change (e.g., two spaces vs. one after a period) warrants re-rendering or distribution?
- Publishing No-Change Updates: Whether confusing users by publishing when nothing has visually or bitwise changed. Pete indicated a general agreement on slower changes.

Decisions and Action Items

Decision: The working group will postpone explicit discussions on content changes (e.g., Errata) and the broader question of the IETF's "standards body" status versus "implementation specification business" until policies regarding presentation and re-rendering are further developed.
Action Item: Pete will write up a summary of the discussion from today's session and the previous one and circulate it to the mailing list.
Action Item: Martin Thompson is encouraged to revise his draft based on the discussions.
Action Item: Paul offered to propose specific wording for guidance to the RPC regarding reader priorities for rendering and re-rendering.
Action Item: Pete and Russ will continue to work on summarizing and synthesizing the discussion points for the working group.

Next Steps

The working group will continue to discuss the summarized points and potential draft revisions on the mailing list, aiming to establish a consensus view on re-rendering policies and guidance to the RPC.
Further discussions on "what XML Source changes are acceptable" and how they should be implemented (including for old RFCs) will likely be initiated on the mailing list. Depending on progress, an interim meeting or discussion at the next IETF may be scheduled for this topic.
The issue of "normative form" (e.g., whether PDF or HTML is considered authoritative) has been identified as a future topic for the queue.