On Thu, Mar 11, 2010 at 10:52 AM, Andrew Sullivan <ajs(_at_)shinkuro(_dot_)com>
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(_at_)shinkuro(_dot_)com
Shinkuro, Inc.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf