**Session Date/Time:** 08 Nov 2022 13:00

# rswg

## Summary

The rswg session focused on two main topics: the future of SVG diagrams in RFCs and the definition and evolution of the RFC XML format, particularly in light of divergences from RFC 7991. Discussions highlighted the need for a re-evaluation of current SVG restrictions, a clear baseline for the "as-is" XML format, and a robust process for future format changes, balancing backward compatibility, tooling requirements, and archival considerations.

## Key Discussion Points

*   **SVG Profile (RFC 7996) Review and Future:**
    *   **Current Issues:** The existing SVG profile (RFC 7996) is highly restrictive, leading to poor tool compatibility and difficulty for authors. Many common SVG features (e.g., markers, complex fonts, `width`/`height`/`viewBox` interactions) are problematic. Security concerns were raised regarding embedded JavaScript.
    *   **Proposed Direction:** There was general consensus that RFC 7996 should be re-evaluated or even obsoleted. The group agreed to define explicit requirements for SVG in RFCs, including considerations for archivability, accessibility, safety (no scripting), and complexity limits, rather than a narrow prescriptive grammar.
    *   **Accessibility:** Emphasis was placed on leveraging existing accessibility guidelines and ensuring that RFC text remains the normative component, with diagrams serving a supplemental role.
    *   **External Standards:** The idea of asking W3C to define a "safe" (script-free) SVG profile was raised to ensure broader applicability and maintainability.

*   **RFC 7991 bis "as is" Document:**
    *   **Purpose:** This document aims to describe the current RFC XML format as it is implemented by tools, acknowledging its divergence from RFC 7991.
    *   **Publication Debate:** Significant discussion centered on whether this "as is" document should be published as an RFC or maintained as a living working document. Arguments for RFC publication included memorializing a baseline and soliciting broad community input, while arguments against highlighted the inefficiency of RFCs for rapidly evolving or frequently updated specifications.
    *   **Accuracy & Validation:** Concerns were raised about the accuracy of the current "as is" draft and the effort required to validate it against existing implementations, given past divergences and numerous bug fixes.
    *   **Archival Implications:** The need to document the format for the over 1000 RFCs published since 7991 (which do not strictly adhere to it) was stressed, noting that this documentation is crucial for long-term archival.

*   **RFC Format Evolution (Paul Hoffman's 3.1 Proposal):**
    *   **Proposed "3.1" Version:** A proposal was made for a "3.1" version of the RFC XML format, representing a consensus-driven desired state that addresses known "bad ideas" in the current implementation and potentially reintroduces useful features from 7991 that were dropped.
    *   **Process for Change:** This would involve an explicit comparison (diff) between 7991, the "as is" state, and the desired "3.1" state, with item-by-item review and group consensus.
    *   **Versioning and Semantics:** The importance of clear XML versioning (e.g., an attribute) was highlighted so that processors can unambiguously identify the grammar and semantics. A major version change (e.g., 3 to 4) should be reserved for semantic breaks.
    *   **Avoiding Feature Creep:** A strong caution was voiced against adding new features during the "3.1" consensus-building process, to ensure timely completion.
    *   **Backward Compatibility:** The constraint of maintaining backward compatibility for future format changes was discussed, with some suggesting this makes immediate "as is" publication less critical, while others argued that some critical changes (e.g., full names) might require breaking compatibility and cannot wait for a full "3.1" process.

## Decisions and Action Items

*   **Decision:** No immediate decision was made regarding the publication of the "as is" document as an RFC. This point will require further discussion.
*   **Action Item:** John Levine will finalize the initial meeting notes and circulate them to the mailing list for corrections.
*   **Action Item:** The Chairs (Ecker and Martin) will synthesize the key discussion points, particularly the conflicting views on the "as is" document and format evolution, and present an issue summary on the mailing list.
*   **Action Item:** The Chairs will initiate further discussion on the mailing list to determine a clear path forward for defining and evolving the RFC XML format.
*   **Action Item:** The Chairs will explore the need for interim meetings to accelerate progress and will assess what resources (e.g., from the RSAB or tool teams) might be necessary.
*   **Action Item:** The Chairs will investigate mechanisms for the group to address and make decisions on non-emergency policy issues related to the RFC format that fall outside the immediate purview of the RSAB or standard RFC publication cycles.

## Next Steps

*   Further discussion on the mailing list to establish detailed requirements for SVG in RFCs and to refine a strategy for defining and evolving the RFC XML format.
*   Consideration of a "living document" model, potentially using a GitHub-driven approach similar to other IETF working groups, for managing the format specification.
*   Prioritize and address specific urgent format changes (e.g., the representation of author names) in parallel with the broader format evolution work, while carefully managing potential compatibility impacts.