John, > > The advantage of using PDF is that we already use it, for both > > drafts and RFCs, and have a lot of experience using it. For > > most people it seems to work just fine. IMO PDF is our best > > shot in IETF at solving the graphics and equations issues > > raised in the draft. > Good. I actually agree, albeit very tentatively, that it is our > best shot. But I believe that saying "PDF" isn't adequate and > that a lot of work has to be done and specified before we are > able to use it as a normative or exclusive form for archival RFC > documents. ... > Note 1: I believe that constraints are imposed on _any_ > normative publication format for the IETF by the way we use > these documents. In particular, I believe that for files > containing the text of the specifications, searchability and > extractability are absolutely critical. One thing almost all > of those of us who have used PDF know is that some files have > those properties while others, often referred to as PDF image > files, do not. As soon as one gets to "need to be able to > search", then it is necessary to profile PDF so that the right > sorts of files appear. And, as I think Bob Braden pointed out, > one also has to have the tools in place to verify that. > > It is reasonable for you to disagree with the main premise of > the above paragraph, i.e., you may believe that we can dispense > with searching and extraction. If so, I would encourage you to > say that, since it would make the PDF profiling problem much > easier. My personal guess is that you would find it quite hard > to sell to the IETF community, but that is just a guess. Of course I believe that searching and extraction from PDF is highly desirable. However I think that is probably not easy, and it's likely that most people can't generate such searchable/extractable PDF files. I also doubt that searchable/extractable PDF is the secret sauce that will suddenly lead to agreement on this list. Besides the beatings administered RE the proposed experiment, we've seen the usual myriad proposals all over again. Based on these discussions, it's hard to see how any way forward other than "do nothing" will fly. Hopefully the IESG, in spite of the discussions, will propose a viable way forward. > Note 2: Unlike some others on the IETF list, I recognize the > importance of having illustrations in better-than-ASCII forms. > We may disagree on how often it is important, or even on whether > "important" should be a criterion or the criterion should be > closer to "convenience". I am nonetheless very sympathetic to > the arguments that fancy illustrations often hide fuzzy thinking > while the discipline of producing ASCII line art tends to > clarify thinking and encourage simplicity in design. Perhaps as > a result of those possible disagreement, we might disagree on > the relevance of ASCII versions of text and ASCII approximations > to the more advanced, image-type, illustrations. But we at > least share the belief that there is a problem in this area that > should be solved. I am not positive that even that position has > IETF community consensus. It's good that a key person such as yourself sees a problem that needs solving. Hopefully we'll find a way forward to solve the problem. Thanks, Regards, Jerry _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf