On Thu, Mar 11, 2010 at 10:52 AM, Andrew Sullivan <ajs@xxxxxxxxxxxx> wrote: > On Thu, Mar 11, 2010 at 10:32:49AM -0500, Donald Eastlake wrote: >> version/font/... problems are overblow, etc. As a data point, I would >> refer people to >> http://www.networkworld.com/news/2010/031010-hackers-love-to-exploit-pdf.html > > That appears to be an argument that Adobe's products contain bugs, and > not an argument that PDF/A (to pick the only reasonable PDF format one > would use for RFCs) is subject to such attacks. Yes and no. It's an argument the PDF tries to do way too much and is too complicated so software for it is likely to be buggy. > Your argument above is roughly akin to arguing that the web is a bad > publication format because some browser-of-choice is loaded with > exploitable flaws. The web is a bad publication format for the purpose of IETF Standard normative text because it tries to do to much, there are too many version of the various formats, too many proprietary additions, etc., etc. > 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. On the other hand, since I produced my first ID sometime in 1992, I've had no particular problem producing them with nroff and I've never had to hunt for, write, debug, or install a single piece of software. It's just there already, including in Mac OS X. > As a consequence, it has robust support from the > library world. Last I noticed, the IETF was not the library world. > These are the same people who use the > egregiously-flawed MARC format because that was the standard they > settled on several years ago. The same people, for that matter, who > have filing systems in various libraries dating to periods where "Holy > Roman Emperor" was a seriously powerful position -- because that's how > it's organized, and they're not going to change it for the sake of > innovation. So should I maybe say that the IETF format dates to the period when Jon Postel was a seriously influential individual and we are not going to change it for the sake of innovation? > The IETF format is specifically designed for, as far as I can tell, a > particular printer, long since out of production. ? The format worked fine on a variety of printers and still does. > It has robust > support from, well, the IETF tools team. We don't even have a > currently-maintained, up to date version of the software that was > supposed to be the new-look equivalent to *roff for generating > Internet Drafts correctly formatted. I have no idea what you are talking about here. People using newer fancier tools seem to keep having to get never versions of them, have problems when the tools aren't updated quickly enough, etc. Pretty much all I have to do, when boilerplate changes, is tweak a few include files. I don't particularly feel much need for "support" because, year after year, I just use whatever version of nroff is at hand and edit the nroff input with whatever source code editor is at hand. > I do get the arguments in favour of ASCII, though I think there are > some pretty serious countervailing arguments (like, for instance, that > we can't spell many contributors' names, to take an easy one). But > the RFC format _is not_ plain ASCII. Just ask anyone whose draft has > failed the increasingly stringent and lengthy list of IDNits tests due > to bad pagination in their I-D. The fact that not every sequence of code points from ASCII (to be precise: "USA Standard Code for Information Interchange", X3.4, American National Standards Institute, 1968) is a valid RFC does not negate that they are plain ASCII. It is of tremendous benefit that they are based on a dead (and dead simple) standard that no one is trying to "update" and "improve". Thanks, Donald > Best, > > A > > -- > Andrew Sullivan > ajs@xxxxxxxxxxxx > Shinkuro, Inc. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf