John, You mean that we should update the current medieval print format to take advantage of the best technology available to the Victorians? Why go to all that trouble to create infrastructure to support an obsolete document format when we can get all the infrastructure required to support a modern, open format that delivers professional results for free? Moreover there is a much higher probability that third party tools will support a common W3C/IETF format than an IETF only format. Phill > -----Original Message----- > From: John C Klensin [mailto:john-ietf@xxxxxxx] > Sent: Friday, June 16, 2006 1:14 PM > To: John R Levine > Cc: ietf@xxxxxxxx > Subject: Image attachments to ASCII RFCs (was: Re: Last Call: > 'Proposed Experiment: Normative Format in Addition to ASCII > Text' to Experimental RFC (draft-ash-alt-formats)) > > > > --On Thursday, June 15, 2006 09:39 -0400 John R Levine > <johnl@xxxxxxxx> wrote: > > >> 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. > > > > In case it wasn't clear, my quite informal suggestion was that one > > might attach a few GIF illusttrations to an ASCII document, sort of > > like a paper book that has a few color plates glued in the back. I > > agree it would be nuts to put text into GIF. > > I continue to wonder whether what we should be doing here is > not to invent a new normative document format, but to figure out how > attach image-type figures to ASCII RFCs. "plates glued in the > back" is almost exactly the same as the analogy I have been > thinking about. > > So, while I don't think this particular experiment, as > described, is plausible, there are two ideas I'd like to see > proposed, perhaps experimentally, for the future: > > (1) A PDF approach, but with PDF carefully researched and > profiled (to include searchability and copy-and-paste > extraction in addition to stability and very wide > availability for readers and formatters) and a back-out plan > should the community not be happy about the experimental results. > > (2) Some specific and well-thought out proposals for a > "figure supplement" to RFCs with multiple figures in a single > file, good naming conventions, and so on. A PDF file of > figure-images might be the right thing to use; there might be > better ones. > But, as a strawman, we might have. > > rfcNNNN.txt (as now) and > rfcNNNN-figs.pdf > > Where rfcNNNN.txt would contain things like > > Figure 3. A Left Handed Foogle (please see > supplement) > with or without a rudimentary ASCII drawing. > > and rfcNNNN-figs.pdf would contain numbered and > captioned figures, one per page. > > There are probably better ways to do this -- I haven't > thought through the details -- but I think that there is the > core of an interesting idea in this. > > It would _not_ be a small experiment: it implies changes to > our archives, changes to indexing systems, more work for the > RFC Editor in verifying that figure numbers, captions, and > content were consistent between the ASCII RFC and the > "plates", and so on. But it would appear to me to point to a > way forward that would not share most of the disadvantages of > normative PDF files. > > john > > p.s. When I said "should not have been last-called" in a > prior note, I wasn't trying to suggest that the _idea_ was > obviously dead or bad. I was trying to suggest, instead, > that, when an idea is discussed at length on the IETF list > and a number of issues raised with it, it is normal for the > IESG to insist that any version of the idea that is > subsequently to be last-called > address most of those issues in some substantive way. "We > don't see X as a problem" may be appropriate; pretending > (deliberately or by accidental omission) that X was not > raised or discussed as an issue is usually not. The fraction > of the Last Call discussion that essentially duplicates the > discussions of some months ago is probably testimony to the > wisdom of that principle. > > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf