Subject: Re: Source Format of RFCs

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: Keith Moore <[email-masked]>
Date: Tue, 01 Dec 1998 12:50:43 -0500

> 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: Keith Moore <[email-masked]>
Date: Tue, 01 Dec 1998 12:50:43 -0500

Keith

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 Dec 1998 10:50:52 -0800 (PST)

> matter what is chosen, it will not be perfect for everyone unfortunately.

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.

This, coupled with the points Keith has made about the impact of such choices
on the RFC Editor, make this approach unworkable in practice. And again, it
isn't like it hasn't been tried.

> even more portable with far more tools available.

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.

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 but one example. I could list dozens of others.

> dropped off.  Perhaps the choice of a more portable format might be better

And the reason it dropped off was that it was a failure operationally.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Tue, 01 Dec 1998 10:50:52 -0800 (PST)

Ned

---

From: Bill Janssen <[email-masked]>
Date: Tue, 1 Dec 1998 11:26:42 PST

Plain text has so many advantages for RFCs, it's hard to imagine any
format that could replace it.  And I say this being a big fan of
generalized markup languages, too.

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.

Bill

---

From: Bill Janssen <[email-masked]>
Date: Tue, 1 Dec 1998 11:26:42 PST

Bill

---

From: RL Bob Morgan <[email-masked]>
Date: Fri, 4 Dec 1998 01:45:35 -0800 (PST)

> 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

---

From: RL Bob Morgan <[email-masked]>
Date: Fri, 4 Dec 1998 01:45:35 -0800 (PST)

- RL "Bob" Morgan
   Stanford

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 4 Dec 1998 11:36:21 +0000 (GMT)

On Fri, 4 Dec 1998, RL Bob Morgan wrote:

> I-Ds, where it is really even more of an obstacle,

Yes, yes, yes. The pagination breaking some of the ASCII diagrams in
the NAT drafts is particularly confusing, and the occasional draft
where pagination information doesn't match the draft title/filename 
well or at all (e.g. a recent udlr draft) suggests that draft authors
shouldn't need to worry about this.

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 4 Dec 1998 11:36:21 +0000 (GMT)

L.

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 Dec 1998 10:44:15 -0500

> As often as not, when printing them (the
> for a truly ugly and unreadable doc.

My printers, at least, seem to still recognize ^L.
However, if I use a web browser to download an RFC, it may filter out ^Ls.
An old-fashioned ftp client works better.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 04 Dec 1998 10:44:15 -0500

Keith

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 04 Dec 1998 11:20:38 -0800

At 01:45 AM 12/4/98 -0800, RL Bob Morgan wrote:
>Yes, yes, yes.

Agree, agree, agree. A bit of quick-and-dirty Perl code I use before I
print RFCs and IDs. Warning: This code occaisonally loses lines I don't
want it to, and also leaves a few blank lines in that I would like it to
get rid of. Improvements (off the ietf mailing list) are always appreciated.

foreach $File (<*>) {
        next if (-d $File);
        print "Doing $File\n";
        open(IN, $File);
        $All = '';
        while(<IN>) { $All .= $_ }
        # Strip formfeeds
        $All =~ s/\cL\n//g;
        $All =~ s/\cL//g;
        # Strip page numbers
        $All =~ s/^.*\[Page (\d)+\]$//gm;
        # Strip lines starting with "INTERNET DRAFT" or "INTERNET-DRAFT"
        $All =~ s/^INTERNET[ -]DRAFT.*$//gm;
        # Strip lines starting with "RFC nnnn   "
        $All =~ s/\nRFC \d\d\d\d  .*\n\n//gm;
        # Strip multiple newlines
        while(1) {
                $Count = ($All =~ s/\n\n\n/\n\n/g);
                last if($Count == 0);
        }
        open(OUT, ">../Out/$File.txt") or die "Could not write to $File: $!\n";
        print OUT $All;
        close(IN); close(OUT);
}

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Fri, 04 Dec 1998 11:20:38 -0800

foreach $File (<*>) {
        next if (-d $File);
        print "Doing $File\n";
        open(IN, $File);
        $All = '';

--Paul Hoffman, Director