Subject: Publishing RFCs in PDF Formal

From: Russ Housley <[email-masked]>
Date: Tue, 26 Aug 2008 16:45:33 -0400

It has already been done: http://www.rfc-editor.org/rfc/rfc97.pdf

PDF is an ISO standard, and the RFC Editor has already set a 
precedent by using this format when they are unable to locate an 
electronic copy of a very old RFC.

This seems like a fine format to capture images, pictures, glyphs, 
and other such things that are difficult to render in ASCII.

No hats on,
   Russ

_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 26 Aug 2008 18:03:12 -0400

--On Tuesday, 26 August, 2008 16:45 -0400 Russ Housley
<[email-masked]> wrote:

> precedent by using this format when they are unable to locate
> an  electronic copy of a very old RFC.
> 
> This seems like a fine format to capture images, pictures,
> glyphs,  and other such things that are difficult to render in
> ASCII.

Russ,

We've stuck with ASCII in the last many years because, in
addition to being a very stable and widely-available format, it
is easily accessible to tools that are widely-available and very
simple.  Diffs work.  Grep works.  Nearly mindless regular
expression searches work.  Copying text out of one document,
modifying it, and pasting it onto another works, and works
reliably.  That list, obviously, goes on.  While there are
possible substitutes for each 
of those, they are not generally available in free products
(unlike simple creation and rendering of PDF files).

There are actually two types of exceptions to the "ASCII" rule
as the normative form of an RFC.  One arises when the authors
can convince the RFC Editor that the document simply would not
make sense without material that cannot reasonably be rendered
into ASCII text or ASCII art.   In those cases, it is possible
to publish an RFC with the primary/normative text in Postscript
(and, more recently, PDF).   The traditional, and most
important, example of that case is the NTP specs, starting with
RFC 1119.  The other is older documents for which no
machine-readable text was available (or there was
machine-readable text in, e.g., NLS) and for which scanning was
the only option for making the documents available.  Some of
those were scanned, run through OCR systems, and then carefully
checked to produce ASCII results.  For others, the resources
weren't around to do that job so seemed wise to get them online
in some form, even image-facsimile.

While we have assumed that virtually all of the community
(Frank's remarks notwithstanding) can read, render, and, if
needed, print PDF files, more complex operations require tools
that are less readily available (or significantly expensive).
One reason for considering the image file an add-on to the ASCII
one, rather than a replacement, is to leave the base RFC
accessible in all of the traditional ways.

I don't think either of the older PDF-only cases one sets much
of a precedent, at least if we continue to care about such
things as those mentioned above.

    john

---

From: SM <[email-masked]>
Date: Tue, 26 Aug 2008 16:04:02 -0700

>(unlike simple creation and rendering of PDF files).

Amplifying John's comments, RFCs written over 25 years ago are still 
accessible nowadays as they are in ASCII.  Anyone can write tools 
without undue cost to read, parse, search and produce documents in 
that format.  Can we say the same for other document formats widely 
used over the last decade?

If PDFs were the formal copy, would the required tools be widely 
available to do the above?  What about 25 years from now?  Vendors 
only develop software if there is a market for it.  The cost of 
maintaining software for IETF use only would be high.  One of the 
advantages of PDF/A is that it is also used by other market 
segments.  At least that reduces the likelihood of problems in future 
accessing the proposed image file format.

Given that the format currently used for publishing RFCs have 
withstood the test of time, any move away from that should be very 
carefully considered.

Regards,
-sm

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 27 Aug 2008 09:22:57 +0900

> electronic copy of a very old RFC.

Then, let's deploy CLNP, first.

CLNP is an ISO standard, and the RFC Editor has already set a
precedent by publishing RFC1347.

						Masataka Ohta

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 27 Aug 2008 02:32:17 +0200

Russ Housley wrote:

> http://www.rfc-editor.org/rfc/rfc97.pdf

Yes, that was a famous case for friends of RFC 5198 :-)

I think somebody had a printed copy and scanned it to
fill a gap in the repository at least for PDF.  

Now looking at it again, the last page was apparently
never ASCII.  Or it does not really belong to RFC 97.

 Frank

---

From: John C Klensin <[email-masked]>
Date: Wed, 27 Aug 2008 00:48:39 -0400

> never ASCII.  Or it does not really belong to RFC 97.

Many of the very early RFCs were prepared in NLS... or on what I
believe were called "typewriters" at the time.  Neither form is
conveniently machine-processable today.

  john

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 27 Aug 2008 09:09:40 -0700

>It has already been done: http://www.rfc-editor.org/rfc/rfc97.pdf

The IETF has done lots of things that don't scale well to multiple tool sets.

>PDF is an ISO standard,

So is OOXML.

>and the RFC Editor has already set a

This is a fine precedent for prehistoric RFCs. I'm pretty sure the 
recent thread was for current RFCs.

>and other such things that are difficult to render in ASCII.

It sure it. It just turns out to be a terrible format for extracting 
text as anything other than lines, and even then doesn't work 
reliably with commonly-used tools

--Paul Hoffman, Director
--VPN Consortium

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Aug 2008 18:16:16 +0200

Paul Hoffman wrote:
> ...
> ...

It's also a terrible format for reading documentation in a Web Browser. 
I believe the IETF and the W3C came up with a better format for that a 
few years ago...

BR, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Aug 2008 12:45:27 -0400

> I believe the IETF and the W3C came up with a better format for that a 

Not clear.

It might be that a small and well-chosen subset of [X]HTML, with strict
checking to limit the kinds of tags and parameters used, and data: URLs
for all images referenced from the main document, would be a decent RFC
format.   But data: URLs are not as widely supported as we'd like.  Nor
is MHTML.  Having multiple files per document is less attractive.

I also suspect that using HTML for RFCs would invite a lot of heated
discussion on just what that HTML should look like.  e.g. I personally
have an intense dislike for the HTML that xml2rfc produces, but I don't
have to care much as long as the plain text versions of those RFCs are
still authoritative.

I'm not saying [X]HTML RFCs are an inherently bad idea, just that
they're not as simple to get right as it might seem.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Aug 2008 18:53:12 +0200

> for all images referenced from the main document, would be a decent RFC

data URIs are available in 3 out of 4 major browsers, with IE8 adding 
them as well.

> is MHTML.  Having multiple files per document is less attractive.

That's true, but the other proposal that's on the table also requires 
multiple files.

> have an intense dislike for the HTML that xml2rfc produces, but I don't

So do I :-)

> they're not as simple to get right as it might seem.

That's true, but I would expect *less* discussions as compared to just 
using PDF (for everything).

BR, Julian

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Aug 2008 13:02:26 -0400

> data URIs are available in 3 out of 4 major browsers, with IE8 adding

I thought IE8 had some fairly annoying limitations on their use?

> That's true, but the other proposal that's on the table also requires

sure, but I'm not taking that proposal seriously :)

> using PDF (for everything).

IMHO, the only thing PDF has going for it is that (sadly) it's easier to
print PDF correctly on most computers than it is to print plain text.
Pretty much everything else about PDF, IMHO, makes it a poor choice for
most new RFCs.  (though it's probably slightly better than PostScript
such as was used in the past).

Keith

---

From: "Tim Bray" <[email-masked]>
Date: Wed, 27 Aug 2008 10:09:34 -0700

> using PDF (for everything).

Agreed on all points.  For those of us who spend any significant
amount of time working with RFCs on-screen, it seems like a minimal,
clean, HTML presentation has been the best available technology for
about a decade now.  -Tim
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Julian Reschke <[email-masked]>
Date: Wed, 27 Aug 2008 19:16:56 +0200

> I thought IE8 had some fairly annoying limitations on their use?

Potentially. I didn't try.

> print PDF correctly on most computers than it is to print plain text.

The HTMLized RFC versions on http://tools.ietf.org/html print well from 
browsers (as they have the necessary CSS-for-print stuff mixed in).

BR, Julian

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 27 Aug 2008 15:42:12 -0700

> I believe the IETF and the W3C came up with a better format for that a 

Yup.

And that really underscores the challenging of juggling competing goals:
Long-standing benefits of a readable/searchable text source, against the
considerable improvements in readability that can be achieved with more robust,
multi-media presentation capabilities.

The Braden/Klensin proposal is seeking a balance of goals.  This is the 
fundamental point about their proposal that we need to appreciate.  And to the 
extent that there is debate about their proposal, it needs to start by 
reconciling goals.  The rest is quibbling about details, albeit possibly 
important ones.

Not surprisingly, I'd wish for different details, but want to re-emphasize that 
we are now (merely) haggling price.

The benefit of the balance they struck is that it is pretty minimal, although 
yes I did not some suggestions for simplification. Still, this defines an 
important baseline reference.

The detriment is that I think its *benefits* are too minimal.  It proposes an 
enhancement that requires a number of procedural and technical changes.  I 
believe that significantly more benefit can be obtained for the same order of 
change.

John C Klensin wrote:
 > That is it.  No intention to solve all possible problems, just
 > what appears to us to be a large and growing subset in which
...
 > It is our belief that, modulo some tuning, this proposal is
 > likely to be able to get community consensus.  Based on the

One thing that will help resolve things is to be very clear about what goals 
need balancing.  The Braden/Klensin proposal states some.  I suspect there are 
some others that are implicit or at least might need stronger emphasis.

My own suggestion for the list of goals expands upon the ones of the B/K proposal:

   1. There is a single, master file for document text.

   2. Base text is able to be edited, viewed, compared and searched with 
extremely minimal set of tools, such as a classic text editors, and the like.

   3. The master file is subject to formatting constraints, to improve 
readability when using simple display tools.

   4. All formats use strictly open standards.

   5. Any mapping from the master file to a presentation format must only depend 
upon well-tested, reliable tools that are available as open-source.

   6. Multiple display forms must be supported, notably scroll-form for screen 
display and paginated form for printing, as well as classic, basic IETF ASCII 
paginated format.

   7. Figures can be encoded in classic ASCII art and/or in a graphics format.

   8. Enhanced display formats can support basic font changes, within 
IETF-defined criteria, since this can enhance readability.

   9. Naming conventions tightly link additional files that are used by the 
master file.

   10. Changes seek to have as much automation as possible for the technical 
aspects of RFC development and production.

   11. Format for the master file should facilitate later revision efforts.

John C Klensin wrote:
 > Actually, you don't care because there should be no requirement
 > that the image file come to the RFC Editor in PDF/A and the
...
 > What goes to the RFC Editor is
...
 > 	
 > 	(ii) An image file in some format the RFC Editor is
 > 	willing to deal with.  Certainly standard PDF would be

I think this promotes a singular mistake, namely potentially *additional* work 
for the RFC Editor.  Where possible, we should seek to move the technical burden 
to authors.  Given the current state of editing and publishing technology, the 
"where possible" is almost everywhere.

I'm told that xml2rfc produces output that is very, very close to what the RFC 
Editor can publish directly... But it is still slightly shy of perfect.

I urge our finding how to close that gap.  Perhaps there are tweaks to xml2rfc. 
  Perhaps there are tweaks to the RFC Editor's requirements.  Whatever they are, 
my own perception of the different outputs that xml2rfc generates is that they 
seem entirely satisfactory for IETF use.

John C Klensin wrote:
 > (1) xml2rfc may be widely used, but it is not a requirement or a
 > standard.  It actually has no formal status in the IETF.

The B/K proposal calls for a change in formal status, for PDF.  Why, then, is 
xml2rfc out of bounds for consideration, particularly given how dominant its use 
has become?

And, by the way, we need to be careful to retain the ability to have simple, 
ASCII-only RFCs.

(If we get the document naming conventions correct, I suspect we can even make 
it possible to have xml2rfc *or* simple ASCII and still incorporate pointers to 
real graphics. I think this would be compatible with the approach that Paul 
Hoffman suggested.)

> John C Klensin wrote:

xml2rfc tools are free and can be used online or the desktop. The source is 
text-processable. All forms of output are processable with wide variety of free 
and commercial tools.

>> that are less readily available (or significantly expensive).

This statement does not seem to be correct, with respect to xml2rfc.

Anyhow...

By way of example, concerning the combination of ASCII and true image figures, 
take a look at the 3 forms of output my own email-arch draft now generates, 
notably in terms of figures.  Take a look at the "unreleased" -11-14dc version:

   <http://bbiw.net/recent.html#emailarch>

Through 4.5 years of development, I only used ASCII art.  This was particularly 
painful for the largest figure.  For the final stages, I've *added" pretty versions.

What is facinating is that the ascii art remains and when html is being 
displayed, if it cannot find the graphics file, it shows the ascii art.  Very 
nice fallback safety mechanism.

So...

I've just submitted an independent revision to draft-rfc-image-files-00 which 
expands upon it, to satisfy the goals listed above.

Besides being submitted as an I-D, the draft is available in the usual xml2rfc 
alternate formates, and includes diff listings against draft-rfc-image-files-00, at:

   <http://bbiw.net/recent.html#rfcmedia>

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 28 Aug 2008 01:52:18 +0200

> That's true, but I would expect *less* discussions as compared to
> just using PDF (for everything).

For the now dead IONs the restriction was roughly "no nonsense".
I guess we could hash out a flat DTD for an IETF subset of XHTML
1.0 transitional working with old HTML 3.2 browsers, while still
allowing the CSS for decorations.

No data URIs of course.  If the goal is one file we could try to
fix the weird ooXML "pack" non-URI scheme (a persistently parked
draft, they know that I'd request HISTOTRIC one second after it
expires, therefore they keep it alive, a congenial subversion :-)

 Frank
-- 
<http://tinyurl.com/5q82dg>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 28 Aug 2008 09:30:39 +0200

On Tue, Aug 26, 2008 at 04:04:02PM -0700,
 SM <[email-masked]> wrote 
 a message of 37 lines which said:

> Anyone can write tools without undue cost to read, parse, search and
> produce documents in that format.

Read, search and produce, OK. Parse, no, unless you're joking.

Parsing RFCs is incredibly difficult. If you doubt it, please write a
Perl/Python/Javascript/Lisp/whatever program to extract from a random
RFC:

* author(s)
* title
* list of sections
* normatively referenced fellow RFCs

and post it here.

Of course, PDF is even worse in that respect and so I would not
support the idea of switching to PDF. What I wanted to emphasize is
that the biggest problem with plain text (wether it is ASCII or RFC
5198 is irrelevant) is the extreme difficulty of parsing and therefore
of extracting metadata.

RFC 2629 rules :-)

---

From: SM <[email-masked]>
Date: Thu, 28 Aug 2008 09:38:43 -0700

>Parsing RFCs is incredibly difficult. If you doubt it, please write a

I'm sure it is.  The point was that it would be more difficult if the 
text has to be extracted from a PDF.

Thanks to the IETF Tools team, one can compare the two I-Ds by going 
to 
http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/internet-drafts/draft-rfc-image-files-00.txt&url2=http://www.ietf.org/internet-drafts/draft-crocker-rfc-media-00.txt

Regards,
-sm