[rfc-i] Does the canonical RFC format need to be "readable" by developers and others?

Martin Rex mrex at sap.com
Fri Jul 6 10:54:48 PDT 2012


Julian Reschke wrote:
>
> Martin Rex wrote:
>> ...
>>> No, it just shows that it's very hard to heuristically detect
>>> indentations, list items, and artwork.
>>
>> Nope, it isn't hard at all.
>> and the heuristics that rfcmarkup uses are anything but rocket science.
>> 
>> The solution doesn't have to be perfect, mind you.
> 
> If it only works something like 90% of the time, using the output will 
> quickly get annoying. Luckily, we don't have to when the source RFC 
> exists in a more expressive format.

You're missing the point.  For all *NEW* documents, it would be easy
to ensure that the heuristics will work 100% of the time.

For all *EXISTING* documents, there simply is no other choice
unless you intend to re-edit each an every revision of an I-D ever
submitted as TXT and each RFC ever published without the meta-information
that you're looking for.


> 
> > There are several thousand documents out there for which there simply
> > is no alternative to doing just that -- if one really cared about
> > rendering them differently from how they're rendered now.
> > But very obviously, nobody really cares about solving the problem
> > how to render what is there differently.  Instead, what I'm seeing
> > here is significant amount of lobbying to kill an existing submission
> > format and several user-friendly existing authoring tools along with it.
> 
> Believe me, I do care a lot. To the point that I have converted most of 
> the historic RFCs I need to xml format.

I was more thinking of "caring" in the terms of caring about *others*.
Such as making an alternative html-ized version accessible online
(preferably via tools.ietf.org), or distributing app(lication)s that
can more reasonably render on handheld gadgets/fondleslabs the formats
that are currently available.

The brokennes of currently available handheld gadgets is mindboggling.
20 years ago, computers had 8-bit CPUs with 1Mhz clock and somewhere
between 8-KByte and 32-KByte memory, and were already able to do a lot
of other things in addition to rendering ASCII reasonably with that
few resources.

Today we have smartphones with 32-bit CPUs, >200Mhz clocks and
512MByte+ memory, and they utterly fail with the trivial task to
render ASCII reasonably.  Looks like a serious QA problem to me.


-Martin


More information about the rfc-interest mailing list