> On May 5, 2025, at 8:55 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> > wrote: > > On 06-May-25 10:19, Russ Housley wrote: >>> On May 5, 2025, at 5:23 PM, Brian E Carpenter <brian.e.carpen...@gmail.com> >>> wrote: >>> >>> On 05-May-25 20:13, Martin J. Dürst wrote: >>>> Hello Martin, Brian, >>>> On 2025-05-05 09:13, Martin Thomson wrote: >>>>> On Mon, May 5, 2025, at 07:10, Brian E Carpenter wrote: >>>>>> How would we feel about the following statement, in a hypothetical >>>>>> draft about ASCII art: >>>>>> >>>>>> "Normative descriptions of protocols, systems, etc. must be fully >>>>>> represented in the text of the RFC, and must not be contingent on >>>>>> comprehension of any ASCII art." >>>>> >>>>> My recollection is that this has been the case for as long as I've been >>>>> involved in putting RFCs together. >>>>> >>>>>> Do we need an exception to the non-normative rule for cases where the >>>>>> SVG is directly equivalent to ASCII art for a PDU? >>>>> >>>>> I don't think so. There are some cases where RFCs have escaped into >>>>> publication without a textual description of the PDU, but I do not >>>>> consider that to be acceptable. It's almost trivial to provide words >>>>> that describe the PDU layout at the same time as the field semantics are >>>>> defined. RFC 791 set a good example there. >>>>> >>>> I agree. Occasionally, ASCII art may be slightly more accessible than >>>> SVG, but it will still require a lot of effort for some blind person to >>>> understand it. In case we haven't required text equivalents for ASCII >>>> art, that's something that we should fix. >>> >>> I was a bit surprised by Martin Thomson's reply because I don't think I >>> have ever seen it written that ASCII art is non-normative. It's not in the >>> style guide as far as I can see. RFC 2360 describes packet diagrams but >>> doesn't clarify their status, and does not state that a textual packet >>> description is *required*: >>> >>> "Most link, network, and transport layer protocols have packet >>> descriptions. Packet diagrams included in the standard are very >>> helpful to the reader." >>> >>> However, the RFC 2360 checklist implies that packet diagrams are desirable: >>> >>> "Does it give packet diagrams in recommended form, if applicable?" >>> >>> I agree that this should be clarified. That's orthogonal to the SVG issue, >>> and probably fits under accessibility. >>> >> Brian: >> I bet you recall this... >> When you were IETF Chair, I was Security AD and my co-AD was Sam Hartman. >> There were several DISCUSS positions that were put on documents that did not >> repeat MUST and SHOULD requirements from diagrams in the body. Sam could >> not get the information from the diagram (ASCII or otherwise). For a blind >> man, Sam had incredible skills, but his text reader could not parse diagrams. > > Right. Sam never failed to amaze me. Anyone can check this by running RFC791 > through a screen reader. It gets really boring when it gets to > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. "Plus dash > plus dash plus dash..." > > But if we're quibbling, RFC 791 lacks any way to tell a screen reader to skip > the diagram, and lacks a sentence something like "We now describe the > components of the header in sequence." After all those "plus dashes" and > associated junk, it just says "Version: 4 bits". > > I fear, despite your and Martin Thomson's comments, that we still have a > major accessibility problem for many existing RFCs, and we need stronger > guidance for the future.
I understand, and I agree that it cannot be fixed quickly or easily. That said, let's have a policy to do better going forward. Russ
signature.asc
Description: Message signed with OpenPGP
-- rswg mailing list -- rswg@rfc-editor.org To unsubscribe send an email to rswg-le...@rfc-editor.org
