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

Phillip Hallam-Baker hallam at gmail.com
Fri Apr 27 04:36:06 PDT 2012


This is a circular argument. You argue that because people have
successfully sandbagged changes to the spec since Postel died that it
has 'staying power'. The British monarchy lasted much longer in the US
than the RFC format but that didn't mean people were happy with it.
The same is true of slavery and herpes and the Berlin wall.

Thatcher was so attached to the Berlin wall that she begged Gorbachev
to send in the tanks to stop it falling two months before it fell. She
would much rather have half a million people in Eastern Europe live in
communist slavery than face the possibility of change.

And as for the person who suggested we were unable to agree on a
format, I see a very good consensus on what an alternative format
should look like.


Postel was more than open to changing the format, I discussed what we
would need to do in HTML 2.0 to make it work with him in Dallas but
the pressing issue at the time was the Network Solutions DNS crisis.


On Fri, Apr 27, 2012 at 3:17 AM, Iljitsch van Beijnum
<iljitsch at muada.com> wrote:
> 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.
> _______________________________________________
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
> https://www.rfc-editor.org/mailman/listinfo/rfc-interest



-- 
Website: http://hallambaker.com/


More information about the rfc-interest mailing list