> That's why I suggested GIF. Like ASCII, GIF has its
> shortcomings, but its definition hasn't changed in 16 years
> and I've never seen GIF software that doesn't interoperate.
But one of the important criteria for an acceptable alternate
form, one which came up in the earlier discussion on this list,
is that the format be searchable. With PDF, page-image forms
may not permit that but, as far as I know, searching inside GIFs
is impossible except perhaps via fancy AI tools and heuristics.
Complete agreement here. GIF may win on stability, but loses badly in several
other ways. In addition to not being searchable, I really don't relish having
to create a revision to a long document starting with only pictures of the text
the document contains.
More generally and to reinforce a point that I think Bob Braden
made, I believe there was general consensus on this IETF list
when the earlier discussion occurred that PDF, if it was to be
used, be narrowly profiled so as to permit only those variations
that appeared to be stable and meet various other criteria,
notably ease of searching and extraction by text copying
operations.
Bingo. And this is the problem with the experiment as it is presently
formulated: It tests nothing of significance. It's completely obvious that we
can create PDF RFCs. It is equally obvious that block diagrams and equations
done in ASCII are inferior in appearance to those done using more powerful
formatting tools. All of these things get a 10 on the "duh" scale.
A genuinely useful process experiment in this space would have to:
(0) Nail down format requirements. Perhaps the requirements are the same
as for ASCII documents, but I doubt it.
(1) Carefully examine the subsetting and profiling issue and decide what
does or does not need to be done.
(2) If subsetting is needed tools need to be identified that conform to
those subsetting guidelines. Additionally, we almost certainly need a
validation tool that checks to see if the guidelines are being followed.
(3) Given how popular xml2rfc is I think it makes sense to at least look at
how it would best be used to produce PDF documents containing equations and
block diagrams.
(4) The criteria for assessing the experiemnt need to address our need for
long term accessibility.
Now, it may or may not be appropriate for the document defining the experiment
to specify all of this stuff. But if the document doesn't specify these things
it at least has to specify the processes that are going to be used to create
these specifications.
I will also point out that the current draft talks about there being
a "phase 2" experiment involving XML or OpenOffice as input formats. The
vagueness of this part of the proposal is very disturbing - additional
details either need to be given or this material needs to be removed.
Yet another problem with the current proposal is the security considerations
section, which basically says there aren't any. Given that this document
proposes using PDF in its full and unrestricted glory it should be obvious why
this isn't true.
It seems to me that this draft, by omitting
specifics about versions and features of PDF to be permitted
and, if it isn't obvious, how the submission or editing process
automatically verifies that those rules were followed, is not
responsive to that consensus. Arguably, on that basis, it
should never have been Last Called.
I can sort of justify last calling it in order to force people to review it. I
certainly hadn't read it all that carefully before. But now that I have read
it, my position is that we urgently need a process experiment in this space,
but this is absolutely not the right one to run.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf