[rfc-i] Graceful degradation is key, was: Re: draft-hildebrand-html-rfc

Martin Rex mrex at sap.com
Wed Jul 18 12:47:33 PDT 2012

Julian Reschke wrote:
> Martin Rex wrote:
> >
> > Could we please stop the pointless parts of this discussion?
> >
> > Try to get down to requirement that are *INDEPENDENT* from xml2rfc
> > does or could do.  xml2rfc contains lots of meta-data, and can be
> > extended to carry even more meta-data.
> >
> > What meta-data is necessary to create a HTML-page that floats
> > is an entirely distinct question.  The requirements for a
> > submission format must be modeled on the minimum meta-information
> > that is necessary to create the desired output formats.
> > ...
> ...and other information needed in the IETF publication process. That 
> includes programmatic extraction of author names, email addresses, and 
> abstract (submission tool!).

That is such a total non-problem.  There already are several thousand
documents, and there are perfectly operational algorithms (that are far
from rocket scient) to extract this information from the existing documents,
and it would be trivial and perfectly reasonable to use formatting
rules for future documents that ensure these existing algorithms will
continue to work.

It should be easy for a human to "extract" this information from
a 72colx56lines printout of the document, so it will be trivial
for software to do this.

> > Similar for the graphics bikeshedding.  Any graphics must be optional.
> > So if another document author takes over a document (I-D or RFC), but
> > doesn't have support for some graphics format in his authoring tools,
> > he should be OK to leave out the graphics from his revisions of the
> > document.  But that only works if the original document is complete
> > without the graphics in the first place.
> Following that argument we should also forbid esoteric source formats 
> that make it hard to take over the *text* content of a given document.

You're trying to mount the bridle on the wrong end of the horse.

The meta-information that is obvious and clearly recognizable from
one of the "simple" output formats is all that ought to matter
(to readers and other authors).

This is why maintaining the 72col/56ln output format is so important.
Besides being readable in pretty much all computing environments in
existence, tools like rfcmarkup, rfcdiff and NroffEdit reauthoring
feed on it. It is the only format that is guaranteed to be available
for all existing documents.


More information about the rfc-interest mailing list