Hello, Trying to sum up where I think we are on this:
1. We have new wording for the next draft, "Normative descriptions in documents (for example, definitions of protocols, formats, or system architectures) must be fully represented in the text of the RFC, and must not be contingent on the comprehension of SVG diagrams." [1] which addressed Russ's initial concern about vague/repetitive wording. 2. However, the more recent discussion has raised concerns about whether one can normatively define packet structure without relying on imagery (making this technology less accessible to people with print disabilities). If making a decision on point #2 is a longer discussion to be had on rfc-interest, for the sake of progress on SVGs I propose that we change the language from OLD "SVGs may be included in RFCs to help explain a concept more clearly, but cannot be the only representation of that concept. Normative descriptions of concepts - which might include protocols, formats, or system architectures - must be fully represented in the text of the RFC, and must not be contingent on comprehension of any SVG. SVGs are never to be considered as specifications in themselves." NEW "SVGs may be included in RFCs to help explain a concept more clearly, but cannot be the only representation of that concept. Normative descriptions of concepts - which might include protocols, formats, or system architectures - should be fully represented in the text of the RFC whenever possible, and should not be contingent on comprehension of any SVG. SVGs are never to be considered as specifications in themselves." Would that change address the concerns of Michael and Brian? Alexis [1] https://github.com/alexisannerossi/id-svgsinrfcs/blob/main/svgsinrfcs.md On Wed, May 7, 2025 at 2:29 PM Brian E Carpenter < brian.e.carpen...@gmail.com> wrote: > On 08-May-25 00:26, Paul Hoffman wrote: > > Is this the right mailing list for the discussion of what is normative > in an RFC? I assume it should instead be in rfc-interest, but that it just > started here as a corner case of the wording first quoted in the thread. > That wording could instead be removed, and the eventual document about what > art means could update this RFC. > > I think that for an initial discussion, rfc-interest is a good place to > start, although it also has an IETF aspect. > > Brian > > -- > rswg mailing list -- rswg@rfc-editor.org > To unsubscribe send an email to rswg-le...@rfc-editor.org >
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
