URLs for RFCs and more (sigh!) on HTML RFCs (long)

["James E. [Jed] Donnelley" <[e-mail]>]

Bob Aiken <[e-mail]> writes:

>I have found many occasions just recently where I would
>liked to have had an RFC URL to put in a document referencing
>the reader to an appropriate RFC on a number of topics.

While I do generally believe that it would be valuable to
have RFCs available in HTML, there is certainly no problem
generating URLs for ASCII (or even PostScript) RFCs.
I find PostScript awkward technically, but the ASCII works
just fine, e.g.:

http://ds.internic.net/rfc/rfc1714.txt

and

http://ds.internic.net/rfc/rfc1714.ps

I just argue that by providing the opportunity to have an:

http://ds.internic.net/rfc/rfc1714.html

we add some communication value at negligible
cost.  The value we add is ease of including cross
references in the RFC itself and the ability to
include easily browsable graphics.  I think it might
be reasonable to suggest (for space reasons?) that
ASCII and EITHER PostScript or HTML (or neither
or course) be provided but not both.  In any case
I believe that making HTML available as an alternative
has value and little cost.

When Vernon Schryver <[e-mail]> writes:
...
>There is no need for a revolution.  Evolution is far more gentle and
>produces far better results in such areas as this.  Wait for the
>evolution from ASCII and Postscript to HTML.
...

I agree with his arguments that HTML is immature and will
likely undergo change.  But I still don't understand the
value in waiting.  The ASCII is there for archive.  Postscript
is available for those that believe it contributes value
in formatting and is more permanent.  Why not allow
HTML as an alternative to add the communication values
noted above?  I don't believe there will be an evolution from
ASCII and PostScript to HTML.  I believe that all of these
formats contribute value and will be around for many
years to come.  Waiting will not help in my opinion.

When Vernon further writes:

>OK.  Let's require that all future RFCs be submitted in the HTML
>generated by the new authoring tools recently announced by my
>employer.  (I'm joking.)

OK - a joke, but the important point is that nobody is suggesting
that RFCs be REQUIRED in HTML (or Postscript) at all.  I am
arguing that HTML is a valuable alternative format that should
be included as an option now.  Even if the HTML files have
no stylistic standards at all I believe a value is contributed.
If HTML form RFCs do contribute value, people will use
the format to provide that value.  In that case stylistic
standards, storage conventions, etc. will be developed
among those that make use of this opportunity.  Anyone not
making use of this opportunity should not be injured and
may choose not to produce HTML RFCs or look at them (as
I do now generally with PostScript).

Shouldn't we be hearing from the maintainers of the archives
about the cost/benefit tradeoffs of allowing for another
alternative format?  I think the values are pretty clear.
Are there costs besides storage (generally less than that
required for PostScript)?  In terms of archival value,
providing the HTML option does nothing to limit the
archival value of the ASCII.  I personally believe that there
is enough pressure on HTML upward compatibility that
even today's HTML 2.0 files will be readable and
hypertext linkable into the future.  However even if
they aren't, what is lost by providing the alternative
now?

As far as that goes, what is to stop somebody from generating
HTML versions of RFCs now?  Is the only problem that none of
the "official" archives will store them?  Why not?  If I was
working on an RFC now I would certainly generate an HTML
version - even if it wasn't "official".  Are people doing this?
Is the issue that none of the archives want to store the
HTML forms?

There is a technical/administrative issue in that if parts of
an HTML RFC are included as separate files (e.g. gifs) there
must be some place to store them and link to them.
This seems pretty simple (e.g. include a named sub directory
for such links).  If that is an issue, it can simply not be allowed
for now.  In fact it might be reasonable not to allow any
links except to other RFCs (at least to begin with).  But for
that matter, what is the problem if the HTML is unconstrained.
If there isn't value contributed people won't use the option
or others, wanting to get maximum use of the added
value, will push for standards.  In any case something
of value has been contributed by those that choose to
make use of the opportunity.  Is it technical/administrative
issues like these that are really the barrier to entry here?
I think we should get on with dealing with these issues.
I see no reason to wait.  The basic issues will continue
to be there.  By moving forward now those that choose to
can contribute to this transition process in addition to
providing more valuable RFCs.

Even something as simple as allowing HTML RFCs that use
<pre> </pre> to look exactly like their ASCII equivalent
but with relative URLs to ASCII (or if available HTML)
RFC references would contribute some minor value in my opinion.

I put a version of RFC 1417 in:

http://www-ks.rus.uni-stuttgart.de/atp/rfc/rfc1714.html

that follows this minimalist approach if anyone is interested
in looking at it.  There were some minor interesting issues
involved that can be seen fairly easily by searching
for "RFC".  However, it only took a few minutes to generate.
Also my references were absolute rather than relative
(since I didn't want to store the referenced URLs as well
for this example).

I also printed out the PostScript version of this RFC.  Aside
from variations in page breaking (rendering page references
ambiguous) and font usage and other minor variations, the
documents appear identical.  I am not sure what page
breaking contributes to RFCs in any case.  Many is the time
when I printed out an RFC only to find that the page
breaks didn't line up with my pages (have others had
this experience?).

Perhaps a more important issue is getting this discussion
off of this list.  Is there an interest group dealing with
this issue outside the [e-mail] mailing
list?  I just think we should get on with it.

--Jed  Stuttgart - http://www-atp.llnl.gov/atp/jed.html