[rfc-i] Illustrations, graphics, and normative-ness
hallam at gmail.com
Fri Apr 27 04:08:58 PDT 2012
There are two issues with 'normative'
1) Is it necessary to be able to read the diagram to implement the spec
2) Which text should govern in the case of inconsistency.
On the first, I think the arguments made for caveman format are
ludicrous. The caveman format is far harder to read and get to display
properly on modern devices than any of the image formats suggested.
Even if this was not the case, I have no problem in requiring people
to have access to a machine that is at least as capable as a One Per
Child laptop or a Kindle. At present the only machine I can use to
comfortably work on RFCs is workstation class.
I don't think the second is anything more than a theoretical issue.
Any inconsistency in the text of an RFC can lead to divergent
implementations as can any ambiguity. That is why I generate examples
from code that is locked to the specification being described in a way
that minimizes room for error. Even though examples are not normative
I know that they are going to be used as test vectors in practice so
they have to me treated as if they are.
Misinterpretation due to inconsistency is just as bad as
misinterpretation due to ambiguity but inconsistency is more likely to
be reported in early implementation. So I am really not very worried
The only reason I ever bother with ASCII scribble today is because
people ask for them to make the document more readable. I find that
they do the opposite in ASCII art format. But people demand them. We
did some in the DKIM deployment guide which I think only confuse in
ASCII art format but would definitely help most readers in a
On Thu, Apr 26, 2012 at 10:44 PM, John Levine <johnl at taugh.com> wrote:
>>Do others agree? Disagree?
> This whole argument seems pretty pointless to me if the graphics can't
> be normative. There are some things that lend themselves to
> presentation as pictures, e.g., state diagrams as boxes and arrows
> rather than tagged items with a list after each item of the tags of
> the items that can follow.
> To cross threads a little, there are some people who would like
> followup reports to experimental RFCs. The report we're working on
> has some tables of numbers. The current tables are pretty small, but
> if they were any bigger, it sure would be nice to have some graphs to
> visualize them. See Tufte for why high density high data graphs are a
> good thing.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest