On 21 May 2026, at 9:58, John Levine wrote:
It appears that <[email protected], [email protected]> said:
Internet-Draft draft-rswg-rfc7997bis-10.txt is now available. It is a
work
item of the RFC Series Working Group (RSWG) Editorial Stream Working
Group of
the IETF.
Title: Text in RFCs
Author: Paul Hoffman
Name: draft-rswg-rfc7997bis-10.txt
I should have mentioned this nine revisions ago, but it seems to me
that a lot
of this document only applies to the Line Printer Memorial text
format, not HTML
or PDF renderings. The latter two load the fonts they use, so if
xml2rfc can
create the HTML and PDF, browsers and PDF viewers can display them.
I think you're going to have to point out examples other than the two
below that constitute "a lot", because I'm not seeing it.
There are certainly issues of strange characters that are likely to
confuse
people, but the bit in section 2 about "People whose systems do not
have the
fonts needed to display part of a particular RFC" or section 3 about
"many
[characters] whose ability to be displayed is debatable" don't make
sense in
HTML or PDF versions of RFCs.
This is the bit where Klensin is spot on. There are definitely ranges of
characters for which font distribution to assorted OSes and browsers is
at least delayed and often non-existent (Latin Extended-G [1] being the
previously cited example, which was produced in 2021 but still has no
support in MacOS or in Firefox AFAICT) which would count as "not
hav[ing] the fonts needed" or "whose ability to be displayed is
debatable". So I don't think your evaluation is correct, and I don't
think a change to the text is needed.
Pete
[1] Perhaps your browser will do something better with
https://en.wikipedia.org/wiki/Latin_Extended-G that will make it look
more like https://www.unicode.org/charts/PDF/U1DF00.pdf, but on the most
updated version of MacOS with the latest versions of Safari and Firefox,
I can't see them.
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
