Tables in specifications, and looking back (was: Specifying a state machine: ASCII-based languages)
On one minor note...
Tables are a possible solution (if the machine is finite). But most
people find them too low-level.
I have just returned from about three days of fairly intense conversations
about one of our current BOF topics, that
- would have been a lot easier to have, if the use cases and concepts drafts
had been organized using tables, and
- would be a lot easier to report back to the BOF community, if I could
conveniently use tables to organize the material I want to present.
Of course, some of our specifications do contain tables, but they aren't as
useful in our specifications as in other environments, because of things
like a limited number of columns.
I was keeper of the tables that went into
ftp://ftp.rfc-editor.org/in-notes/rfc2757.txt as Section 5, which I thought
was about as good a presentation as we could do in an ID/RFC, and I remember
that the tabular format was used extensively during early discussions,
before we even came to IETF to do this work (who still living remembers
"Mobile Network Computing Reference Specification"/MNCRS?)
This specification was a very early report on some of the topics that were
presented in http://www.ietf.org/rfc/rfc3150.txt Section 3,
http://www.ietf.org/rfc/rfc3155.txt Section 3,
http://www.ietf.org/rfc/rfc3449.txt Section 7 actually did use a tabular
presentation, and I think it's reasonably good, given the current
http://www.ietf.org/rfc/rfc3481.txt Section 4.10 also used a tabular
presentation that would have been clearer if we'd had more columns to work
with (note that whether the recommendation is for sender, receiver, or both
is "folded" into the text comment column, but would have been clearer in its
own column - but we had the page width issue).
(I note that several of the PILC specifications contained equations of
approximately the complexity we've been discussing, which reminds me that
the current toolset was usable for our needs there, however much we might
benefit from better equation support).
... and, having looked back, I wonder if it would be worth adding a EDU Team
tutorial on "ways we've done things in RFCs that have worked well". A fair
amount of discussion in this and related threads has reflected (IMO) a split
between people who have learned "what not to do" in IDs/RFCs, so don't feel
the constraints, and people who don't have that experience, so who do feel
the constraints of the same toolset.
If there is little/no energy or determination to do much about the current
toolset, it might be more productive to help find usable paths than to
criticize wandering through minefields. Entertaining as watching people
wander through minefields might be, it does become monotonous.
Ietf mailing list