RFC-HTML Issues Page

Back to RFC-HTML Development Page.
This is a summary of we have decided, know, or understand about the RFC-HTML effort. Each issue section has one or more positions attached to it. Names of listmembers are attached to the positions.

In the propositions below, please bear in mind the distinction between a submission format (what RFC authors would send the RFC editor), an archive format (what the RFC editor keeps to generate HTML, ASCII, PDF, Postscript, etc.), and an HTML distribution format (what the RFC editor will make available on the Web).

The date on each proposition is either that of origin or the last time the majority position changed.

"Neutral" is an acceptable position.

GOALS

G1 (30 Jul 1997): Our overall goal is to define RFC submission, archive, and distribution formats (and a set of support tools) which will facilitate making HTML distribution of RFCs routine and effective.

Pro: This is the list charter. If you don't accept this, what are you doing here? :-)

G2 (30 Jul 1997): Our goals should include RFC-HTML to ASCII translation good enough so that flat-ASCII could be replaced as a submission and archiving format (though not as a distribution one).

Pro: esr, rob
I'm awaiting a proposition on internationalization support as a goal.

G3 (30 Jul 1997): Ease of writing RFCs should be a significant consideration in the design of the submission format.

Pro: dan
(Dan has not registered a reason.)
Con: esr, Chris.Newman, rob
Writing RFCs should not be too easy; requiring some competence filters out idiots.

RFC-HTML

S1 (30 Jul 1997): The subset of HTML described in the validator spec for RFC-HTML is an appropriate HTML distribution format.

Pro: esr, moore, Chris.Newman, rob
S2 (30 Jul 1997): Allowing IMG tags for PNG images should be recorded as a "possible future direction" for RFC-HTML.

Pro: esr, dan, rob

TABLES

T1 (30 Jul 1997): Tables are a good thing and we should support them if technically possible.

Pro: esr, dan, moore, rob
Tables are a valuable device for describing many things in RFCs that aren't expressed well in text narrative.
Con: wildfire
Anand Kumria cites concerns about blind peoples' access to tableiferous documents.

T2 (30 Jul 1997): Tables can be added to the RFC-HTML spec.
Pro: esr
All the world has Netscape; Lynx is significant mainly as a converter-to-ASCII and its lack of tables support can be made up by a preprocessor.
Con: dan
If we respect access from the developing world as a goal, we have to assume a significant population of Lynx-only web users.

AUTHORING

A1 (30 Jul 1997): This group should ignore HTML generator issues in designing a submission format (that is, the capabilities of tools such MS Word, SGML-tools and off-the-shelf HTML editors should not constrain the submission format design).

Pro: esr, Chris.Newman, rob

ANCHORS

N1 (30 Jul 1997): URNs aren't here yet and may never get here; therefore they cannot be a factor in the design of submission, archiving or distribution formats.

Pro: esr
The only special case we really want is RFC references; those can be detected in the submission format and automastically turned into URLs in the presentation format.
Con: rob
Rob Earhart advocates that we should plan what to do in case URNs happen.
N2 (30 Jul 1997): We don't have to have any provision for marking references to entire RFC URLs in the submission format.

Pro: esr
They can be generate automatically in the distribution format.
Con: rob
(I don't yet understand Rob's reasoning.)

Eric S. Raymond <esr@snark.thyrsus.com>