John, I believe - for the record - that Post-Script is also allowed. -- Eric --> -----Original Message----- --> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] --> On Behalf Of John C Klensin --> Sent: Thursday, January 05, 2006 11:28 AM --> To: Ash, Gerald R \(Jerry\); Yaakov Stein; ietf@xxxxxxxx --> Subject: Re: Baby Steps (was RE: Alternative formats for IDs) --> --> --> --> --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 mailing list --> Ietf@xxxxxxxx --> https://www1.ietf.org/mailman/listinfo/ietf --> _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf