Subject: RE: Source Format of RFCs

From: "Herman R. Silbiger" <[email-masked]>
Date: Mon, 30 Nov 1998 22:47:12 -0500

I agree that there is a certain universality about ASCII text.  The problems that you bring up that may be part of using a more modern format capable of figures and tables do exist.  I disagree somewhat with your position regarding the "archival" nature of RFCs that need to be read for decades.  The only true archival format is print on acid-free paper or microfilm, both of which can be produced without difficulty and could always be concerted back into digital format.

I do question why this is so all important to the IETF and not to any other standards organization.  The ITU, ISO, ANSI and most other  standards organizations do not seem to have any difficulty with using a word processor format.

What I miss most in the all text format is the ability to mark and track changes in successive versions of drafts. 

I also have found that many authors actually use word processors to produce drafts and RFCs, having given up their Teletypes some years ago.

Herman Silbiger

----------
From:  Keith Moore [SMTP:[email-masked]]
Sent:  Monday, November 30, 1998 8:28 PM
To:  Bruce Balden
Cc:  Dunlap, Randy; [email-masked]
Subject:  Re: Source Format of RFCs 

> A number of RFC's and drafts, such the ones regarding BGP, suffer negatively 
> from the text-only format. It would be nicer to have a richer format, 
> especially since such documents rarely originate in the text-only format, 
> but are rendered into that format by MS-Word, nroff, LaTeX or whatever.
> 
> Would it be asking too much for all RFC's too made available in some sort 
> of rich format, and in particular their source format since that doesn't 
> require additional work?

You may be asking for far more than you realize.

I agree with you that the ASCII-only RFC format is a bit restrictive.
However, ASCII is amazingly flexible.  It is one of the few formats 
that can be reasonably viewed (or searched) on any computer, and
printed on any printer.  Neither of these is true of the document 
formats associated with common word processors.  Also, since it is 
so simple, ASCII is a good choice for formatting documents that may 
need to be readable for many decades.  For comparison, word processor 
documents from the early 1980s are difficult to read today, and
it's not difficult to imagine that today's word processor documents
will be difficult to read ten or twenty years from now.

(The more complex the document format, the less interoperable it is.
There have been problems with PostScript RFCs because some tools
produce PostScript that cannot be printed on some printers.
Similarly, version X of FooWord may produce documents that cannot
be read by version Y of FooWord.)

There are also problems with making RFCs available in multiple formats.
One is that the RFC Editor and Internet-Drafts folks would then need
to deal with a wider variety of tools.  Another is that multiple formats
can make it more difficult to keep the various formats in sync.
For instance the RFC Editor generally needs to be able to make minor 
changes to a document before publication, yet may not have the 
tools neded to modify the "source" document.  If the author is asked
to make the changes, there is then a need to make sure that the
author does not make other modifications to the work after it has 
been reviewed and approved by a working group and IESG.  Again, 
this generally requires special tools.

Until a new format can supplant ascii text for all intents and purposes,
there will continue to be a need to produce ascii text versions of RFCs.
Many word processors do a very poor job of producing "RFC ASCII"
(with margins that allow printing on both A4 and US-Letter paper, 
no overprinting, and so forth)  Documents written for a wysiwyg 
word processor are often difficult to read as ASCII, e.g. because 
the word processor will try to put too many words on a line, or too
many characters in a column of a table. (I've seen various versions 
of this while reviewing RFCs for IESG.)

Then there is a need to make sure that new RFC formats are adequately
supported by all of the RFC and internet-drafts mirrors.

For some time I have been interested in exploring the use of HTML
for RFCs and Internet-Drafts.  This would provide several advantages,
including multifont and multi-faced text in a variety of sizes,
hyperlinks, images, and ease of generation with many word processors.
HTML is openly published and widely-used, and (provided a few restrictions
are observed) one of the few formats which can be read on every platform 
(and is easily converted to plain text).

However, as far as I can tell, there are several barriers to adoption 
of HTML as an RFC format:

0. Given that not all features of HTML are available on all HTML viewers,
   We need some (perhaps loose) standards for which features can be
   used, and which ones should be avoided.    (For example, the use of
   tables for formatting, or embedded images for bullets, should perhaps 
   not be allowed.  Even the use of CSS might be questionable since
   many viewers do not support it.) The standard would need to specify 
   things like which HTML tags could be used, the naming convention to
   be used for files, the format of links to other RFCs and to embedded 
   images (presumably relative rather than absolute), and "style" - 
   how a document should be formatted if it wants to look like an RFC
   (e.g. which tag should you use for a section header?).

1. Once an "RFCs in HTML" standard were adopted, common word processors 
   might be unable to produce HTML which conformed to the standard.
   It might turn out to be even more difficult to produce reasonable 
   HTML than it currently is to produce reasonable plain text.

2. The Internet-drafts and RFC Editor people would need tools to let
   them edit HTML, remove or alter tags that did not conform to the
   standard, and perhaps to convert HTML to "RFC format" ASCII text.
   (again, such tools would need to work with the garbage HTML that
   is generated by some word processors)

3. The mirror sites would have to adapt to accomodate HTML RFCs, 
   including any embedded images referenced by those RFCs.

..and there are probably a few more.  None of these is insurmountable,
but so far there has been a lack of critical mass behind the effort.

A year or two ago I set up a discussion list for rfcs-in-html.
To subscribe, send mail to [email-masked].

Keith

---

From: "Bruce Balden" <[email-masked]>
Date: Tue, 1 Dec 1998 01:00:19 -0800

I fully understood before I posted the earlier message that revising the official
format for RFC's is a divisive and difficult issue.

Although a revision of this format might be useful, my proposal is more modest, and
more clearly explained as follows.

De facto, all of the lengthier documents, if not the shorter ones as well, are
prepared by their authors orginally in some richer format, and when they are in draft
form, can frequently be found on company ftp sites (although not at the IETF) in their
original format, which is of some benefit to anybody with access to a Windows machine,
because MS makes a free MS Word viewer available. Similarly, for UNIX documents there
are groff and LaTEX under Linux.  Whatever the format, be it MS-Word or LaTEX, or
troff, this format is later projected  into ASCII, and the diagrams in particular
sometimes suffer greatly.  When the drafts become RFC's, these original forms
disappear never to be seen again.  As far as official activities go, this is perhaps
appropriate, but I wouldn't mind having the original form around.

Referring to some of the other comments, I would be sorry so see the text versions
disappear, having them searchable is extremely useful.  I frequently hope for, in
fact, a long unformatted file without the text headings and footers, so as to make it
easier to search with a text editor.

I don't greatly value the bold face headings, etc., but I found serious errors in a
version of an RFC which had been printed in a book and none-too-carefully typeset,
obviously retrofitted from the text version.  I do value proportionally spaced fonts
as far easier for the eye to read, and also taking up less paper.

The basic problem with ASCII and RFC's is that we are dealing with networking, which
sometimes requires signficant non-verbal information to be conveyed in the form of
interaction diagrams, topology diagrams, frame layouts, etc.

So as another commentator pointed out, maybe special attention should be placed on
diagrams, and a tar or zip file of relevant diagrams be made available.

MS Word is a good format because it is searchable, but IETF would need a guarantee
from Microsoft never to require a licensing fee for the Word viewing program. It
should also be noted that the Word viewing program is available for Solaris and
perhaps other UNIX-like OS's.

Before I get too many comments from MS foes, let me say that I dislike each successive
version of MS Word a little more, and I am probably going to revert to LaTEX for
technical documents, but that getting LaTEX to work can be a challenge. Even DVI
format, which is far less useful then LaTEX source from the point of view of
maintenance, can be an adventure to use.

Standards track RFC's are getting to be important documents, viewed by a much larger
audience than previous RFC's (such as the now-deleted one about a cancelled meeting),
and there far more of them than before, and their content is getting more complex.

Adopting a better source format for RFC's might be a step towards addressing this, but
it would seem than we are facing the need to use the ITU-T model of segregating RFC's
into groups by subject.

I remember twenty years ago an article in a publication noted that the programming
enterprise was one of the last tasks to benefit from software, i.e. almost all effort
in the past was expended in delivering applications to end users, with scant attention
to the programmer's own environment and comfort.

Similarly, in the IETF, the RFC's document an amazing variety of advanced networking
tools, very few of which the IETF actually employs to its own benefit.

-----Original Message-----
From: Keith Moore <[email-masked]>
To: Bruce Balden <[email-masked]>
Cc: Dunlap, Randy <[email-masked]>; [email-masked] <[email-masked]>
Date: November 30, 1998 6:12 PM
Subject: Re: Source Format of RFCs

|> A number of RFC's and drafts, such the ones regarding BGP, suffer negatively
|> from the text-only format. It would be nicer to have a richer format,
|> especially since such documents rarely originate in the text-only format,
|> but are rendered into that format by MS-Word, nroff, LaTeX or whatever.
|>
|> Would it be asking too much for all RFC's too made available in some sort
|> of rich format, and in particular their source format since that doesn't
|> require additional work?
|
|You may be asking for far more than you realize.
|
|I agree with you that the ASCII-only RFC format is a bit restrictive.
|However, ASCII is amazingly flexible.  It is one of the few formats
|that can be reasonably viewed (or searched) on any computer, and
|printed on any printer.  Neither of these is true of the document
|formats associated with common word processors.  Also, since it is
|so simple, ASCII is a good choice for formatting documents that may
|need to be readable for many decades.  For comparison, word processor
|documents from the early 1980s are difficult to read today, and
|it's not difficult to imagine that today's word processor documents
|will be difficult to read ten or twenty years from now.
|
|(The more complex the document format, the less interoperable it is.
|There have been problems with PostScript RFCs because some tools
|produce PostScript that cannot be printed on some printers.
|Similarly, version X of FooWord may produce documents that cannot
|be read by version Y of FooWord.)
|
|There are also problems with making RFCs available in multiple formats.
|One is that the RFC Editor and Internet-Drafts folks would then need
|to deal with a wider variety of tools.  Another is that multiple formats
|can make it more difficult to keep the various formats in sync.
|For instance the RFC Editor generally needs to be able to make minor
|changes to a document before publication, yet may not have the
|tools neded to modify the "source" document.  If the author is asked
|to make the changes, there is then a need to make sure that the
|author does not make other modifications to the work after it has
|been reviewed and approved by a working group and IESG.  Again,
|this generally requires special tools.
|
|Until a new format can supplant ascii text for all intents and purposes,
|there will continue to be a need to produce ascii text versions of RFCs.
|Many word processors do a very poor job of producing "RFC ASCII"
|(with margins that allow printing on both A4 and US-Letter paper,
|no overprinting, and so forth)  Documents written for a wysiwyg
|word processor are often difficult to read as ASCII, e.g. because
|the word processor will try to put too many words on a line, or too
|many characters in a column of a table. (I've seen various versions
|of this while reviewing RFCs for IESG.)
|
|Then there is a need to make sure that new RFC formats are adequately
|supported by all of the RFC and internet-drafts mirrors.
|
|For some time I have been interested in exploring the use of HTML
|for RFCs and Internet-Drafts.  This would provide several advantages,
|including multifont and multi-faced text in a variety of sizes,
|hyperlinks, images, and ease of generation with many word processors.
|HTML is openly published and widely-used, and (provided a few restrictions
|are observed) one of the few formats which can be read on every platform
|(and is easily converted to plain text).
|
|However, as far as I can tell, there are several barriers to adoption
|of HTML as an RFC format:
|
|0. Given that not all features of HTML are available on all HTML viewers,
|   We need some (perhaps loose) standards for which features can be
|   used, and which ones should be avoided.    (For example, the use of
|   tables for formatting, or embedded images for bullets, should perhaps
|   not be allowed.  Even the use of CSS might be questionable since
|   many viewers do not support it.) The standard would need to specify
|   things like which HTML tags could be used, the naming convention to
|   be used for files, the format of links to other RFCs and to embedded
|   images (presumably relative rather than absolute), and "style" -
|   how a document should be formatted if it wants to look like an RFC
|   (e.g. which tag should you use for a section header?).
|
|1. Once an "RFCs in HTML" standard were adopted, common word processors
|   might be unable to produce HTML which conformed to the standard.
|   It might turn out to be even more difficult to produce reasonable
|   HTML than it currently is to produce reasonable plain text.
|
|2. The Internet-drafts and RFC Editor people would need tools to let
|   them edit HTML, remove or alter tags that did not conform to the
|   standard, and perhaps to convert HTML to "RFC format" ASCII text.
|   (again, such tools would need to work with the garbage HTML that
|   is generated by some word processors)
|
|3. The mirror sites would have to adapt to accomodate HTML RFCs,
|   including any embedded images referenced by those RFCs.
|
|...and there are probably a few more.  None of these is insurmountable,
|but so far there has been a lack of critical mass behind the effort.
|
|A year or two ago I set up a discussion list for rfcs-in-html.
|To subscribe, send mail to [email-masked].
|
|Keith
|
|-
|This message was passed through [email-masked], which
|is a sublist of [email-masked]. Not all messages are passed.
|Decisions on what to pass are made solely by Harald Alvestrand.
|

---

From: Gunnar Lindberg <[email-masked]>
Date: Tue, 1 Dec 1998 11:52:42 +0100 (MET)

A simple example: We all know there has to be a <Postmaster> on a
mail host. Why? Which RFC? See below. 110 Mbyte data on your laptop
and you have'm all. Try that with "richer" text...

A S C I I.
End of discussion.

laptoy% cd rfc

laptoy% du -s .
106384

laptoy% grep -i -l Postmaster rfc*.txt
rfc-index.txt
rfc822.txt
rfc876.txt
rfc1020.txt
rfc1062.txt
rfc1081.txt
rfc1117.txt
rfc1123.txt
rfc1138.txt
rfc1148.txt
rfc1166.txt
rfc1168.txt
rfc1173.txt
rfc1183.txt
rfc1211.txt
rfc1225.txt
rfc1327.txt
rfc1328.txt
rfc1386.txt
rfc1392.txt
rfc1465.txt
rfc1480.txt
rfc1506.txt
rfc1580.txt
rfc1617.txt
rfc1648.txt
rfc1649.txt
rfc1699.txt
rfc1709.txt
rfc1712.txt
rfc1713.txt
rfc1720.txt
rfc1780.txt
rfc1800.txt
rfc1846.txt
rfc1855.txt
rfc1880.txt
rfc1891.txt
rfc1894.txt
rfc1911.txt
rfc1912.txt
rfc1920.txt
rfc1983.txt
rfc2000.txt
rfc2076.txt
rfc2142.txt
rfc2156.txt
rfc2200.txt
rfc2249.txt
rfc2300.txt
rfc2319.txt
rfc2369.txt
rfc2400.txt
rfc2421.txt
rfc2442.txt

	Gunnar Lindberg

---

From: "Tim Kehres" <[email-masked]>
Date: Tue, 1 Dec 1998 23:40:50 +0800

Keith,

>Given a choice between plain text and PDF, I'll take plain text every time,
>unless I want to print the document on paper (something I very rarely do).

The intent of my message was not to suggest scrapping the ASCII form of the
documents, but rather to suggest an alternative method of publishing the
information (PDF) that might be more useful to many.   Like any solution, no
matter what is chosen, it will not be perfect for everyone unfortunately.

>I also have my doubts about PDF being readable 20 years from now.

I don't understand this.  Postscript has been around for what seems close to
this amount of time, and it is still as useful as it was originally.  PDF is
even more portable with far more tools available.

>So while I could see PDF as an "alternate" RFC format (as PostScript
>is now), I certainly wouldn't want it to replace plain text.

This is all I was trying to suggest.   On the other hand, it would be nice
if more authors would make available formatted documents.  There seem to
have been several that came out for a while is postscript, but this has
dropped off.  Perhaps the choice of a more portable format might be better
at this point.

>Yes, but you're missing the point.  PDF cannot replace ASCII, and PDF
>documents are not easily translated to readable ASCII.

Replacing ASCII I don't believe to be the point here.  Well formatted
documents with diagrams and illustrations are considered by most that I know
to be easier to read, with a higher information content than their strictly
ASCII-based couterparts.  ASCII renditions of images, diagrams, etc., simply
do not convey the same information.

Again, an alternative format (in addition to the currently accepted ASCII
form) is all that I'm suggesting, or perhaps, encouraging.

Best Regards,

-- Tim

P.S.: If you are interested in some of the many pdf tools available, one
such catalog can be found at http://www.pdfzone.com, whom I have no
association with.

---

From: [email-masked]
Date: Tue, 1 Dec 1998 09:31:05 -0800

*> 
  *> And I've personally found that RFC authors who write directly for pure-ascii 
  *> format are only occasionally hampered by the inability to produce 
  *> graphics.  By contrast, RFC authors who produce word processor documents 
  *> and convert them to text later, often seem to be worrying far too much 
  *> about the appearance of the document and too little about the quality 
  *> of the prose.

Keith,

I would like to strongly second you on both statements above.

Bob Braden

---

From: [email-masked]
Date: Tue, 1 Dec 1998 09:31:05 -0800

*> 

Keith,

Bob Braden

---

From: Fred Baker <[email-masked]>
Date: Tue, 01 Dec 1998 09:37:09 -0800

At 01:00 AM 12/1/98 -0800, Bruce Balden wrote:
>De facto, all of the lengthier documents, if not the shorter ones as well, 
>are prepared by their authors orginally in some richer format

I'm not sure you can say that. I can tell you outright that MIBs are
generally done using nroff, because the accepted boilerplate is an nroff
source. Ditto PPP documents. The longest RFCs that come to mind - 1122,
1123, and 1812, were all done in nroff. I'll agree that a lot of documents
are written as ASCII text in some editor capable of other-than-ASCII, but
I'm not sure I'll buy off on "they all are"

>MS Word is a good format because it is searchable, but IETF would need a 
>guarantee from Microsoft never to require a licensing fee for the Word 
>viewing program. It should also be noted that the Word viewing program is 
>available for Solaris and perhaps other UNIX-like OS's.

It would also need a full Word implementation that ran on Solaris and BSD
Unix, as the RFC Editor would otherwise not be equipped to create the
documents. Not everyone creates their documents on PCs.

---

From: "Dunlap, Randy" <[email-masked]>
Date: Tue, 1 Dec 1998 09:57:39 -0800

I too favor keeping the text format.  I'm not sure that the
PDF format or CD-ROM media in its current form will be readable
20 years from now.

Regarding Keith's need for the ability to edit/revise a
document, I favor a transition to the SGML/HTML/XML world
instead of PDF.  It seems to me that XML solves both problems
(better readability [with graphics] and revisability).

Note:  Please don't respond to me directly.  Just to IETF will
suffice.

~Randy

> From: Keith Moore [mailto:[email-masked]]
> Sent: Tuesday, December 01, 1998 9:51 AM
> To: Tim Kehres
> Cc: Keith Moore; Bruce Balden; Dunlap, Randy; [email-masked]
> > information (PDF) that might be more useful to many.   
> 
> I agree that PDF would be a useful alternative form (and 
> better a better
> one than PostScript), but using PDF would not solve a lot of 
> the problems
> that people seem to want to solve.  (one that hasn't cropped up yet in
> this thread is the desire for a format that is revisable)
> 
> So I'd be in favor of allowing PDF as an alternative form instead of 
> PostScript, but I'd still want the plain text versions to be 
> authoritative.
> 
> Keith
>

---

From: "Dunlap, Randy" <[email-masked]>
Date: Tue, 1 Dec 1998 09:57:39 -0800

~Randy

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 1 Dec 1998 11:18:01 -0700 (MST)

> No. Having a mandatory ASCII version is OK. However, having a richer  
> format in addition is not bad either.
> ...

If you have more than one version, which version would be authoritative?
Who, except go-ers and less-than-amateurs, would look at any version of
an RFC, except whichever is authoritative?  Of course, for docments lacking
substance, such as many of the VI RFC's (Vanity Informational) published
lately, it doesn't matter which is authoritative.

As for the claims that style and substance are distinct, and that the RFC
Editor can freely decide style--what about the periodic complaints and
appeals to this mailinglist from authors that the RFC editor's stylistic
changes were substantive?  My personal, very limited experience with the
RFC editorial process demonstrated that the author must review the proposed
final draft generated by the RFC Editor, because innocent, mechanical,
supposedly minor changes by the Editor do change the substance.  Don't
authors of dead-tree books still check galleys, or exact copies of the
final pages to ensure that editorial changes were only stylistic?  How
can anyone who has dealt with real life HTML on the WWW believe that style
and substance are entirely independent and can be mechanically separated
or combined?  Only when the style is no more than can be done with ASCII
can you begin to trust any person's or mechanism's stylistic changes to
not affect substance, and even then, such trust is dangerous (e.g. line
breaks can affect substance).

In a network standard, what drawings or illustrations are genuinely
required and cannot be done with "ASCII art"?  Pretty pictures of packet
formats might be nicer than the IETF ASCII standard boxes, but are not
required, at least not by the only readers of RFC's that matter.  State
diagrams more complicated in RFC 761 probably cannot be done with ASCII
(unless you go to the ANSI style), but that only says that the state
machines such diagrams would represent are too complicated and should be
simplified or divided.

Contrary to claims about the IEEE, ITU, and ANSI, those guys do not have
a lot of fancy graphics.  ANSI network state diagrams are ASCIIfiable.
The other standards committees tend to move a <<lot>> of dead trees around
because the favored document form of whomever is currently editing the
document is useless to most participants.

The previous IETF experiements with Postscript were a resounding flop.
The reasons for that failure have not changed, and apply to all of the
proposed forms, including HTML.  When the first Postscript RFC's were
produced, Postscript had not been around for long, and most of the current
arguments for PDF applied to Postcript.  When PDF or any other non-trivial
form has been around more than 10 or 15 years, it will be just as
non-portable as Postscript is now.  (Never mind how non-portable Postcript
was in real life, as opposed to how it was supposed to be, when the
Postscript RFCs were published.)  As for HTML--have you seen what current
Microsoft tools produce for their HTML equivalents, especially for tables,
with orders (plural) of decimal magninude of bloat?

So a modest proposal: let Informational RFC's be published in anything,
but require real RFC's to be ASCII.  It would be handy to be able to filter
the junk RFC's by suffix.  My current pile of .txt RFC's takes 100+ MByte,
and it's getting so that `grep` is slow and finds too many false positives.

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 1 Dec 1998 11:18:01 -0700 (MST)

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 1 Dec 1998 11:18:01 -0700 (MST)

---

From: "Tim Kehres" <[email-masked]>
Date: Wed, 2 Dec 1998 03:58:50 +0800

>This has been tried and it just doesn't work.
>
>The problem with this approach is that implicit in it is the notion that a
tool
>can work primarily in some very rich format but then turn around and
produce
>reasonable text.

>
>But in practice this doesn't happen. The text output always ends up being a
>poor relation to the primary (to the production system) format, usually to
the
>point where it is completely unusable. It then isn't a question of the lack
of
>perfection, it is a question of not having usable text at all.

As has been pointed out by others, other organizations are using other tools
in practice that can produce rich text or better without problems.   IMHO,
in the area of documentation, the world in general may have left this group
in the dust when it comes to using better (more readable) technologies,
which is unfortunate.   The real need to perform fast searches through the
entire RFC library is quite useful, I agree, but I suspect not the only or
primary criteria that should be considered in coming up with a format (or
formats) for the documents.

>Ahem, you might want to try rendering significant amounts of very old, very
>poorly produced PostScript on modern devices sometime. I have, and the
results
>weren't good.

So, what's your point?   I've got tons of ASCII files that I can say the
same about.   Poorly constructed objects, regardless of their type are
problematic.   When's the last time you tried to print a UNIX manual page
produced with nroff on a standard printer, that did not understand
backspaces?   The underlining throughout most of these documents makes for
an unusable printed output.   Do you want more examples - they are easy to
come up with as well.  Does this make ASCII bad - not at all!

>Old PostScript goes so far as to sometimes include 68000 machine code to
>download to the printer to fix some bug or other. Unfortunately such
commands
>are rarely properly conditionalized (why bother when the only PostScript
>printer was the LaserWriter), so when presented to newer devices cause
>the operation to fail.

This is also fine and good, but what is it's relavence to PDF or other
alternatives?

No technology by itself is guaranteed to produce good results by the sheer
fact that you are utilizing it.   This is the same for ASCII as it is for
PDF, postscript, HTML, or anything else you can come up with.   There has to
be some standard structure to the documents that are uniform and
consistently applied.   This is the reason that the ASCII versions of the
documents are usable - the same could be applied to other methods (even,
*gasp*, Word formatted files).

Best Regards,

-- Tim

---

From: Francois Menard Distribution List Management Account <[email-masked]>
Date: Tue, 1 Dec 1998 15:33:31 -0500

> deal with ASCII import/export in any reasonably elegant
> ways...that is *really* baffling...maybe even enough so
> to motivate me (or someone else!) to learn how to extend

Likewise,

Maybe some developer at Microsoft could go about making an ID style and an
associated file save filter that could properly save the headers and footers
in a manner compliant with 2223.  This would let everybody buy licenses of
word for the track changes feature and let us painlessly publish it in 2223
format with a simple FILE | SAVE AS.

I'll use the Poisson list next time ...

-=Francois=-

---

From: Francois Menard Distribution List Management Account <[email-masked]>
Date: Tue, 1 Dec 1998 15:33:31 -0500

Likewise,

-=Francois=-

---

From: Geert Jan de Groot <[email-masked]>
Date: Tue, 01 Dec 1998 22:23:56 +0100

On Tue, 1 Dec 1998 01:00:19 -0800  "Bruce Balden" wrote:
> MS Word is a good format because it is searchable, but IETF would need 
> a guarantee from Microsoft never to require a licensing fee for 
> the Word viewing program. It should also be noted that the Word viewing 
> program is available for Solaris and perhaps other UNIX-like OS's.

That doesn't even come close to minimal exchange requirements 
for an IETF document.

I note that this message came to you using IP (RFC791, sep 1981),
TCP (RFC793, sep 1981) and, UDP (RFC768, aug 1980), 
and the specifications for these 18-year old protocols are readable 
unchanged on your platform of choice today, whether or not you're
M$-challenged.

MS Word's documents don't even meet this requirement today, let alone
18 years from now.

RFC-editor was very wise when he decided to use ASCII.

Geert Jan

---

From: Geert Jan de Groot <[email-masked]>
Date: Tue, 01 Dec 1998 22:23:56 +0100

Geert Jan

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 1 Dec 1998 14:34:38 -0700 (MST)

> As for composition, I am unqualified to comment on specific tool
> availability or quality.

Arguments in favor of any format are enhanced by comments about specific
tool availability and quality.  On the other hand, if we are merely going
to hypothesize usable tools, why stop there?  Why not also hypothesize
good protocol standards, disband the IETF, and retire to the beach?

>                          However, as I mentioned in a previous post, as
> long as we're initially talking about the ASCII character set, you can
> whack out SGML or XML docs in any editor that supports raw ASCII.

That is true in theory but false in practice.  It is far too easy to
generate bogus tags with an ASCII editor.  The RFC author and editor must
have at least a full-featured display tool for the rich form, to ensure
that what you've typed makes sense to the computers that will be displaying
the rich version, unless you are writing in such a simple format that it
gains nothing from the tags.   From my experience writing dirt-simple HTML
with `vi`, that problem applies to tags that only do linking, not to
mention tables.  In the simplest manual formatting, it is too easy to
mistype "<\STRONG>", lose count of "<\UL>s", and so forth.

>                                                                   There
> are ways to coerce any word processor that supports templates and a
> capable macro language into generating structured docs, but it's probably
> better to push on the vendor to integrate true XML support.

That is closer to right, but still wrong, unless you use so little of the
tags of the rich form that you would do better to stick to simple ASCII.
If you are merely going to wrap an ASCII document with something like
"<html><head><title>xxx</title></head><body>" and "</body>/<html>", then
why bother?  What are you gaining except trendy bragging rights?

]                                        But, as I mentioned earlier, the
] IETF is growing. Perhaps it's merely a personal belief and not truly
] "engineering judgement", but I just don't think that "textual conventions"
] and ASCII scale well.

What does it mean to say "ASCII [does not] scale well"?   What does the
growth of the IETF have to do with whether technical Enlish documents can
be represented in ASCII?  Am I to understand that until the invention of
some rich text scheme in the last 10 or 15 years, that all of the technical
information of mankind was limited to not much more than the current 100+
MBytes of ASCII RFC's?

] ...
] However, to summarize, I include indexing and searching improvements,
] revision control improvements, document interrelationship representation,
] and internationalization/translation in my list of "vast areas of
] improvement".

sheesh--that's more than the ITU hopes to do.  It's news to me that any
of that would be automagically implemented by using any kind of rich text.
Just to pick one item, "internationalization/translation"--is it envisioned
that the IETF should offer versions of RFC's in more than English?  Can
we anticipate charging for copies of RFC's to pay for the necessary corps
of translators, or is it felt that automatic, purely mechanical natural
languate translators finally work sufficiently reliably without human
oversight after the past almost 40 years of failures?

It should be noted and admitted that the current format is not simple
ASCII.  Nroff is a kind of a "rich format," albeit neither new nor trendy.
Why do you suppose no one except authors and the RFC Editor use the current
"rich format"?  For that matter, why hasn't troff replaced nroff?

As in previous instances of this thread in this mailinglist, after
discarding mistaken claims (e.g. style and substance are independent, or
that revision control makes sense for documents that are never changed,
such as all RFCs), the arguments for the lastest fancy formats turn out
to be "because it's the new thing recommend by all of the self-described
mavens and self-advertised gurus", "because in theory format Z is better
for use A, B, and C that in practice we don't do now but might someday",
"because we can," "because ASCII is old fashioned and prehistoric," and
other versions of "why not?".  Not coincidentally, the worst network
protocol (and other) designs are also based on the "why not" design
principle.

As I said before, I think the Vanity Informational RFC's should be allowed
to be in whatever wonderful trendy new formats their authors's desire.
If a new format works, it could and would be adopted for real RFC's.
In the more likely case, the other formats would be handy as filters.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 1 Dec 1998 14:34:38 -0700 (MST)

] ...

---

From: [email-masked]
Date: Tue, 1 Dec 1998 18:35:47 -0500

The fact is that there is no standard format for electronic documents more
advanced than ASCII Monospace. That that should be true in this day and age is
so outrageous that many engineers refuse to believe it (and pretend otherwise).

But think about it. In thirty years, we haven't managed to agree on an end of
line sequence (though we're getting pretty good at coping with all the
variations). And we haven't learned to use form feeds, so most people (including
me) who print RFCs get them with trailer lines in a different spot on each page.
[And I'm saying this in the secret hope that someone will tell me not just that
I'm an idiot, but also the trivial way to get them to come out right].

So what hope is there for rich text? The only way I can imagine it happening is
for Microsoft to take over the world and have everyone use Word (with
incompatible updates every two years, of course). And I try not to think about
that.

ASCII forever. Cursing all the way.

     --Charlie Kaufman
     ([email-masked])

---

From: [email-masked]
Date: Tue, 1 Dec 1998 18:35:47 -0500

--Charlie Kaufman

---

From: Dan Kohn <[email-masked]>
Date: Tue, 1 Dec 1998 16:09:49 -0800

Over a year ago, Eric Raymond put together a quick summary page at
<http://www.tuxedo.org/~esr/rfcs-in-html/> describing some of the ideas
from the RFCs-in-HTML list Keith mentioned.  Note that the mailing list
petered out soon afterwards.

In reviewing the page, I have to admit it seems a little dated in that
XML <http://www.w3.org/XML/> seems to offer a lot of additional
structure capability while allowing even better "down-conversion" to
HTML or text (or even, with a little Perl hacking, nroff).  In general,
though, I think XML authoring and viewing tools (not to mention XSL) are
still about 6 to 12 months from maturity and longer from ubiquity, and
so I am not yet convinced that critical mass exists to adopt a new
standard format.

		- dan
--
Daniel Kohn <[email-masked]>
Teledesic LLC
+1-425-602-6222 (voice)   602-0002 (fax)
http://www.teledesic.com

---

From: "Ranil Lizardo" <[email-masked]>
Date: Wed, 2 Dec 1998 09:14:24 +0800

Would an ascii editor that has support for pdf will answer our question?

-----Original Message-----
From: Randy Bush <[email-masked]>
To: Merton Campbell Crockett <[email-masked]>
Cc: ietf <[email-masked]>
Date: Tuesday, December 01, 1998 11:35 PM
Subject: Re: Source Format of RFCs

>> Actually, WordPerfect would be a better choice than Microsoft Word.  It
is
>> available for a much broader range of systems than Word.
>
>I prefer TeX.  <msacras>
>
>randy
>
>
>

---

From: "The Best OS" <[email-masked]>
Date: Wed, 02 Dec 1998 05:23:15 PST

<snip>
>> No. Having a mandatory ASCII version is OK. However, having 
>> a richer format in addition is not bad either.
>
>Here are the arguments I've seen in favor of non-ASCII:
>
>1) "Better" diagrams and tables. Frankly, though, the diagrams 
>   we have now are just fine.
>2) "Better formatting makes things more readable". I can't see that
>the current versions are particularly hard on the eyes. I've very
>rarely read RFCs on paper in many years, btw.
>
>So do we really want to spend lots of time and energy debating all
>this so that we can have "better" diagrams and tables and "more
>readable" text?
<snip>
>Perry

I think there are two alternate ideas here for replacing ASCII
and the above only refutes one.

Idea 1.  

Lets have something pretty, nice fonts, great diagrams, why stop
there ?  VRML network diagrams, Multimedia RFCs <g>

Idea 2.

Lets have a document with the possibilty of Meta information, the
basic doccument displays fine on my Palm Pilot, ZX81, or SGI
but with an XML enabled reader references become hyperlinks, docs
are easily searched by author, an index is swiftly compiled.

I don't think much of Idea 1 as you may guess, I don't see much
benefit and would tend to agree that ASCII is better than PDF
PostScript, M$ Word 2007 etc.

Idea 2 though looks like a win - win.  The simple ASCII RFC can
be extracted by stripping out the tags easily, a CGI on the web 
site can do that when you request the ASCII download.  RFC space
gains a structure that will make it easy to browse around a
subject.  It will be more likely that RFC users check references
when they are there as an imediate link rather than make a mental
note to have a look later then get distracted.  The MultiMedia 
crew can render beautiful headings in hand tooled illuminated 32
point fonts.  

A simple logical DTD without too much crud is of course vital
but I don't think that is beyond the skills of the IETF to define.

Regards,
R.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: "The Best OS" <[email-masked]>
Date: Wed, 02 Dec 1998 05:23:15 PST

<snip>
<snip>

Idea 1.  

Idea 2.

Regards,
R.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 2 Dec 1998 08:43:46 -0700 (MST)

> ASCII is our 90% solution. Why can't we stick with what we have and allow
> an additional alternative format for authors who wish to add pictures?
>
> The text is what we are standardizing. ASCII is good enough for that. The
> pictures are for elucidation and should be optional. Since it's optional,
> leave it up to the author to publish in whatever format they want. If I'm
> an author of a draft and I want to include a picture to describe something,
> I might include a Word, ps, PDF or XXX format file as I see fit.

If the pictures and the text disagree, which is authoritative?  If the
pictures are not required to define the standard, why include them?  If
the pictures are required to define the standard, of what use is a version
of a standard without some required information?   There are compelling
reasons why the other standards bodies go through their gyrations to
produced "normative references."  Those reasons are also why RFC's include
so much repeated boilerplate.

Of course, if you're talking about documents that would be more at
home in a trade rag keeping ads of competators from being too close
together, then such considerations are irrelevant.

> ...
> draft-holdrege-rfc-graphics-pdf-00.txt
> draft-holdrege-rfc-graphics-msword-00.txt
> draft-holdrege-rfc-graphics-ps-00.txt

Doesn't it seem odd to have a ".txt" file that is not text?  What
is wrong with old naming convention used to relate the existing
Postscript RFC's to their ASCII versions and vice versa?

] Lets have a document with the possibilty of Meta information, the
] basic doccument displays fine on my Palm Pilot, ZX81, or SGI
] but with an XML enabled reader references become hyperlinks, docs
] are easily searched by author, an index is swiftly compiled.

Useful indeces cannot be "swiftly compiled."  It is hard to find the right
uses of the right words to list, and that effort requires a human who
understands the text, not a computer.  However, if you want full text
inversion, then you already have it with `grep` on ASCII.

] Idea 2 though looks like a win - win.  The simple ASCII RFC can
] be extracted by stripping out the tags easily, a CGI on the web 
] site can do that when you request the ASCII download.  RFC space
] gains a structure that will make it easy to browse around a
] subject.  It will be more likely that RFC users check references
] when they are there as an imediate link rather than make a mental
] note to have a look later then get distracted.  The MultiMedia 
] crew can render beautiful headings in hand tooled illuminated 32
] point fonts.  

Again, what is the authoritative document?  If the pictures are
frills, then omit them entirely.  If the pictures are required,
then they cannot be skipped in any form or version of the document.
Similarly, if hand tooled illuminated 32 point fonts are required,
they must be present, and if they are not required, then there is
no reason to including them at all.

As for checking references in an existing RFC to another, I don't find it
necessary to make any mental notes.  I just switch to another to the other
file in the same or another window.  Hyperlinks are frills, unless you
believe that library research was impossible until their invention.

A major cause for this controversy is the continuing confusion or
disagreement about the purpose of the documents published by the IETF.
If RFC's define network protocol standards, then you must have a well
defined format, and you do not need fancy pictures or hyperlinks.  If the
RFC series is a kind of trade-rag or netnewsgroup, then many formats are
reasonable, and no one really cares if there many versions of a document.
The form of the filler between trade-rag ads and netnews articles is often
at least important than the substance.   If the IETF would stop publishing
vanity RFC's, then much of this controversy would be quenched.

---

From: Johnny Eriksson <[email-masked]>
Date: Wed, 2 Dec 1998 17:21:21 MET

Randy Bush <[email-masked]> wrote:

> >> Could not we use XML (vs. ASCII) as the RFC format?
> > give us some arguments for that, concerning choice of word processor (what
> > UNIX, what Mac, and what PC word processors support it)
> 
> please do not forget waits, tops-20, ibm and other lameframes, vms, ...

"There are two kinds of fools:
 One says: This is old, and therefore good.
 The other says: This is new, and therefore better."

That said, let it be known that I'm the former type of fool, of the very
strong opinion that ASCII's very lack of blinking text, boldface, fonts,
graphics, sound etc. is in this context a Good Thing, since that means
that they can't be abused.

And no, I won't forget tops-20 either.

> randy

--Johnny

---

From: Johnny Eriksson <[email-masked]>
Date: Wed, 2 Dec 1998 17:21:21 MET

--Johnny

---

From: Tripp Lilley <[email-masked]>
Date: Wed, 2 Dec 1998 11:51:07 -0500 (EST)

I propose that we move this discussion to the [email-masked],
which can be subscribed to through [email-masked]. If you
have not already done so, please read the material archived at
http://www.tuxedo.org/~esr/rfcs-in-html/index.html to get up to speed on
"what has gone before" on the list.

Also, read Fred Baker's very excellent "focusing post", archived at 
http://www.ietf.org/mail-archive/ietf/msg03303.html .

I believe that the charter of the rfcs-in-html list and the the nature of
the current discussion differ. However, it still seems the best place to
move to have the "serious discussion on the subject" for which Mr. Baker
calls.

Hope to see you there!

------------------------------------------------------------------------------
Tripp Lilley, Innovative Workflow Engineering, Inc. ([email-masked])
------------------------------------------------------------------------------
         "Given enough eyeballs, all bugs are shallow" -- Linus's Law

---

From: Tripp Lilley <[email-masked]>
Date: Wed, 2 Dec 1998 11:51:07 -0500 (EST)

Hope to see you there!

---

From: "Mark D. Anderson" <[email-masked]>
Date: Wed, 2 Dec 1998 08:46:49 -0800

FYI, the w3c seems to be working on this problem; there is an early
version of a dtd for a specification format in xml, at:
http://www.w3.org/XML/1998/06/xmlspec-report-19980910.htm
There is an archived discussion list at:
http://cgi.w3.org/Archives/Public/spec-prod/1998JanMar/0000.html
There are some stale thoughts at:
http://www.w3.org/MarkUp/SGML/spec-mgmt

They currently have *not* yet published dsssl or xsl sheets to work
with such an xml format.

I'm not involved in the w3c; just interested in the problem.

-mda

-----Original Message-----
From: Eric S. Raymond <[email-masked]>
To: Dan Kohn <[email-masked]>; 'Keith Moore' <[email-masked]>; Bruce Balden <[email-masked]>
Cc: Dunlap, Randy <[email-masked]>; [email-masked] <[email-masked]>; 'Rohit Khare' <[email-masked]>; 'Adam Rifkin'
<[email-masked]>
Date: Tuesday, December 01, 1998 5:46 PM
Subject: Re: Source Format of RFCs

>I'm still interested in this problem, Dan.  I agree that XML is looking
>good for this purpose.  I'll make it an action item of mine to send a notice
>to the list when it looks like there's a stanard. open-source XML toolkit
>to work with.

---

From: [email-masked]
Date: Wed, 2 Dec 1998 09:26:20 -0800

*> 
  *> Nroff is too complex - it bothers authors with details like indention,  
  *> headline numbering etc. LaTeX would be much better - if we had a good  
  *> documentclass. Word processors usually can't produce good preformatted  
  *> plain text.
  *> 

Note that the RFC Editor recommends not full nroff, but nroff -ms.
This is comparable to using LaTex rather than Tex (or however you
capitalize it), plus maybe a few nroff macros.  It's NOT very complex...

Bob Braden

---

From: [email-masked]
Date: Wed, 2 Dec 1998 09:26:20 -0800

*> 

Bob Braden

---

From: Per Gregers Bilse <[email-masked]>
Date: Wed, 2 Dec 1998 18:41:40 +0100

Permit me to butt in from the side.  While not an active producer of
RFCs and I-Ds, I do read a lot of them, and I find well written plain
text, optionally with some simple diagrams and tables, absolutely
marvellous for the purpose at hand: describing protocols and processes
in a clear and unambigous way.

A lot of this discussion seems to ignore what the purpose of the
documents is.  They are not manuals, they are not advertisements, their
purpose is not to highlight features, etc.  They are English language
descriptions of processes and protocols which one way or another are to
be codified: turned into algorithms and code, to be run on machines.
While a picture may be worth more than a thousand words for other
purposes, that is not the case here (unless "Visual C" means something
new and interesting).  The more fuzzy and open to interpretation
a description is, the more likely it is that different implementations
will exhibit behaviour which the standard, and/or its author, did
not intend.  Similarly, arguments over which is correct behaviour
will easily proliferate.

In a nutshell: A standard MUST express the process to be implemented
in a clear and unambigous way.  It MAY include diagrams to aid
understanding, but authors SHOULD NOT rely on such aids for core
functionality.  Being blunt:

- if an author cannot describe the process without use of pictures,
  somebody else should do the writing;

- if implementors cannot understand the process without pictures, they
  probably shouldn't be writing source code for machines in the first
  place -- they will have much worse problems understanding their own
  code than understanding the description;

- if the process/protocol is such that it cannot be expressed in plain,
  understandable English at all, it probably won't have any hope of
  working on real machines in the real world; at least not in a fashion
  interoperable with other implementations.

Note that these issues are completely different from those of eg the
ITU, where transponder beam footprints were mentioned as an obvious
example.  That is information which is completely different from a
description of a protocol or process, or the other things which are
typically described in RFCs.

On a more subjective note, the general light weight of ASCII documents,
their total portability, etc, etc, should be enough in its own right.
If I need to cross reference between two or more places (be they in the
same document or in different ones), it's trivial to have multiple
windows open.  Flipping through pages, text search, etc, are equally
trivial in normal editors as we know them.  It's rather much less than
trivial to do the same with eg PostScript or PDF (the search function
in acroread is outright horrendous, and it is seriously slow), or,
for that matter, any other "better-than-ASCII" type of editor/viewer.

-- 
------ ___                        --- Per G. Bilse, Director Network Eng & Ops
----- /     /  /   __   ___  _/_ ---- EUnet Communications Services B.V.
---- /---  /  /  /  /  /__/  /  ----- Singel 540, 1017 AZ Amsterdam, NL
--- /___  /__/  /  /  /__   /  ------ tel: +31 20 5305333, fax: +31 20 6224657
---                           ------- 24hr emergency number: +31 20 421 0865
--- Connecting Europe since AS286 --- http://www.EU.net e-mail: bilse at domain

---

From: Per Gregers Bilse <[email-masked]>
Date: Wed, 2 Dec 1998 18:41:40 +0100

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 2 Dec 1998 15:46:41 -0700 (MST)

> From: Matt Holdrege <[email-masked]>

> ...
> The author decides what is authoritative. The author writes the drafts. In
> short the author is totally reponsible for his/her draft. Nothing new here.

On the contrary,
  - the author's decision is irrelevant, even if you accept the false idea
      that an author is responsible and authoritative about a standard.
      The question is not what the author really meant, but what readers
      infer of the author's meaning.  Readers must have a decision
      procedure for determining what the standard says.  If some pictures
      are part of the standard, then they must be in all copies of the
      standard.  An fragment of a standard is merely a fragment.  If
      pictures are not part of the standard, then they "MUST" be omitted.

  - you are proposing several new things:
       1. you want something other than the nroff that the RFC Editor uses
	  as the primary source for generating RFC's, and other than the
	  de facto deprecated Postscript.  (I think I recall that the
	  Editor converted my initial rax ASCII to the IETF's simplified
	  nroff in my brush with the process).

      2. you propose documents that are in more than one part, and no
	  indication of which parts constitute the authoritative standard.

      3. you would make RFC authors ! authoritative about the contents of
	  RFCs.  That is a radical change!  Currnetly, only the sponsoring
	  working group can say what the standard is.  (Of course, the
	  vanity RFC's are something else.)

> If the author wishes to include pictures, that is up to him/her. They do it
> anyway today at their own web site. Re-read my note about this scheme being
> for I-D's and not necessarily for RFC's.

And that is the biggest mistake and misunderstanding of what we
are talking about.

  1.  The last version of an Internet-Draft is identical to the RFC.
      If the last I-D differed from the RFC, who would make the changes
      to convert one to the other?  How does the working group approve
      those changes without seeing them in the final I-D?

  2. if someone wants to say something, then they can say it in the
      working group mailinglist.  You can use the format of an I-D, or
      you can use any other form.  Others have said that the formal I-D
      form is useful even for initial or throw-away ideas, and they may
      be right.  That you use the form an I-D should not let you fool
      yourself into thinking you are writing an I-D, because it doesn't
      fool eveyrone else.   An "Internet Draft" is an "Internet Draft of
      an RFC", not a random marketing tract or stray technical statement.

  3. the legitimate purposes of the IETF RFC's do not include vanity
      publishing, "educating consumers," or providing flak for
      salescritters.  RFC's exist only to define standards for network
      protocols.  The Information RFC's are at best frills and supplements,
      and in many cases literally parasites.  The reason so many people
      want to publish vanity and proprietary Information RFC's is purely
      because of the reputation of the real RFC's.  Those authors and
      organizations are literally being parasitic.

  4. a real RFC has nothing to do with a personal web site.  It is just as
      silly to compare an RFC with the contents of a personal or corporate
      web site as it is to compare the contents of popular magazines with
      laws passed by Congress or your nearest City Council or School Board.
      It is true that laws, RFC's, websites, and the popular press are
      all mere text and pictures, but there are also differences.  You
      can't create your own law any more than you can create your own
      de jure or de facto standard.

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 2 Dec 1998 15:46:41 -0700 (MST)

On the contrary,

---

From: Chen Maoke <[email-masked]>
Date: Thu, 3 Dec 1998 11:06:50 +0800 (CST)

Sorry for my late arriving at this topic. I agree with Bilse from EUnet. We should focus on the purpose of the RFC documents. In my opinion, the RFCs are mostly the description of the technology and/or ideas related to the evolution and innovation of the Internet. So it is important that an RFC should provide information much as possible with bytes few as possible, and that one can get the information as conveniently as possible whatever system and software he/she are using.

Therefore I think it would be better to write the RFC in ASCII code. I cannot bare that a technical standard document would occupy much more space than the words we can read. I even prefer to read the RFCs in .Z form with some popular tools such as zcat, without decompress. 

As to the illustrations or graphics, the current RFCs are working excellent. Diagrams in a specific format, are not necessaryly good presented on a specific platform. Diversity is one of the essential principle of the Internet. We cannot forget this when we are discussing the RFC format.

Thanks,
Maoke
-------------------------
Chen, Maoke
Dept. of Electronic Engineering,
Tsinghua University,
Beijing, 100084
P R of China
e-mail: [email-masked]

---

From: [email-masked]
Date: Thu, 3 Dec 1998 15:20:02 -0800

*> 
  *> Lloyd,
  *> 
  *> What is the point of a technical doucment
  *> unless it educates?  Does anyone agree
  *> with me here?
  *> 
Sorry, this seems silliness to me.  We are talking (mainly)
about protocol standards documents.  They are reference documents
used by implementators and other experts who do not need
education.  They understand the context and just want the
facts.  If you want education, go visit your local bookstore

  *> If the technical document doesn't educate
  *> and provide _useful_ information to the
  *> reader than it is nothing more than
  *> an ego booster for the author.
  *> 

Faintly insulting to those of us who work hard on protocol specs.

Bob Braden

---

From: [email-masked]
Date: Thu, 3 Dec 1998 16:12:28 -0800

*> From [email-masked] Thu Dec  3 15:52:31 1998
  *> Reply-To: <[email-masked]>
  *> From: "Mitch Denny" <[email-masked]>
  *> To: <[email-masked]>, <[email-masked]>
  *> Cc: <[email-masked]>
  *> Subject: RE: Source Format of RFCs
  *> Date: Fri, 4 Dec 1998 10:51:43 +1000
  *> MIME-Version: 1.0
  *> Content-Type  *> :   *> text/plain  *> ;   *> charset="iso-8859-1"  *> 
  *> Content-Transfer-Encoding: 7bit
  *> X-Priority: 3 (Normal)
  *> X-MSMail-Priority: Normal
  *> X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
  *> Importance: Normal
  *> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
  *> In-Reply-To: <[email-masked]>
  *> Content-Length: 2582
  *> X-Lines: 82
  *> 
  *> Bob,

Mitch,

Well, I replied privately to avoid clogging the IETF channel, but
since you address me directly...

  *> 
  *> When an author puts out a document for a proposed
  *> standard, they are the expert, assuming it is a new
  *> protocol and not a rehash, they are the only ones
  *> with this knowledge.
  *> 
  *> THERE ARE NO OTHER EXPERTS.  So this document
  *> has to be able to educate the readers so that
  *> they can then go out and implement it.
  *> 

In general, this is simply nonsense.  For most IETF-produced documents,
there are WGs full of experts.  An RFC author is typically a scribe who
combines his/her own ideas with other's ideas to create a specification
in English prose.  Furthermore, there are few IETF-produced standards
that could not be competantly implemented by 20 - 100 different people
attending one IETF meeting, on the basis of the RFCs alone.

  *> There is no point listing arbitary command
  *> syntaxs without defining and showing how they
  *> work together to create a protocol.
  *> 
  *> Can you remember when you suddenly knew everything
  *> that there was to know about a system?  No, you
  *> learnt the information over time.  Imagine how
  *> much more you could have accomplished if you had
  *> all the information that you needed in an
  *> educational form rather than obscurely formated
  *> documents.

No, I have never known all there is to know about any
(non-trivial) system, but it is a nice thought.

This is exactly why protocol implementation is
a learning experience, and why the IETF insists on
implementations.  It has nothing to do with RFCs or
Internet Drafts.

  *> 
  *> When I want to learn about some background
  *> technology being used on computer systems today
  *> my first point of call is a lookup on the current
  *> database of RFC's.
  *> 

As do many of us, but apparently you are dissatisfied with
the result.  Again, I refer you to your corner bookstore
for introductory material on Internet protocols.

  *> I do not intend to insult those very intelligent
  *> people that have worked hard to produce extremely
  *> useful conventions to operate with.  My point is
  *> that the documents produced can be both a reference
  *> and informative.
  *> 

Informative?  Yes, I find most RFCs (excepting maybe
MIBs!) very informative.  Educational?  No, I read a book.

  *> We should create technical documents that address
  *> a wider audience, and are more complete.  We 
  *> shouldn't be elistist by excluding vital
  *> informative and educational information.

Sorry, but I entirely disagree.

Introducing the term "elitist" here is emotional clap-trap (gosh, I have not
had a good occasion to use that word for a long time!).

Bob Braden

---

From: [email-masked]
Date: Thu, 3 Dec 1998 16:12:28 -0800

Mitch,

  *> 

  *> 

Bob Braden

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 3 Dec 1998 17:36:45 -0700 (MST)

> From: "Mitch Denny" <[email-masked]>

> ...
> When an author puts out a document for a proposed
> standard, they are the expert, assuming it is a new
> protocol and not a rehash, they are the only ones
> with this knowledge.
>
> THERE ARE NO OTHER EXPERTS.  So this document
> has to be able to educate the readers so that
> they can then go out and implement it.

Again, RFCs that are not VI RFCs are the products of IETF Working <<GROUPS>>,
not "authors."  I've long argued that the use "author" instead of "editor"
by the IETF causes many distortions of the process and misunderstandings
by outsiders.  Because of that word, people aspire to be RFC authors
for bad reasons, most often to be famous and so improve their sex lives,
get a promotion at work, or help their private consulting businesses.

> There is no point listing arbitary command
> syntaxs without defining and showing how they
> work together to create a protocol.

I disagree.  Thank you very much, but let the RFC simply define the
protocol, so I can hack the code to implement it.  I'll go elsewhere to
learn its purpose or application, if I don't already know or can't figure
it out.

There is more than one kind of technical document.  One is a reference
manual, and another is a tutorial.  People who already have clues find
tutorials misleading and generally worse than useless.  People new to a
subject find reference manuals very difficult and often give up.  Document
that try to be both reference manuals and tutorials combine the worst of
both flavors and the virtues of neither.  Historically, RFC's were
reference manuals.  You, like others over the years, are urging that
the real RFC's become either turtorials or combination tutorials and
reference manuals.  That might help educate the masses, but it would hurt
the current readers of RFC's, implementors and protocol designers.

>                                  ... My point is
> that the documents produced can be both a reference
> and informative.
>
> We should create technical documents that address
> a wider audience, and are more complete.  We 
> shouldn't be elistist by excluding vital
> informative and educational information.
>
> The Information Technology industry as a whole
> is fairly elitist, I am guilty of it, I bet some
> of you are too.  If we devulged a little more
> information more readily in a better format,
> out technologies would be taken up quicker and
> we could go on to develop better systems.

Why don't those words apply equally or more to the documents produced by
lawyers and legislators?  Every law or serious contract I've tried to read
has "[exclued] vital informative and edutational information".  Why are
all lawyers and politicans so "elitist"?

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 3 Dec 1998 21:52:59 -0700 (MST)

> > manual, and another is a tutorial. ...

> It is all about creating a resource that
> everyone can use, ofcourse you merge the
> two documents, you link them, make the
> tutorial reference the reference.

Have you ever been involved in making documentation for computer stuff?
I have, and I think you cannot simply link a reference manual to a tutorial
and vice versa.  The two must be independent enough to stand on their own,
although each might benefit from the existence of and links to the other.
Writing both a tutorial and a reference manual requires about twice as
much work as writing a reference manual.  Why should IETF Working Groups
double their work "create a resource that everyone can use"?  Why must
the IETF serve everyone?

> My original point was use a rich format
> to help convery _whatever_ information
> better.  Why do people have a problem
> with that.
> ...

Why didn't you answer my question about why protocol specifications must
or at least can be easily accessible or use a rich format, but laws and
other legal documents cannot?  The truth behind the jokes about the
protocol police is that protocol specifications are the laws of the net
universe, and standards committees are legislatures and courts.  It makes
as much sense for the U.S. Congress or the United Nations to use your rich
format (whichever it is) as the IETF.

As many have said, a reference manual for almost any network protocol does
not need a format richer than ASCII, at least for the current customers
of standards track RFC's, the implementors and authors of standards track
RFC's.  Maybe like judges, lawyers, and politicians, we're just
stuck-in-the-mud for not requiring hyperlinks and GIFs in our laws, or
maybe we're right.

What is wrong with the network trade magazines, textbooks, tutorials,
video training tapes and even CDROMs in the nearest bookstore?  There are
more such works in your nearest "Barnes and Noble" then there are
prehistoric ASCII RFC's.  There are legions of people eagar to write and
publish more of whatever you are willing to pay for.

What is wrong with diversity?  Why must all network documents be as rich
as the trade rags in your nearest supermarket?  If a rich format is better,
then it will soon replace the efforts of "legacy Internet programmers".

---

From: Vernon Schryver <[email-masked]>
Date: Thu, 3 Dec 1998 21:52:59 -0700 (MST)

---

From: [email-masked]
Date: Fri, 04 Dec 1998 12:52:27 +0100

[email-masked] said:
> As often as not, when printing them (the only time when pagination
> makes any sense at all) the printer ignores the ^Ls and the header/
> footer cruft marches slowly up successive pages, making for a truly
> ugly and unreadable doc.

Could it be because you're trying to print the RFC directly from your
browser? Usually, most printers deal correctly with Form Feeds, but
it these FFs are filtered out either by the printing software (e.g.
the browser) or by the printer driver, the FFs will be useless.

When I want to print an RFC that I retrieved with a Web browser, I first 
save the RFC to a file, then print the file from a command shell. Thus, 
the FFs work fine.

Peace,

Bertrand Ibrahim.
--------------------------------------------
[email-masked]
http://cuiwww.unige.ch/eao/www/Bertrand.html
My PGP public key is in my WWW home page.
Its fingerprint is 27 F8 E6 45 76 C4 E4 90 C5 83 2A 14 20 CC 7D FC

---

From: [email-masked]
Date: Fri, 04 Dec 1998 12:52:27 +0100

Peace,

Bertrand Ibrahim.

---

From: "R. Lizardo" <[email-masked]>
Date: Sat, 5 Dec 1998 08:47:46 +0800

-----Original Message-----
From: RL Bob Morgan <[email-masked]>
To: [email-masked] <[email-masked]>
Date: Friday, December 04, 1998 6:30 PM
Subject: Re: Source Format of RFCs

>
>The one useful suggestion (IMHO) in this thread was from Bill Janssen:
>
>> One thing I'd like to see change, though, is the pagination of RFCs.  It
>> would be more useful, in my opinion, to format the RFC text as one long
>> scroll of text, rather than breaking it into pages as is currently done.
>> Easier to print, too, in my experience.
>
>Yes, yes, yes.  Pagination in RFCs is the single major drawback of the
>format.  The interpage header/footer/whitespace intrudes on the document
>text, making it harder to read.  As often as not, when printing them (the
>only time when pagination makes any sense at all) the printer ignores the
>^Ls and the header/footer cruft marches slowly up successive pages, making
>for a truly ugly and unreadable doc.  "diff" makes an excellent substitute
>for the changebars many folks seem to want (for comparing I-D versions,
>that is); or it would except that any text change that alters the
>pagination produces lots of spurious diff output.  Having produced an I-D
>or two using the nroff tools, the only obnoxious part about it was getting
>the pagination right.  The only other possible justification for
>pagination is as location indicators for focussing discussion, but in my
>experience people say "see section 4.3.5" not "see page 23", and for good
>reason.
>
>So, let me second Bill's suggestion that pagination in future RFCs simply
>be dropped.  If this is too radical, then we should abandon pagination in
>I-Ds, where it is really even more of an obstacle, and only have the RFC
>editor add it when the doc becomes an RFC.
>
> - RL "Bob" Morgan
>   Stanford
>
>

I agree with Bill and Bob on the changing of RFC pagination for the same
reason!

---

From: "R. Lizardo" <[email-masked]>
Date: Sat, 5 Dec 1998 08:47:46 +0800

---

From: "Herman R. Silbiger" <[email-masked]>
Date: Fri, 4 Dec 1998 16:29:12 -0500

I second that suggestion.  In addition, if you really have to have hard EOLs, don't exceed the printable width of the A4 page (less than 196mm.)  That way the drafts/RFC can be printed on both A4 and North American letter paper.

Herman Silbiger

----------
From:  RL Bob Morgan [SMTP:[email-masked]]
Sent:  Friday, December 04, 1998 4:46 AM
To:  [email-masked]
Subject:  Re: Source Format of RFCs

 - RL "Bob" Morgan
   Stanford

---

From: "Herman R. Silbiger" <[email-masked]>
Date: Fri, 4 Dec 1998 16:29:12 -0500

Herman Silbiger

----------

 - RL "Bob" Morgan
   Stanford

---

From: Robert Elz <[email-masked]>
Date: Sun, 06 Dec 1998 05:30:59 +1100

It has been most "amusing" to suddenly find myself reading a week's worth
of IETF mail, and find it has been dominated by this topic, all over again.

These discussions never change (except in minor detail).   Most people will
accept that something better than ascii might be nice to have (a few will
proclaim that anything more than ascii is necessarily bad).

Then there's the discussion of what should (could) replace ascii.   The
interesting thing here is that the most preferred suggested replacement is
always this new "not quite ready yet, but everyone will be using it in
6 months" format, that at the time of the discussion very few people have
actually used enough to be able to see all the pitfalls.   By the time
that a format is truly widespread, almost no-one wants it, because all of its
warts are then visible.

Ascii is nice because we know its warts, we have long practice in dealing
with them, and we have learned how to cope.

Could we please attempt to avoid having this discussion again until we have
a format in genuine widespread use which has demonstrably less problems
than ascii has?

kre