--On Saturday, 23 August, 2008 14:55 +0200 Frank Ellermann
<hmdmhdfmhdjmzdtjmzdtzktdkztdjz(_at_)gmail(_dot_)com> wrote:
John C Klensin wrote:
My hope is that we can discuss and figure out whether
the community likes and will accept the general idea.
What *is* the general idea ? If it's "attaching" one
or more figures / images to an RFC I'm fine with it.
That is it. No intention to solve all possible problems, just
what appears to us to be a large and growing subset in which
pretty-printed figures, images, and the like would significantly
add to RFC comprehensibility without having to reopen the debate
about alternate base formats, searchability, etc., etc.
It is our belief that, modulo some tuning, this proposal is
likely to be able to get community consensus. Based on the
outcomes of the discussions that have arisen every several years
for what seems forever, there is little or no hope getting
community consensus for any of the "publish RFCs in my favorite,
pretty-printed, format with inline images instead". I
sincerely hope that we can have a discussion about this proposal
without reopening that debate and/or that people who want to
have that debate will consider getting this approved and
deployed as a useful step in the direction of their goals since
it would demonstrate the utility of better illustrations.
Technical detail, for some years we could still stay
within the limits of 8+3 like so:
rfc5555.txt, rfc555a.svg, rfc5555b.gif, rfc5555d.png
Note that we already have rfcNNNN.txt.pdf and some other
relationships that take us outside 8+3, Internet-Draft naming
conventions that are (as Julian pointed out indirectly) _far_
outside 8+3, and so on. So I'm not sure what you are trying to
preserve here... it seems to me that we abandoned 8+3 years ago.
As soon as you have "more than one" part you can as
well go for the real thing, each figure in a part,
skip the ugly container. Or pick SWF instead of PDF,
I'd like it better. What about ordinary TGZs if you
insist on a container format ?
"Anything PDF" is a serious showstopper from my POV.
One of the concerns in putting this proposal, and a major reason
you didn't seem something like it several years ago, is the
question of whether _any_ format other than plain ASCII text is
sufficiently stable long term. PDF (and preferably PDF/A) was
chosen because, not only is there a stable pair of ISO
standards, but PDF/A is considered stable by the archival /
depository librarians, whose traditional criterion for stability
involves a considerably longer timeframe than even the IETF.
No other contemporary image, image-file, or page definition
format comes even close whether you (or I) "like it better" or
not. And there is really no issue about a container format
here, even if you consider a multi-page PDF file to be such a
format. If one gets involved with containers, even "ordinary
TGZ", and one immediately gets involved with questions about
availability and stability of decoders. At least Multics/
first-generation-U**X archive files, like self-extracting shell
scripts, can be disassembled with a text editor, but I'm not
sure I'd recommend them either.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf