Re: Image attachments to ASCII RFCs (was: Re: Last Call: 'Proposed Exper

I could not agree with John more on the desirablilty of a tighter definition 
of PDF and the reasonableness of "plates in the back".
And about the usefulness of including a list of places we've already been.

I note that we use issue trackers in a number of working groups, but this is 
an individual submission... until we come up with a better plan, keeping an 
issues list in the draft might at least cut down on the number of times we 
deja vu.
Spencer

> --On Thursday, June 15, 2006 09:39 -0400 John R Levine <johnl(_at_)iecc(_dot_)com> 
> 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(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf