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