Re: I-D ACTION: draft-ash-alt-formats-01.txt

John Levine <> Wed, 01 February 2006 03:31 UTC

Received: from ([] by with esmtp (Exim 4.32) id 1F48i9-0003wa-CF; Tue, 31 Jan 2006 22:31:13 -0500
Received: from ([] by with esmtp (Exim 4.32) id 1F48i2-0003sW-HX for; Tue, 31 Jan 2006 22:31:10 -0500
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id WAA01875 for <>; Tue, 31 Jan 2006 22:29:20 -0500 (EST)
Received: from ([]) by with smtp (Exim 4.43) id 1F48sy-0002tP-Nf for; Tue, 31 Jan 2006 22:42:26 -0500
Received: (qmail 25486 invoked from network); 1 Feb 2006 03:30:49 -0000
Received: from ( by with QMQP; 1 Feb 2006 03:30:49 -0000
Date: Wed, 01 Feb 2006 03:30:49 -0000
Message-ID: <>
From: John Levine <>
In-Reply-To: <>
Mime-Version: 1.0
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION: draft-ash-alt-formats-01.txt
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

>First and foremost, if the input format is PDF, how will the RFC Editor 
>edit the document?  PDF documents are not editable.

Well, this particular proposal only makes PDF an output format, but
the question is still a good one.  Without an editorial process to
create the PDFs, it's not much of an experiment.

I think I understand many of the issues here, and they don't strike me
as being amenable to solution by wiggling the back end.  If the goal
is to allow prettier output while still maintaining the stability and
reusability of plain text, that practically demands an input format
that is plain text underneath (for the stability and reusability) but
structured enough that it can be converted mechanicically to PDF or
whatever.  The obvious candidate is an XML profile with some tools to
render it into output formats.  But now we have to face questions
about which version is authoritative (the XML, presumably) and whether
the PDF version is any more than a convenience for people who don't
like to read XML.  I could easily envision a system that archives the
XML along with renderings into PDF, HTML, or whatever else people like
to read, adding new translators as desired to offer them in whatever
trendy new format (podcast?) is popular next.

None of this is is a technical stretch.  What's hard is making sure
the processes work, for the people who write drafts and RFCs, the
people who do the editorial work, and the people who use the results.
So I have to ask, what part of this problem does an experiment that
just permits PDF output solve?


Ietf mailing list