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

Joe Touch touch at isi.edu
Thu Apr 26 10:05:42 PDT 2012



On 4/26/2012 8:05 AM, Paul Hoffman wrote:
...
>
> Whoa, whoa, whoa. I have been assuming up to this point that we were
> talking about illustrations and graphics as normative parts of the RFC.
> It sounds like I made a bad assumption.

Whenever there are multiple descriptions of the same concept - typically 
one text and one diagrammatic - one is usually selected as normative.

> RFC 5996, a standards-track document, has this:
>
>     The initial exchanges are as follows:
>
>     Initiator                         Responder
>     -------------------------------------------------------------------
>     HDR, SAi1, KEi, Ni  -->
> . . .
>                                  <--  HDR, SAr1, KEr, Nr, [CERTREQ]
>
> I consider that illustration to be normative.

Packet field format diagrams are typically normative.

In this case, the exchange diagram might be normative too.

The key issue is whether there is a separate description in text. When 
there are two descriptions, the text is usually declared as 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.

I would hope an update to this document would more clearly provide a
*protocol* description. A protocol description should always include:

A- endpoint state
B- message definitions
C- rules that govern the transition between state based on message exchange

This document is a good example of very clear "B", but obscure "A" and 
"C" that need to be inferred from diagrams like you cite.

Whether any of the above are done graphically or not, if there are two 
descriptions of the same item, IMO at most one should be declared as 
normative.

Joe


More information about the rfc-interest mailing list