[rfc-i] Now tell me how to communicate this as effectively in plaintext

Olaf Kolkman olaf at NLnetLabs.nl
Thu Apr 26 02:05:45 PDT 2012

I planned to stay silent on this discussion, but there are a few things that I want to observe, or even take a position on.

* A picture says more than a thousand words.

What a commonplace indeed.

But even if an illustration doesn't say more than prose I believe that it can help readers by guiding them through text. There is a reason why TCP/IP was illustrated with state diagrams.

Observing that there is a trend of authors and readers of RFCs towards less and less native English speakers the utility of an illustration should not be underestimated. While not normative, illustrations might help preventing misinterpretations.

We do not spend the time, collectively or through the RFC Editor, to improve prose. The fact that there is some bashing of a text written by somebody who I consider a native (albeit Oxbridge) speaker is illustrative that writing good prose is difficult.

* Use the best tool for the job.

Without claiming to know what the best tool for broad common use I think that ASCII is high on the stack for appropriateness for graphics.

I do not think that a Conté ink pen with India ink, which is my preferred way of graphical expression, is appropriate either.

* Consistency in look and feel of graphics and illustrations

Regardless of the technical format that we converge to. I would like us to have a consistent look and feel for the series. Does that mean that we will have an illustrator that turns all pictures into a consistent style? Do we develop a style guide for illustrations? Do we offer a library of common graphical elements (such as routers, clouds, and users)?

We can argue about ASCII all we want, but at least it provides a consistent style.

Illustrations are probably as expensive as words, and producing good graphics needs skills that may, just as good literary skills, be hard to get within the IETF.

All in all I think the ability to illustrate is a strong requirement. But I also think the streams and the RFC Editor should be extremely conservative in allowing illustrations and only allow them if they are: non-normative, add clarity, and are sparsely used. Taking Philips document as an example; some (most? I don't have a strong opinion) of the pictures do not add much but some illustrations help the reader.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120426/271a9c8d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: E-mail-Signature-NLnetLabs-smaller.png
Type: image/png
Size: 11929 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120426/271a9c8d/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20120426/271a9c8d/attachment-0001.sig>

More information about the rfc-interest mailing list