--On Monday, 19 June, 2006 09:32 -0700 Bob Braden
<braden@xxxxxxx> wrote:
> *> 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.
> John,
>
> This discussion has seemed to overlook that fact that for the
> past 20 years or so the RFC Editor HAS offered a .ps/.pdf
> alternative output format; it just can't be normative. With
> very few exceptions, a protocol specifications (that's what we
> are supposed to be documenting here, the last time I checked)
> can be defined normatively quite satisfactorily using ASCII.
> But, sometimes it is helpful to add additional explanatory
> (non-normative) diagrams, equations, etc., which can be in an
> auxiliary .ps/.pdf version. I believe there are roughly 50
> worked examples of this approach among the 4000+ RFCs in the
> archive.
>
> The one caveat is that processing RFCs with a .ps/.pdf version
> does take more time and effort, so we hope it does not happen
> very often.
Bob,
I certainly was not ignoring that possibility, and have
commented on it several times. However I see three major
disadvantages of it which may or may not be subsumed by "more
time and effort". The proposers of this particular experiment
would add a third, which is precisely that the ps/pdf forms are
not normative. Those disadvantages are, in increasing order of
importance for this discussion (but perhaps not more generally),
are:
(1) Because the ps/pdf files are not normative, we haven't spent
nearly enough time making sure that they are long-term readable.
Perhaps we should; perhaps we now assume that, since they are
not normative, we don't care. But there have been, e.g., many
postscript files of the vintage of last 1989 that are not
readable by modern tools without at least some fussing.
(2) If I prepare an RFC draft using some mechanism which
produces a document in form X, where X might include
* ASCII text, via emacs or vi, with a post processor for
headers, footers, or page numbers
* xml2rfc
* MSWord plus some templates and post processing
* nroff with a profile different from the RFC Editor's standard
* LaTeX or TeX
* Obscure word processor 7b
then the RFC Editor makes changes, possibly extensive and
returns the revised document in an ASCII text format. No
matter how good my tools are, I'm going to have to do
considerable, mostly manual, work to retrofit those changes into
my source. The retrofit will be easiest with the fourth, but
nroff preparation is part of what some of us have never used and
others would like to get away from. It will be second-easiest
if I prepared the input with the ASCII editors, but they won't
help me produce PS/PDF for the textual part of the document
(which we both assume will be most of it). For the others,
based on experience with three of the four, it has considerable
costs in time and effort, costs that are high enough to act as a
considerable deterrent to ever getting around to producing the
PDF or PS forms.
If that deterrent is what the RFC Editor is after, perhaps on a
"if we make it hard, then only those who think it is really
important will put in the time and create the extra work for
us", I wish you would be more candid about it with the
community. But I haven't concluded, so far, that it is
intentional.
But, if it is not, then one of the discussions we should be
having, IMO, is about selecting one or two additional input
formats (xml2rfc and Word stand out as candidates to me) in
which the RFC Editor is willing to accept input documents and
return editing results to the authors for review. Doing so
would solve a large number of problems, not only wrt easily
producing PS/PDF forms when needed, but for producing revised
versions of the relevant documents for updated standards, etc.
That suggestion has been made several times; as far as I know,
the discussion has never gotten off the ground.
(3) Finally, if one adopts the "plates in the back" model, the
PDF (or whatever) document contains the illustrations and _only_
the illustrations. That makes it fairly insensitive to the RFC
editing process. In that process, almost all changes are to
text. Even if the figures are changed, that usually requires
significant negotiation between authors and RFC Editor and there
is still more text. So I suggest that, generally, we would find
that, in a "text plus figures" model, the editing process would
generally change the text only, permitting the figures/images to
remain unchanged. That would considerably reduce the burden of
both preparation and checking relative to what is now required
to produce, retrofit changes, and publish a PS or PDF document.
As I have said in response to other notes, I'm not convinced
that "text plus figures" (or "image attachments") is a good
enough idea to be worth writing up and considering -- in terms
of either IETF needs or RFC Editor workload. But it has enough
advantages relative to either version of the status quo
--"ASCII-only" or "of course you can produce a version in PDF if
you are motivated enough and we hope you won't get motivated
very often"-- that I think it needs a bit more consideration
than it has been getting.
Of course, if the community approves the current "normative PDF"
proposal, that discussion would be moot. But I don't think I
see the discussions headed in that direction (just personal
opinion, of course).
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf