John,
I believe - for the record - that Post-Script is also
allowed.
--
Eric
--> -----Original Message-----
--> From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org]
--> On Behalf Of John C Klensin
--> Sent: Thursday, January 05, 2006 11:28 AM
--> To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf(_at_)ietf(_dot_)org
--> Subject: Re: Baby Steps (was RE: Alternative formats for IDs)
-->
-->
-->
--> --On Thursday, 05 January, 2006 08:25 -0600 "Ash, Gerald R
--> \\(Jerry\\)" <gash(_at_)att(_dot_)com> 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 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