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>