--On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
\\(Jerry\\)" <gash@xxxxxxx> wrote:
> Happy New Year to all!
>
> Many thanks to Yaakov for his excellent handling of the list
> discussion. I'm not very surprised with the way it has gone.
> Déjà vu all over again :-)
>
> The challenge is to focus the discussion to try to reach
> consensus on moving forward with a process change, i.e., we
> need to take baby steps to make progress.
>
> I'd suggest we try to reach consensus first on the following:
> Alternative format(s) for IDs, in addition to ASCII text,
> should be allowed.
>
> One requirement/motivation for this change (as set forth in
> the ID) is to be able to include drawings and diagrams with
> something much more flexible than ASCII art.
>
> Based on the prior discussion of 'ASCII art', and the current
> discussion, I see few people arguing that ASCII text is all we
> need and that no other formats should ever be allowed.
Even those of us who are strongly supportive of ASCII as our
primary base format and those who believe that the effort needed
to simplify illustrations and diagrams sufficiently that they
can be accurately represented in ASCII artwork is helpful in
forcing clarity are reluctant to say "never".
> Let's set aside for now which format(s), and take that as a
> later step if we can take this first step.
Jerry, one of the nice things about baby steps is that you
sometimes discover that the baby learned to take the steps
without any instruction.
Unless the IESG has changed the rules while I was not looking,
it has been permitted to post I-Ds in PDF in addition to ASCII
for some years. I find it interesting that it has not been taken
advantage of more often (and, for the record, I'm one of those
who has taken advantage of it). When it has been done for
artwork purposes, the artwork in the ASCII version has sometimes
been pretty rudimentary. In practice, whether it is "good
enough" has been made on a case by case basis by WG Chairs and
WGs or, for non-WG documents, by whether or not the relevant
people are willing to read and consider those documents.
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. If you do more of it,
perhaps we can move some of the interoperability problems into
the realm of actual IETF experience and out of the realm of
extrapolation from other situations mixed with pure speculation.
Free advice: if and when you want to move beyond that point,
drop (or isolate into separate documents):
(1) Recommendations for IETF process change or specific
ways to determine consensus. They should be separate so
they can be considered separately, using an appropriate
process.
(2) Distinguish clearly between what is required or
tolerable for I-Ds and what is required or tolerable for
RFCs. RFCs, in general, put a less strong requirement
on easy extraction and modification of text than I-Ds.
And, since I-Ds in theory expire after six months, you
might be able to convince the community that the "be
sure it can be read twenty years later" requirement for
archival documents should not be taken as seriously for
I-Ds.
(3) Recommendations to permit any format that is (i)
proprietary, or (ii) dependent on particular software
for processing where that software carries either high
costs, onerous licensing requirements, or licensing
requirement that attempt to prohibit the development of
independent tools to work with the format, or (iii)
significantly operating-system dependent, or (iv)
significantly version-dependent in the sense that the
documents are not forward and backward compatible.
I would suggest to you that the fact that Word hits a jackpot by
satisfying all of the negative criteria in that third suggestion
is the reason why it has been regularly rejected for IETF
posting and working use in the past and is almost certain to be
rejected in the future. If you want to consider that déjà vu
(or deja vu, for ASCII-readers), it certainly is in the sense
that we have been here before... but that rather misses the
point: it has been rejected in the past for substantial and
substantive reasons and the déjà vu situation, for me at
least, is that someone decides to bring it up again every few
years as if it had never been considered in the past.
regards,
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf