[rfc-i] Illustrations, graphics, and normative-ness

Joe Hildebrand jhildebr at cisco.com
Thu Apr 26 11:34:43 PDT 2012


On 4/26/12 11:18 AM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:

> On 26 Apr 2012, at 17:05 , Paul Hoffman wrote:
> 
>>   Initiator                         Responder
>>   -------------------------------------------------------------------
>>   HDR, SAi1, KEi, Ni  -->
>> . . .
>>                                <--  HDR, SAr1, KEr, Nr, [CERTREQ]
> 
>> I consider that illustration to be normative. If I update the document in the
>> future when there is a non-text graphics format so that this appears with
>> solid lines and arrows, I would expect graphic to be normative.
> 
>> Do others agree? Disagree?
> 
> 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. And don't
> forget: not only the technical system requirements, but also the human system
> requirements.
> 
> I don't think that's a good idea.
> 
> But there are many avenues to explore for less normative better looking
> graphics. See some of my earlier messages.

There are several special cases for diagrams that we've talked about.

- Packet descriptions: these can be done as tables in HTML (start:
https://github.com/hildjj/pdu2html)

- 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.

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.

-- 
Joe Hildebrand



More information about the rfc-interest mailing list