[rfc-i] Illustrations, graphics, and normative-ness
Iljitsch van Beijnum
iljitsch at muada.com
Thu Apr 26 13:08:40 PDT 2012
On 26 Apr 2012, at 20:34 , Joe Hildebrand wrote:
> There are several special cases for diagrams that we've talked about.
> - Packet descriptions: these can be done as tables in HTML (start:
I have no idea what I'm supposed to do with that link, for sure there are no examples of header diagrams there.
The trouble with HTML tables is that they don't degrade well, and also that the use of tables is an invitation to massage the contents to fit a particular display size, often at the expense of other possible display sizes.
I think it makes more sense to adopt a formal syntax for header diagrams and then come up with tools to derive image and text representations as desired. These diagrams are very straightforward, it should be simple enough to specify them formally in a format that is still sufficiently human readable.
> - State transitions: these can be done graphviz, with the source as alt text
> in HTML, although I've gotten to the point as an implementer where I prefer
> a nice table such as that in RFC6121, appendix A.2.1
> - Sequence diagrams (like above): these can be done in a manner similar to
> websequencediagrams.com (modulo branding and licensing issues), with the
> source as the alt text.
No opinion at this time...
> I would be fine with all of those being normative. However, I'm concerned
> about the accessibility of normative "plain" images that don't fall into one
> of these sorts of special cases.
As I've said before, the current rules allow for the use of non-normative images. Perhaps all we need is an easier way to display those when possible/desired, which should be simple enough with HTML as the format. Once people actually start using this option we can revisit the issue of making images normative.
>> We currently have an illustration (to use the term loosely) that anyone with ASCII capability can decipher. If we allow for normative illustrations in one or more image formats without a mandatory ASCII version then we are moving up the system requirements for implementing an RFC significantly.
> We disagree about "significantly".
Apparently we do.
>> And don't forget: not only the technical system requirements, but also the human system requirements.
> I have not forgotten that. I believe you are overstating the issue, and are ignoring the fact that lots of other SDOs use non-text illustrations and the implementers have absolutely no problem with them.
How many other SDOs have 32-year-old standards that are freely available for download in (a | their original) format that is largely workable today?
It's easy enough to come up with something that works well today, but predicting what will work well in the future is hard. The future keeps surprising us, both in good and bad ways. We really need to be careful here. Although the formatting / pagination is becoming an issue, the use of simple text has served us well for 40 years so I think it makes sense to keep that as a base and only allow more complex stuff as optional, non-normative extras. Maybe even just in the beginning until we can be sure that these new things work well.
More information about the rfc-interest