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

Iljitsch van Beijnum iljitsch at muada.com
Fri Apr 27 00:17:47 PDT 2012

On 27 Apr 2012, at 0:47 , Joe Hildebrand wrote:

> http://cursive.net/spdy-syn-stream.html

I don't like some of the choices made here (the numbers on the left side are confusing), but I can see how something like this could work well. However, the size is hardcoded, so I don't think this would work much better on small screens than what we have today.

>> The trouble with HTML tables is that they don't degrade well,

> Using links on the above URL seems to degrade fine for me.

Yes, I see what you mean. This is better than things used to be. Still, because there are no borders I don't think this leaves the diagram in a usable state.

>> 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 agree with you that HTML is a good candidate for being around for a long time. Hence my support for adopting some form of HTML as the new format for RFCs.

> I disagree that current line-printer format works well today.

It will still display in any browser that has an appropriate font and a wide enough display. I would say that is a success for a 40-year-old format. If we can repeat that with a new format I'll be very happy.

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

Agree with both of these.

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

I have somewhat different take here. Although there are certainly issues with the current format, it does have a number of good properties, such as the fact that it's accessible to anyone with ASCII capability, including simple homegrown tools. So the kid/bathwater thing applies.

On 27 Apr 2012, at 3:34 , Martin J. Dürst wrote:

> Well, moving up the system requirements from something around 1970 or so to 1990 or a bit more MAY be called significant :-). But what really counts is whether present or future systems can handle our stuff, not how well 1980's hardware and software can. We are not a computer museum.

You're right that explicitly supporting hard- and software more than 5 years old is not really a useful goal. However, old stuff that is still around has shown it has staying power so that gives it a leg up over the latest and greatest thing that may or may not disappear in short order.

Also, we have to imagine a world where there are no tools that do what we need, so we have to write our own. That means our formats should be sufficiently simple that that's reasonably possible.

On 27 Apr 2012, at 4:44 , John Levine wrote:

> This whole argument seems pretty pointless to me if the graphics can't
> be normative. 

Allowing graphics to be normative would promote laziness. By having a text description and then an image it's possible to compare the two and see if they portray the same thing. If images are normative then people could just supply an image without text describing the same thing in the same detail and this opportunity for extra consistency checking would be lost, even if we don't care about accessibility issues.

More information about the rfc-interest mailing list