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