[rfc-i] discussion about artwork

Nico Williams nico at cryptonector.com
Tue Feb 18 10:14:44 PST 2014

On Tue, Feb 18, 2014 at 11:52 AM, Paul Kyzivat <pkyzivat at alum.mit.edu> wrote:
> The art in some sense is never normative, because it is the text that
> contains normative (MUST) statements. But presumably the text can contain
> normative statements that *refer* to diagrams that are integral to the
> requirement. Are you saying that someone attempting to understand the
> normative aspects of the draft could be *required* to view some
> non-plaintext format? Of must the document be fully understandable without
> reference to the diagrams?

Accessibility concerns dictate the latter.  Artwork must not be
normative in any sense except when the artwork is a rendering of a
description -that is normative and available- whose source is written
a language that can be read (e.g., a UML-type language, a grammar, and
so on).

I realize that we have lots of RFCs with bits-on-the-wire
representations (e.g., IP, TCP, ...), but even there we generally have
legible text to go with the picture that makes the picture not
necessary (e.g., RFC793, figure 3, is accompanied by text that makes
the figure redundant).

I like it this way myself, because I do like reading RFCs on text
terminals (and browsers, yes, but I do a bit of both), so I'd like to
retain text renderings.  And I tend to prefer that as much of a
specification as possible be written in a formal language or ad-hoc
conventions that add enough formality (knowing we can't get to 100%
formality -- that's OK), which means that I can then read the text
rendering and not really require the image.

IMO we shouldn't spend too much time on images.  Let authors and the
RFC-Editor negotiate SVG, ASCII art, any conversions between those, or
plain PNGs vs. no art in text rendering.  To avoid spending much time
on this we should agree that figures are mostly to be Informative,
with exceptions handled on a case-by-case basis.

Oh, incidentally, I think I'd like an option to use Unicode line
drawing characters in ASCII art, especially if the alternative in many
cases is no artwork in text rendering.


More information about the rfc-interest mailing list