ietf
[Top] [All Lists]

ancients-moderns dispute (was: PDF, Postscript, and "normative" versions (was: Re: Baby Steps (was RE: Alternative formats for IDs)))

2006-01-06 07:12:20
We need to get out this ancients vs moderns dispute. Ancients saying they have no experience of actual need by moderns, and moderns saying this is because the ancient culture does not permit it.

Is there an objection to quote non-ascii documents hyperlinks? I suppose not.

Why not to just to proceed step by step and experiment? Let create an optional non-ascii art RFC-Editor repositories, for images quoted in RFCs. This will not permit non-ASCII art to be normative but will permit non-ASCII art to be _better_ descriptive in a first time. Experience will show if there are many such images. If there is a real need for normative non-ASCII art, it will provide experience to create a non-ASCII art IANA registry making sure they will survive, at an adeqate place.

jfc

At 21:00 05/01/2006, John C Klensin wrote:
No, I'm not saying that.  But the distinction I was trying to
make is pretty subtle.   The ASCII is the ASCII.  "Normative"
doesn't mean much for an I-D (see below for RFCs).  The rule
about PDF or Postscript versions is that they are supposed to be
equivalent to the ASCII (and vice versa).  But "equivalent" gets
a little subjective...

We know perfectly well that there are a few cases in which, no
matter what one does with ASCII art, it is not sufficient to
make whatever point is being made and supplemental text --more
description, in words, of what would be in the pictures-- will
not help much either.   Now, part of the point that the people
who have said "if you can't do it in ASCII art, you generally
shouldn't be doing it -- use the ASCII art and write a better
description" are making is that the cases in which we really
need fancy pictures are very few and that, except for those
cases, we are better off without them or at least being able to
treat them as strictly supplementary.

Before I go on, I continue to be fascinated by the observation
that, each time the "we really need pictures and fancy
formatting and need them frequently" argument comes up, the vast
majority of those who make it most strongly are people whose
contributions to the IETF -- in designer, editor, or other
leadership roles-- have been fairly minimal.  Now, of course,
some of them might argue that our current rules prevent them
from contributing and that, if only we would let them submit
documents written with the DeathRay word processor in Klingon
script, not only would their productivity rise, but everyone
else's would too --once we bought copies of DeathRay, learned
Klingon, and persuaded UTC to get the characters into Unicode.

However, that aside, assume that you are describing the new Mona
Lisa protocol, and that it is really impossible to adequately
describe the protocol without a high-resolution scale picture of
the Mona Lisa overlaid with your coordinate system.  The ASCII
form of your document could (and must under our current rules)
describe the coordinate system, include all of the measurements,
and describe what you are doing with them.  That text is
normative (and the important thing is "the text", not whether it
is in ASCII or not) and has to be.  But it is going to be _very_
hard for anyone to understand your protocol without seeing the
picture unless they have a good mental image of it.

Under those conditions, our precedents are that you can probably
convince the WG/WGchairs/ADs, and eventually the RFC Editor,
that a PDF document containing a picture of the Mona Lisa and an
ASCII document with

      _        -----
              /     \
      _       | o o |
              |  |  |
              | __  |
      _       |     |
              \_____/
      _
            |   |  |  |

as a substitute for that picture, with the marginal lines
roughly identifying your grid marks and coordinate system, is
"equivalent" or as close to it as one can get.  I would expect
that to be a hard sell.  I, personally, would _want_ it to be a
hard sell.  If it is really necessary, folks will figure out how
to get the picture (maybe only the picture, which will probably
not change from one version of the I-D to the next) to those who
can't handle the PDF (or Postscript).  But we have done it
before, all of the needed rules and procedures are in place, and
nothing new is needed other than your understanding that you are
going to have to get consensus that the artwork is vital before
making that great a departure between the ASCII and the PDF
versions.

>> Similarly, when PDF has been posted in order to exhibit
>> non-ASCII characters, it has proven helpful to have Unicode
>> character offsets (i.e., U+nnnn representations)  in both the
>> ASCII and PDF forms to ensure complete precision even though
>> the character-glyphs themselves appear only in the PDF form.
>>
>> So, consider the first baby step to have been taken: nothing
>> prevents you from posting an I-D in both ASCII and PDF today,
>> and the relevant sub-community will sort out, on a case by
>> case basis, whether the ASCII is good enough.
>>
> ...and if it's not the pdf version of the text including
> graphics will become the RFC?

No, they both become the RFC, and concerns about which one is
"normative" are just distractions.   For standards-track
documents, if it is posted as an official form of an RFC, it is
normative.   But, the more whatever-is-in-the-PDF differs from
whatever-is-in- the-ASCII --or, to put it differently, the more
the text depends on images that appear only in the PDF rather
than on the text standing alone or with ASCII art-- the harder
it is going to be for you to convince the community, the IESG,
and the RFC Editor that the PDF version is "equivalent" and, to
the extent to which it is obviously not equivalent, sufficiently
necessary to justify its posting.

    john


_______________________________________________
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