Hello Brian, others,
On 2025-05-11 05:30, Brian E Carpenter wrote:
Hi all,
Actually I agree with Martin. I think there's a gap in the style guide,
because the principle that diagrams are illustrative rather then
normative should be clearly stated, and that is orthogonal to SVG vs
ASCII art. (It should have been stated in RFC 2360/BCP 22, but that's an
IETF document.)
As far as I can see, this is a stronger principle than the W3C principle
"Provide text alternatives for non-text content" [1]. It's saying that
the text is normative and the diagram is not.
Yes indeed. Web Content Accessibility Guidelines (WCAG) in general and
"Provide text alternatives for non-text content" [1] in particular apply
to Web pages in general, of which only a very tiny percentage are
"normative" in any sense of the word.
Regards, Martin.
[1] https://www.w3.org/WAI/standards-guidelines/wcag/glance/
Regards
Brian Carpenter
On 10-May-25 18:51, Martin J. Dürst wrote:
Hello Alexis, others,
On 2025-05-10 06:44, Alexis Rossi wrote:
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).
Of course one can. It may be less compact, but will be more accessible
if done right. If anybody thinks that's not the case, please provide an
actual example.
So I propose to leave the text below as is (OLD).
Regards, Martin.
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
--
Prof. Dr.sc. Martin J. Dürst
Department of Intelligent Information Technology
College of Science and Engineering
Aoyama Gakuin University
Fuchinobe 5-1-10, Chuo-ku, Sagamihara
252-5258 Japan
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
