postel@VENERA.ISI.EDU (02/03/90)
Hi: RFCs have been traditionally published in ASCII text. The IAB has decided that RFCs may be published in PostScript. This decision is motivated by the desire to include diagrams, drawings, and such in RFCs. It also allows authors that normally work with document production tools that produce PostScript output to use their normal tools. PostScript documents (on paper, so far) are visually more appealing and have improved readability. PostScript was chosen for the fancy form of RFC publication over other possible systems (e.g., impress, interpress, oda) because of the perceived wide spread availability of PostScript capable printers. It has been pointed out that many RFC users read the documents online and use various text oriented tools (e.g., emacs, grep) to search them. Often, brief excerpts from RFCs are included in e-mail. These practices are not yet practical with PostScript files. Therefore, the IAB has also decided that when ever an RFC is published in PostScript a secondary version of that RFC is to be made available in ASCII text. This secondary version may be missing some elements of the primary version (e.g., diagrams), and be formatted differently. Work is in progress to provide the secondary versions of the PostScript RFCs already published. It has also been pointed out that PostScript is less standard that has been assumed and that several of the document production systems that claim to produce PostScript actually produce nonstandard results. It may be necessary to identify a set of document production systems authorized for use in production of PostScript RFCs, based on the reasonableness of the output files they generate. --jon. (The RFC Editor)
skl@van-bc.UUCP (Samuel Lam) (02/03/90)
In article <9002022237.AA21479@bel.isi.edu>, postel@VENERA.ISI.EDU wrote: >... the IAB has also decided that when ever an RFC is published >in PostScript a secondary version of that RFC is to be made available >in ASCII text. Thank you very much!!! This decision is appreciated. -- Internet: <skl@wimsey.bc.ca> UUCP: {van-bc,ubc-cs,uunet}!wimsey.bc.ca!skl
haverty@BBN.COM (Jack Haverty) (02/04/90)
Some documents will be very difficult to understand with only ascii content, e.g., documents with diagrams, graphs, and other pictorial information. Request for clarification: is the intent of this policy to create ascii images of RFCs which are complete and understandable in isolation, or to create ascii versions of RFCs for ease of computer searching, extraction of text, and the like? Jack
kasten@interlan.interlan.COM (Frank Kastenholz) (02/05/90)
I think that this is an excellent solution to the Postscript vs Ascii debate. My only concern is that there may be useful information that is lost in going from Postscript to ASCII. For example, if the TCP RFC were originally done in Postscript and 'ported' to ASCII, the TCP header and state transition diagrams could be lost. Will any effort be made to preserve these diagrams? Also, given the possible information loss, which version of the RFC will be the 'official' one? As an aside - maybe diagrams could be made available via "FAX over TCP"? I seem to recall that there was a discussion thread on the TCP/FAX topic on the TCP-IP list within the past 2 or 3 months so there is some interest in the general subject. Cheers Frank Kastenholz Racal Interlan
ihm@NRC.COM (Ian H. Merritt) (02/06/90)
haverty@BBN.COM (Jack Haverty) says: >Some documents will be very difficult to understand with only ascii >content, e.g., documents with diagrams, graphs, and other pictorial >information. > >Request for clarification: is the intent of this policy to create ascii >images of RFCs which are complete and understandable in isolation, or >to create ascii versions of RFCs for ease of computer searching, extraction >of text, and the like? > >Jack Jack, I have access to a PostScript printer. It is tough to grep through a paper copy of an RFC, no matter how 'pretty' it may be. The PostScript format files are of little use in this regard as well. For my purposes and per many of the other comments I read in the initial flurry of complaints spawned by the first few PostScript-only RFC's, it is this (computer searching as you suggest in your question) that is most important about plaintext. Once the RFC has been mechanically identified, we can get a paper copy. Also, it is useful to be able to include quotes from the RFC in E-mail without having to type them in from a paper copy (extraction, as you also suggest in your question). Retyping, after all would somewhat defeat the purpose of this marvelous electronic communication system we all know and love. -i Ps: Thank you Jon Postel. -- US Snail: 2380 Rose Avenue; Oxnard, CA 93030 U.S.A. tel. 805-485-2700 InterNet: ihm@NRC.COM
haverty@BBN.COM (Jack Haverty) (02/13/90)
Re: Postscript/ascii RFCs Sorry for the gap in this "conversation" - I spent a week at COMNET electronically incommunicado in a sea of products from the communications industry! Vint clarified the intent of the policy for me - to provide machine-processable versions of all RFCs for ease of searching, etc. I fully support that notion; after all, we're supposed to be applying computers and communications to getting work done in a better way than manual brute-force techniques. At the risk of opening yet another round..... Speaking of brute force, perhaps interesting documents on the Internet should be made available in SEARCHABLE format, as the next obvious step beyond ascii and FTP. By this I mean supplementing the "file servers" which are sprinkled throughout the system with database servers in which the documents are stored, and which could be queried through some kind of language (SQL, grep, whatever). Rather than forcing everyone to FTP all of the files to all of their local computers, and search them there, we could allow people to send queries to the server machine(s) to find the identity of relevant documents which could then be transferred. This idea is of course hardly new - the "DataComputer" on the Arpanet in 1975 or so provided such a capability, and services such as IQUEST accessible through networks such as CompuServe provide similar capabilities for the more formal publications. Perhaps such a capability should now be on the Internet? Is anyone thinking or working on this? Maybe it already exists and I'm just not aware of it? Jack