[rfc-i] Illustrations, graphics, and normative-ness
jhildebr at cisco.com
Thu Apr 26 15:47:14 PDT 2012
On 4/26/12 2:08 PM, "Iljitsch van Beijnum" <iljitsch at muada.com> wrote:
>> - 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.
Like I said, it's just a start. It's pretty bog-standard python, so you
could have downloaded the code and generated the tables. But I just checked
in the outputs. Since I don't know how to make github server up an HTML
directly from the repo, I've copied one of them here:
I just took the typical wikipedia look and feel and made it easy to
> The trouble with HTML tables is that they don't degrade well,
Using links on the above URL seems to degrade fine for me.
> 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.
This is a QA issue.
> 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.
That's possible as a future enhancement. The syntax I picked for pdu2html
is probably not interesting enough to get all of the cases that people want,
but I don't want to sign up to produce a complete answer and get it
> It's easy enough to come up with something that works well today, but
> predicting what will work well in the future is hard.
I'd be willing to bet you $10k in 2012 US Dollars on longbets.org that more
than one piece of mainstream software will be easily able to read today's
carefully-formatted HTML in 2044.
I disagree that current line-printer format works well today.
> The future keeps surprising us, both in good and bad ways.
> We really need to be careful here.
I agree. But "careful" != "opposed to any change".
I see a careful, sober, practical approach that uses HTML.
> 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.
Of *course* we have to test what we do before we deploy it. But that
doesn't mean that we can't move forward.
The current format is irrevocably broken. It has been for at least 10
years, and probably closer to 15. Attempts to convince me otherwise and
fight for the status quo have so far not been successful, as far as I'm
More information about the rfc-interest