>> PDF/A is a deliberately-limited format designed specifically for >> archival purposes. > >And is clearly a non-starter because I have no idea how to produce PDF >so limited, not idea how to test a PDF to see if its "PDF/A", etc. There are certainly arguments against PDF/A, but this doesn't strike me as a very strong one. You know how to produce an ASCII I-D, which looks somewhat like an RFC, but I doubt that you know how to produce an RFC. (I don't think anyone does other than the handful of people who have actually done so, since the list of rules and formatting twiddles for the RFC style is not perfectly documented.) Were we to adopt PDF/A as a format for RFCs, what would matter is that the RFC production house knew how to create PDF/A files. Document authors would continue to send in I-Ds in whatever form they send them in, with some extensions for figures and non-ASCII characters. Indeed, I know plenty of people these days who have no idea today how to produce an ASCII file with only tab, CR, and LF formatting characters. This does not mean they are morons, it means that the text processing tools that people use today are different from the ones we used in 1973. If someone writes an I-D using xxe to produce XML which xml2rfc turns into the text form that idnits wants, that doesn't make him less manly than someone who edits with teco and codes the nroff commands by hand. (I had enough of that in my thesis in the 1970s.) A major reason that the discussion of RFC formats never gets anywhere is that it is really a discussion of the process more than about particular formats, and we don't do process very well. The current process uses input and output formats that are similar enough that people wrongly think they're the same, even though of course they are not. Many people seem to assume that if we picked a new output format, we would necessarily change the input format to be "the same" as the output format, which I think would be a terrible idea. The input formats need to be reasonably easy for non-experts to create, and to be structured enough so that validation tools can work with them. The output format basically needs to be displayable, printable and searchable. There is no reason they have to be at all similar. If I were tsar, I would probably leave the input format as xml2rfc, give or take tweaks for figures and a broader character set, but make the output format a more rigidly structured XML that can be mechanically and consistently transformed into a variety of display formats. If you want nroff-style RFCs, that's a display format. R's, John _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf