[rfc-i] Problems and requirements for RFC Format
"Martin J. Dürst"
duerst at it.aoyama.ac.jp
Mon Apr 23 18:34:34 PDT 2012
On 2012/04/24 6:11, Iljitsch van Beijnum wrote:
> On 23 Apr 2012, at 9:01 , Martin J. Dürst wrote:
>> So what does the above mean for graphics? Just about the same, except that we don't use "read" when we look at graphics, but that's a detail. Otherwise, the activities are quite similar. So I don't think there will be such a big problem. In other words, our ability to detect, and react to, complexity and inconsistency isn't really that much text-bound.
> No, there are several differences. First of all, discussions use words so in discussions we can quote and suggest text. Doing the same for images is much harder.
There may be cases were it's indeed difficult, but proposing to use a
circle rather than a rectangle, to draw a line thinner or thicker, to
have an arrow go the other way, and so on, are not that difficult.
> Second, using words is second nature to us humans. Maybe not the English words used to specify protocols,
Yes, and maybe not English in the first place. My guess is that drawings
may help people who are not fluent in English quite a bit.
> but it's still words and we all know how to work with those. Not so much for images, which may mean different things to different people
We definitely should avoid these!
> and many of us may not be able to create useful ones,
Then just don't create any. Nobody is saying that in the future, every
RFC has to have at least one drawing.
> and it can be hard to judge what will be clear to others.
From all the text in I-Ds that I have read over the years, the same
problem exists for text :-(.
> So unless we are prepared to hire graphics designers who do this for a living, the quality of free form images will be much more variable than that of text.
I agree with this in terms of low-level "graphical style". But I don't
think that a graphics designer will be better at drawing the right
*state transition* diagram than a protocol designer.
> (Of course there are many constrained types of images such as header diagrams or state transition diagrams.)
Yes. And it's probably mostly these that will get used.
>> But on the other hand, ruling out graphics from the start because some of them are bad seems a bad idea.
> Once again, non-normative images in a PDF or PS version are allowed TODAY. Hardly anyone bothers to make them.
To some extent, I think this is because a lot of specs don't need
images. To some extent, I think it's because creating good diagrams is
work (writing good text is also work, and I guess many people would
avoid that if they could :-). And last but not least, it's because many
people don't know there's the PDF/PS option, and even those who do know
that the PDF/PS files are rarely looked at, and so on.
More information about the rfc-interest