>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? R's, John _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf