**Session Date/Time:** 28 May 2024 20:00

# [RSWG](../wg/rswg.html)

## Summary

The RSWG session focused on confirming the scope and immediate work products of the group, specifically the two tasks previously outlined by Ecker: completing the documentation of the currently implemented `xml2rfc` tool (Work Product 1) and creating a document of the desired grammar (Work Product 2). There was broad agreement on these two high-level goals. Much of the discussion revolved around the precise definition and scope of Work Product 1, particularly concerning elements present in the toolchain but not necessarily used in published RFCs, and the desire to avoid prolonged debates ("rat holes") that have hindered progress in the past. The chairs committed to providing further guidance and setting a timeline for these tasks.

## Key Discussion Points

*   **Note Taking**: Rich volunteered to take notes for the session.
*   **Confirmation of Work Products**: The chairs started by asking for confirmation on two work products, as described by Ecker:
    1.  Completing documentation of what is currently implemented in the `xml2rfc` tool.
    2.  Creating a document of the desired grammar.
    There was general agreement on these two goals, though some expressed them more as a continuous process rather than discrete products.
*   **Concerns about Work Product 1 (As-Implemented Documentation)**:
    *   **Paul**: Noted that feedback on existing queries revealed elements deemed "not new" or "possible but RPC is not doing it." Expressed concern about re-litigating decisions and asked for a clearer "statement of work" to define "implemented" (e.g., which tools, what output forms).
    *   **Julian**: Acknowledged that participants, including himself, might have tuned out of process discussions, leading to broader feedback when concrete questions were finally posed. Reiterated agreement with the two work items.
    *   **Ecker**: Clarified that Work Product 2 should initially be an intermediate assessment of implemented but undocumented items from RFC 7991 (keep, deprecate, replace) rather than a radical re-architecture of the XML.
*   **Elements In Tool vs. In Publication**:
    *   A significant discussion point was how to handle elements that might be present in the `xml2rfc` tool or used by authors, but are not actually utilized by the RFC Production Center (RPC) for published RFCs.
    *   **Ecker/Paul**: Argued that if the RPC never publishes with an element and there's no intent to, it doesn't "really exist" for the purpose of RFCs and should be removed from the documented grammar.
    *   **Robert**: Suggested documenting such elements in a separate section (e.g., "exist but not used") rather than outright removing them, to avoid harm and provide clarity. Emphasized making it easier to change `xml2rfc` functionality sooner.
    *   **John Levine**: Advocated for Work Product 1 to strictly document "as implemented" without editorial comments, judgments, or opinions. He suggested a "1.5" stage after Work Product 1 to discuss necessary additions, removals, or warnings. He expressed concern that granular debates about what *should* or *should not* be there in Work Product 1 could lead to participants tuning out.
*   **Scope of the Working Group and "Policy"**:
    *   **Paul**: Raised the question of whether the RSWG's "policy" scope includes grammar elements used only by authors (e.g., for drafts, pre-processors) and not directly affecting RFC publication. Requested a clear chair statement on this.
    *   **Julian**: Wondered who would address authoring-specific grammar extensions (e.g., standard formats for binary messages, tracking issues) if RSWG does not, suggesting pre-processors could handle these.
    *   **Alexis**: Proposed that Work Product 1 should document *anything* used in *any part* of the process (authoring, pre-processing, or final publication), clearly noting its specific usage context.
    *   **Paul**: Counter-proposed (disagreeing with Robert and Alexis) creating a *separate mailing list* for discussions on authoring tools and non-RPC-published XML elements. This would allow RSWG to focus Work Product 1 purely on RPC-published grammar, preventing "rat holes" and clarifying the WG's policy scope.
    *   **John Levine**: Agreed with Paul on keeping Work Product 1 purely "as implemented." He further articulated the idea of potentially three distinct "languages": one for authors (for discussion/drafts), one for RPC internal formatting (which should be an RPC problem), and one for the stable, canonical published RFCs.
*   **Publication Form of Work Product 1**:
    *   **Ecker**: Argued against publishing Work Product 1 as an RFC because decisions are not based on consensus. Suggested an authors' page or an RFC that *includes deprecated sections* if commentary is unavoidable.
    *   **John Levine**: Emphasized the need for a *stable* document, regardless of whether it's an RFC, not something continuously tinkered with. If it includes commentary/deprecations, it would align with his "1.5" idea.
    *   **Paul**: Advocated for a stable, date-stamped document that *looks like an RFC* (due to existing tooling) but explicitly states it is *not* a consensus RFC and contains *no commentary* (due to ongoing discovery and lack of consensus).
    *   **Elliot**: Acknowledged the difficulty of achieving consensus for a pure RFC publication for Work Product 1. Prioritized getting the work done over the document's form, leaning towards Paul's suggestion to avoid getting blocked.
    *   **Robert's `prep tool` question**: Asked when `xml2rfc` could stop putting in defaults (e.g., for `docname` bug). Paul clarified that `prep tool`'s current behavior is defined by a published RFC (7998) and therefore constitutes published policy. RPC cannot unilaterally change this; it requires a new policy document or a WG decision.
    *   **Rich**: Suggested RFC 7998 doesn't mandate a specific prep tool instance, implying RPC could change it when ready, and the documentation could follow.

## Decisions and Action Items

*   **Work Product Confirmation**: The working group broadly agreed to pursue the two main work products as described: documenting the currently implemented `xml2rfc` tool, and creating a document of the desired grammar.
*   **Chair Guidance**: The chairs will issue a statement on the mailing list clarifying the working group's scope regarding "policy" discussions, particularly concerning grammar elements used only by authors or pre-processors, and how they relate to the "as implemented" document.

## Next Steps

*   The chairs will review the meeting notes, summarize conclusions, and propose a concrete timeline and action plan (including potential deadlines for Work Product 1) on the mailing list.
*   Further discussion is needed on the exact content and form of Work Product 1 ("as implemented"), specifically regarding how to document elements used in the toolchain but not in published RFCs, and its publication mechanism (e.g., RFC, authors' page, with/without commentary).
*   A process needs to be established for addressing specific changes to `xml2rfc` behavior, such as the `docname` issue, and how these relate to the work products.
*   The chairs will evaluate the need to solicit authors for specific documents or tasks related to these work products.