Tables in specifications, and looking back (was: Specifying a state machine: ASCII-based languages)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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.

Thanks,

Spencer


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]