> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf