karl@asylum.SF.CA.US (Karl Auerbach) (09/27/89)
RFC1124 came out with a discussion of policy issues of interconnected networks. Interesting and important stuff. Now, it seems, according to RFC1111, that postscript is OK for RFC's, (including postscript that was obviously generated by a word or text processor.) So: can anyone make reasonable comment on stuff that looks like what follows? Can anyone do a reasonable machine-based content search? Can I send it though my automated indexing tools? Can I make a nice e-mail reply with appropriate selections for context? No. I thought we were working on communications, not obfuscation. I propose that we ban postscript RFCs. --karl-- Selection from RFC1124: 727 789(Computer)U 1039(networking)S 1391(has)S 1511(become)S 1759(pervasive)S 2059(and)S 2187(basic)S 2359(to)S 2439(the)S 2551(conduct)S 2803(of)S 2887(scienti\256c)S 3119 873(,)U 577 957(e)U 577 873(and)U 705(academic)S 1001(activities.)S 1327(To)S 1431(provide)S 1675(the)S 1787(needed)S 2015(networking)S 2367(support)S 2607(to)S 2687(these)S 2859(activities)S 609 957(ach)U 733(of)S 817(the)S 929(agencies)S 1201(funding)S 1449(research)S 1713(has)S 1833(proceeded)S 2153(to)S 2233(establish)S 2509(one)S 2637(or)S 2721(more)S 2893(agency)S 577 1041(funded)U 801(computer)S 1097(networks.)S 727 1149(Recognizing)U 1115(the)S 1227(importance)S 1575(of)S 1659(such)S 1815(networking)S 2167(support,)S 2425(the)S 2537(Of\256ce)S 2741(of)S 2825(Science)S 577 1317(r)U 577 1233(and)U 705(Technology)S 1073(Policy)S 1281(\(OSTP\))S 1529(working)S 1793(with)S 1945(the)S 2057(appropriate)S 2409(personnel)S 2713(from)S 2877(the)S 601 1317(esearch-funding)U 1089(agencies)S 1361(on)S 1457(the)S 1569(Federal)S 1809(Coordinating)S 2213(Council)S 2465(on)S 2561(Science)S 2809(Engineering)S 577 1485(r)U 577 1401(and)U 705(Technology)S 1073(\(FCCSET\))S 1409(Committee)S 1753(on)S 1849(High-Speed)S 2217(Networks)S 2521(developed)S 2841(a)S 2897(set)S 3001(of)S 601 1485(ecommendations)U 1113(for)S 1221(the)S 1333(evolution)S 1629(and)S 1757(enhancements)S 2189(of)S 2273(scienti\256c)S 2557(and)S 2685(academic)S 2961 1569(e)U 577 1653(a)U 577 1569(networks.)U 907(These)S 1103(recommendations)S 1639(are)S 1751(described)S 2051(in)S 2131(three)S 2299(phases.)S 2557(The)S 2693(\256rst)S 2829(phas)S
koreth@panarthea.ebay.sun.com (Steven Grimm) (09/28/89)
In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes: >Now, it seems, according to RFC1111, that postscript is OK for RFC's, >(including postscript that was obviously generated by a word or text >processor.) > >I propose that we ban postscript RFCs. Agreed. Apart from really complex diagrams, I don't really see why it's necessary. If your RFC needs diagrams, make the necessary PostScript (or "pic" commands or whatever) a separate entity (rfcxxxx.5?) so your text will be readable by a wider audience. For those who like pretty-printed RFCs, though, there should be some way to get at them in their original uncooked nroff (or TeX, etc.) forms. I wouldn't mind having a nice copy of rfcxxxx from my LaserWriter, but I don't want it at the expense of people who can't view PostScript files. --- This message is a figment of your imagination. Any opinions are yours. Steven Grimm Moderator, comp.{sources,binaries}.atari.st sgrimm@sun.com ...!sun!sgrimm
nelson@sun.soe.clarkson.edu (Russ Nelson) (09/28/89)
In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes:
I thought we were working on communications, not obfuscation.
I propose that we ban postscript RFCs [because the on-line text is typically
unreadable]
Karl has a good point. We must bear in mind that PostScript has the
potential for better communication. I offer three solutions less
drastic than his total ban:
o Keep RFCs in a text-only format, and provide hints to a PostScriptizer
that knows what parts of the text should be filled, what parts of the
text are actually character graphics (like | and - ), and what parts
are tables.
o Restrict the types of PostScript that are acceptable to those that can
be textized by running them through a filter. That way, a user can
reconstruct a reasonable text version of the RFC.
o Create a PostScript interpreter that renders its output using a
unidirectional stream of ASCII characters.
Of course, a reasonable follow-up to this message is:
Russ! Good idea! Send me a copy when you get it written! :-)
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.budden@manta.NOSC.MIL (Rex A. Buddenberg) (09/28/89)
At the risk of sounding too rational, why don't you employ the CALS standards for what they were settled on for? (SGML for text, IGES for CAD, CCITT Group 4 for images). Is there an RFC/IEEE/ANSI/ISO standard for PostScript? Rex Buddenberg
zweig@brutus.cs.uiuc.edu (Johnny Zweig) (09/28/89)
It seems the best thing to do is to put PostScript stuff _somewhere else_. I like being able to do "lpr RFCxxx" and have the right thing happen -- and I imagine people who don't have PostScript printers around would be even more adamant on the point. It seems that complicated drawings ought to go into some kind of companion document that would be referenced (with good old [1]...[n] in plain ASCII) in the RFC-proper. I think that one can go a long way with - + | _ / \ < and >. Certainly anything that can't be described without a comlicated drawing ought to be rephrased. A picture may be worth a thousand words, but a standard should be clear enough not to need thousands of words. -Johnny Keep-it-simple
romkey@asylum.sf.ca.us (John Romkey) (09/28/89)
I'd suggest that rather than ban them, ensure that all RFC's are available in plain text, and allow postscript versions as a secondary format for them. But certainly never release an RFC in postscript-only format. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com "Live the life you love, Use a god you trust, and don't take it all too seriously." - Love & Rockets
skl@van-bc.UUCP (Samuel Lam) (09/28/89)
It would be great if those of us without easy access to PostScript
capable laser printers would not be kept out of future RFC's, as
with the recent RFC which only has a PostScript version.
Requiring that each PostScript RFC submitted be accompanied with
a plain text version should do it. (The reverse wouldn't be necessary).
There are still many people who cannot easily have a PostScript
file printed. (Or is the argument that those people should be kept
out in the cold because if one can't afford a PostScript capable
printer he/she shouldn't be reading RFC's? :-( )
...Sam
--
Samuel Lam <skl@wimsey.bc.ca> or {uunet,ubc-cs}!wimsey.bc.ca!sklCERF@A.ISI.EDU (09/28/89)
Karl, The PostScript question is well taken. We seriously need some way to capitalize on "desktop publishing" (compound documents) without being forced back to paper only. At the same time, all of us recognize and have experienced the problem you describe. The one thing which is still a major conundrum for me is the problem of illustrations. ASCII only illustrations are painful to produce and most tools produce other than ASCII (bitmap or PostScript is more typical graphic tool output). What's your general thought about finding a path towards benefitting from the tools now emerging while at the same time not losing the obvious benefits of the ASCII output form? Vint
clynn@BBN.COM (Charles Lynn) (09/28/89)
I'm not a Postscript expert, but from the earlier message it seems that things would be a lot better if the .ps document didn't try to justify the words within a line. Is it "easy" to disable text justification (leaving fill enabled)? Are font changes within a phrase, e.g., titles, a significant problem? Charlie
narten@LOVELACE.ALBANY.EDU (Thomas Narten) (09/28/89)
One problem with postscript format documents that I have run into is that not all printers are 100% postscript compatable. This is perhaps an unavoidable situation, because my impression is that 100% compatable postscript printers are somewhat (though perhaps not much) more expensive than others because of licensing fees. Persons paying for printers may not be aware that 100% compatability is an issue. I'm very much in favor of postscript documents, but worry that 100% postscript printers aren't as prevalent is they should be. Can anyone suggest a solution to this problem? Is it realistic to put together a subset of common postscript commands with an eye on avoiding less common constructs? Is there software that massages postcript input to remove uncommon constructs? Thomas Narten
jqj@RT-JQJ.STANFORD.EDU (JQ Johnson) (09/28/89)
A printer language such as Postscript isn't really ideal for the "canonical" versions of RFCs, though it does allow arbitrary graphics. It suffers from not allowing other forms of access, particularly online display on character only terminals and use with typical character-only text processing tools like grep. It doesn't generalize well to hypertext either. If standards were a bit further advanced, the ideal choice for RFCs would be a standard markup language (GML? RTF? InterScript? WordPerfect internal format? troff input?). Then we could generate whatever display format we wanted for it. They aren't to that point yet, I'm afraid. What are the NSF Expres project's solutions? If NSF is willing to accept something as a grant proposal format, then I'd be willing to accept it for an RFC. JQ Johnson voice: 415-723-3078 Manager, Special Projects Internet: jqj@jessica.stanford.edu Networking and Communications Systems Pine Hall Rm 125-A Stanford University Stanford, CA 94305-4122
mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (09/28/89)
Vint: As it would capitalize on the advantages of "desktop publishing", may I suggest that the IAB acquire for each Internet site a software and hard- ware suite so that we can have the RFCs in one standard format. While we maintain a directory of the RFCs on one of our systems, very few copies are ever printed which seems to me to be what PostScript is all about. Most people reference the documents online with whatever VT100 or compatible terminal that is sitting on their desk. I can order, almost, any software and hardware that I want for delivery to a customer; however, a "desktop publishing" system to read RFCs out of the capital budget would get me nominated for "Comic of the Year" by the bean counters. Merton
bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) (09/28/89)
Karl Auerbach has proposed that postscript RFC's be banned, presumably because trying to index keywords in a postscript file is a pain, and not because he feels that postscript printers are too obscure. (is that right?) I don't mind postscript format, but I think the question of keyword indexing should be addressed. It would be useful if authors of any document that is shipped in postscript were to add a postscript prologue to the file with the proper keyword indexes. A standard postscript prologue goes something like; %%Begin Keywords %%topic: interfaces checksum rfc1001 netbios smb %%relatedto: udp ip rfc1002 %%End Keywords By standard, I mean the double % and the begin and end blocks. I probably don't have the version 2.0 ESPF format quite right, but the idea is the same anyway. It'd be easy to strip out sets of keywords (do we need an RFC to describe the standard for key words?) and items prefaced by % won't upset the postscript printer either. comments? | Brad Clements bkc@omnigate.clarkson.edu bkc@clutx.bitnet | Network Engineer Clarkson University (315)268-2292 ------------------- Meet me at Interop '89 ---------------------------------
emv@math.lsa.umich.edu (Edward Vielmetti) (09/28/89)
It is clear from the postscript output that the source for RFC1124 was a troff document, with some simple tbl tables in it. I can understand the need to use postscript to cope with complex documents, but in this particular case it should be easy to produce an ascii RFC1124. --Ed ps. Or at least let loose the troff file.
martillo@cpoint.UUCP (Joachim Carlo Santos Martillo) (09/28/89)
In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes: >RFC1124 came out with a discussion of policy issues of interconnected >networks. Interesting and important stuff. >Now, it seems, according to RFC1111, that postscript is OK for RFC's, >(including postscript that was obviously generated by a word or text >processor.) >So: can anyone make reasonable comment on stuff that looks like what >follows? Can anyone do a reasonable machine-based content search? >Can I send it though my automated indexing tools? Can I make a >nice e-mail reply with appropriate selections for context? >No. >I thought we were working on communications, not obfuscation. >I propose that we ban postscript RFCs. > --karl-- The logic of Auerbach's proposal is compelling. As Prime Computer Corporation began self-destructing, part of this self-destructing evinced itself in the lack of communication between different groups within the company. This lack of communication was aided by the increasing non-uniform use of PC word processors on MAC's and IBM clones to produce important documents, memos and PET's instead of the uniform use of scribe+plain text on the 50 Series machines. I should also point out that not all of us have postscript printers or postscript software+supported non-postscript printers RFC's should be available at the archive machines in a plain-text format. Now I know that writing an RFC with a PC word processor is a lot nicer than using an editor on most Unix-based machines or minis. Fortunately, PC word processors like MS-Word and WordPerfect have a plain-text output mode. Utilities like The Software Bridge permit conversion of other word processor files to MS-Word or WordPerfect readable format. It should also be possible (if it has not already been done) to hack up a postscript interpreter to output plaintext to a file. Hence, even for someone using a PC word processor, there is no necessity to submit RFC's in postscript format. There might be some value to maintain a postscript format RFC archive somewhere but we should remember a great RFC will be great in plaintext while a piece of garbage will still be a piece of garbage no matter how beautifully a postscript printer can output it. Joachim Carlo Santos Martillo
fin@UF.MSC.UMN.EDU ("Craig Finseth") (09/29/89)
It is probably worth pointing out that Postscript is a representation targeted to the task of rendering a document as an image. In itself, it does not contain enough information to enable a program to mechanically produce a "reasonable ASCII" form of the document. Note that is is possible to extend Postcript so as to include this additional information using comments and/or special operators, but such a solution is not currently supported. I would also like to mention that, as the ASCII form will no doubt be wanted by more than one person, it only makes sense for the original author to perform such conversion once. (As an added plus, the author can then excercise quality control over the ASCII form.) As the Postscript advantages are more for diagrams than running text, why not offer a separate .PS file with just the diagrams? I have seen this done on several documents around the net, and it works pretty well. The following files would then be offered: RFCnnnn.TXT ASCII form as usual, with crude drawings RFCnnnnILL.PS Nice, Postscript versions of the drawings RFCnnnn.PS Postscript form of the whole thing (Yes, I realize that the ASCII form of the drawings is somewhat difficult to do and not going to work as well, but in general such drawings should be only a small fraction of the work involved with producing the RFC.) As a test case, could we ask the authors of RFCs 1119 and 1124 to come up with the ASCII versions? Craig A. Finseth fin@msc.umn.edu [CAF13] Minnesota Supercomputer Center, Inc. (612) 624-3375
karl@asylum.SF.CA.US (Karl Auerbach) (09/29/89)
There are really two distinct issues on the postscript RFC issue. One is the mere readibility of the document -- I would guess that many (but I am sure not all) have access to postscript printers of one sort or another. (Although it must be noticed that some things which fit legally into the postscript form are really bit-mapped files from tools like Tex, etc, and tend to be printable only on printers with lots of memory.) The second, and to me much more important issue, is that postscript hides the content in lots of directives. One simply can't apply any sort of text based tools to digest, correlate, index, or even grep the contents. I do believe that we need a means to have better documents, including good images. And I can see mixed documents which have text mixed with postscript pictures. I can even see postscript wrapped text, BUT it must be without the mass of directives which are injected by typical word processors. My suggestion is, hang onto your hats, to use the ASN.1 body part definition from X.400. Using that you can cleanly separate text from postscript from digitized voice from fax from ... And the ASN.1 isn't painful when used in this limited sense (and with some sensible limitations on the use of constructors, etc). [The reason I like ASN.1 is that it was designed for precisely this purpose -- mixed media representation.] --karl--
ihm@NRC.COM (Ian H. Merritt) (09/29/89)
karl@asylum.SF.CA.US (Karl Auerbach) says: >RFC1124 came out with a discussion of policy issues of interconnected >networks. Interesting and important stuff. > >Now, it seems, according to RFC1111, that postscript is OK for RFC's, >(including postscript that was obviously generated by a word or text >processor.) > >So: can anyone make reasonable comment on stuff that looks like what >follows? Can anyone do a reasonable machine-based content search? >Can I send it though my automated indexing tools? Can I make a >nice e-mail reply with appropriate selections for context? > >No. > >I thought we were working on communications, not obfuscation. > >I propose that we ban postscript RFCs. > > --karl-- > >Selection from RFC1124: > >727 789(Computer)U >1039(networking)S >1391(has)S >1511(become)S . . (Most of this is omitted here) . >2131(three)S >2299(phases.)S >2557(The)S >2693(\256rst)S >2829(phas)S I just sent a note to the NIC about that one, suggesting that at least if PostScript RFC's are to come out, that a plaintext grep'able version accompany it. Here is their response: <From NIC@NIC.DDN.MIL Mon Sep 25 12:03:02 1989 <Return-Path: <NIC@NIC.DDN.MIL> <Received: from NIC.DDN.MIL by nrc.com (4.0/NRC-DDN1.1) < id AA00386; Mon, 25 Sep 89 12:02:56 PDT <Date: Mon, 25 Sep 89 12:03:02 PDT <From: DDN Reference <NIC@NIC.DDN.MIL> <Subject: Re: rfc1119 <To: ihm@nrc.com <Cc: NIC@NIC.DDN.MIL <In-Reply-To: <8909181603.AA06258@nrc.com> <Message-Id: <12529118419.30.NIC@NIC.DDN.MIL> <Status: RO < <Ian, < <I'll let Postel answer this one. We have been working with Postel to encourage <him to provide text RFCs whenever possible. < <Regards, <Sol for the NIC <------- Jon? Care to comment on this? Until utilities exist to allow meaningful grep'ing (or equivalent) through PostScript or TeX documents; until EVERYBODY concerned has workstations with PostScript AND TeX browsers (i.e. don't need to waste paper to read or time to visually search), I believe we don't want documents in this forum, one of the best features of which was online retrieval, to come out in cryptic form without at least an accompanying plaintext version. Ok, so mathematical equations and cute little graphic figures won't be as pretty; we've done OK until now. At least we'll be able to read them without trying to dig up a PostScript printer, and we'll be able to have the COMPUTER do the searching for things in our RFC libraries, as we have always done. -i -- US Snail: 2380 Rose Avenue; Oxnard, CA 93030 U.S.A. tel. 805-485-2700 InterNet: ihm@NRC.COM
rdroms@NRI.RESTON.VA.US (09/29/89)
Comments on suggested solutions:
o Keep RFCs in a text-only format, and provide hints to a PostScriptizer
that knows what parts of the text should be filled, what parts of the
text are actually character graphics (like | and - ), and what parts
are tables.
PostScriptizing an ASCII RFC doesn't sound like much of a win - you've
already lost all the graphics info ... there's nothing to reconstruct.
o Restrict the types of PostScript that are acceptable to those that can
be textized by running them through a filter. That way, a user can
reconstruct a reasonable text version of the RFC.
Reverse engineering ASCII from PostScript sounds like an interesting,
but hard, problem. You'll need to guess what parts are straight
ASCII, and can be re-paragraphed, what parts are tables and must be
left verbatim, and what parts are graphics and must be approximated
with ASCII text.
It is clearly advantageous to have the ability to view and search
through RFCs on-line. For the time being, we might want to try a
fourth solution:
o Require the author to submit an ASCII version of the RFC - and
allow an optional PostScript version.
nroff/troff solves the problem by using two translators - nroff
generates ASCII and troff generates PostScript from the same course.
Is there a version of nroff that behave rationally when confronted by
grpahics (e.g., pic output) input? Is there an equivalent to nroff
for TeX?
- Ralph Droms (On leave from Bucknell University)
NRI rdroms@nri.reston.va.us
1895 Preston White Drive, Suite 100 (703) 620-8990
Reston, VA 22091 (703) 620-0913 (fax)lehners@uniol.UUCP (Joerg Lehners) (09/29/89)
zweig@brutus.cs.uiuc.edu (Johnny Zweig) writes: >It seems the best thing to do is to put PostScript stuff _somewhere else_. I >like being able to do "lpr RFCxxx" and have the right thing happen -- and I >imagine people who don't have PostScript printers around would be even more >adamant on the point. Same with me, except I don't print the RFC often. I almost all time just do an 'more Rfc/Rfc<some-number>' to look up some details. Printouts get lost too often. And what about looking up words. I would like to be able to do for example: 'grep TTL Rfc/rfc*'. >It seems that complicated drawings ought to go into some kind of companion >document that would be referenced (with good old [1]...[n] in plain ASCII) >in the RFC-proper. >I think that one can go a long way with - + | _ / \ < and >. Certainly >anything that can't be described without a comlicated drawing ought to be >rephrased. A picture may be worth a thousand words, but a standard should be >clear enough not to need thousands of words. Yes. I really like the drawings in rfc793. It's good enough and visisble on every character only terminal. For details see the Text ! What about that: Let all RFCxxxx and the new in the old style, build some RFCxxxx.ps files for the Postscript-Version. But they should NOT differ in contents ! Joerg -- / Joerg Lehners | Fachbereich 10 Informatik ARBI \ | | Universitaet Oldenburg | | BITNET/EARN: 066065@DOLUNI1.BITNET | Ammerlaender Heerstrasse 114-118 | \ UUCP/Eunet: lehners@uniol.uucp | D-2900 Oldenburg /
hedrick@geneva.rutgers.edu (Charles Hedrick) (09/29/89)
I agree too. We have plenty of Postscript printers, but I often want to look at RFC's from inside Emacs, like when I'm working on software, or answering a question that requires me to refer to an RFC. If we get to the point where we can assume that everybody is using a workstation or X terminal, I'd be willing to consider a document format that could only be displayed on such a beast. I'm afraid that's a few years in the future. I do not want to be told that I have to read these documents in hardcopy.
sra@lcs.mit.edu (Rob Austein) (09/29/89)
Vint, GNU Emacs, at least, has a major mode called "picture" which somewhat eases the task of drawing pictures in ASCII. It's not perfect, and could use some further development, in particular to do useful things with mice, but it's a start. I agree with Karl completely. I haven't got the room to keep an entire hardcopy RFC manual set in my office, let alone at home, let alone take it with me when I travel. Pictures are nice and there are some things that can be said much more easily with pictures, but I can't quote chapter and verse of a picture in a mail message (unless it's in ASCII) and I can't read it to somebody over the phone. I think that until the available tools for transmitting arbitrary pictures become as cheap and available as home terminals are now, the core of any RFC really ought to remain remain English text. I would be content with ASCII versions of RFCs which replaced all the pretty pictures with little boxes that read: +-------------------------------------------------+ | | | If you had a PostScript (TM) printer, you'd | | see a pretty picture here. You lose. | | | +-------------------------------------------------+ One other thing. According to RFC-1111, page 3: "Since PostScript is not editable, an editable source version of the document must also be submitted." This is entirely reasonable. Perhaps this same editable source version be made available to the rest of us after the RFC Editor has performed his office? This would help somewhat even if the rest of the question degenerates to an insoluable religious debate. --Rob Austein, MIT
epsilon@wet.UUCP (Eric P. Scott) (09/29/89)
In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes: >I propose that we ban postscript RFCs. Where have you been? PostScript has been the de facto standard for FTPable documents for quite some time. IMHO, PostScript RFCs are long overdue. More please! I still have hardcopy RFCs from the days when the NIC mailed them out. The text versions pale by comparison. Now if I can find textured manilla covers... -=EPS=-
davecb@yunexus.UUCP (David Collier-Brown) (09/29/89)
karl@asylum.SF.CA.US (Karl Auerbach) writes: | There are really two distinct issues on the postscript RFC issue. | One is the mere readibility of the document [...] | The second, and to me much more important issue, is that postscript | hides the content in lots of directives. [...] Given these two requirements, the implication is that one employ a notation that expresses the "directives" in as succinct and identifiable a way as possible. One can then: 1) read the document in editable form, ignoring the occasional directive, 2) process the document into final form, evaluating the directives, or 3) process the document into an approximation of the final form, with placeholders used for things which cannto be represented (eg, empty boxes for diagrams) | My suggestion is, hang onto your hats, to use the ASN.1 body part | definition from X.400. Using that you can cleanly separate text from | postscript from digitized voice from fax from ... And the ASN.1 isn't | painful when used in this limited sense (and with some sensible | limitations on the use of constructors, etc). [The reason I like | ASN.1 is that it was designed for precisely this purpose -- mixed | media representation.] I'm not religious about which multi-media standard you wish to use, subject to the requirements above. SGML subsets, ASN.1 subsets or just postscript run through a postprocessor to make it readable in its editable form all meet the requirements. Which to use is a managment decision, based on which standards body we respect (:-)). --dave ps: For mere ease of implementation, a requirement that fill-but-no-justify be used when creating postscript plus a few sed scripts would probably render an editable form that we could live with... -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
roy@phri.UUCP (Roy Smith) (09/29/89)
One of the recent PS RFCs that came out (NTP) recently was of
interest to me. Unfortunately, it took me about3 days to get a printed
copy of it. I tried to display it with NeWS, but my NeWS server just died.
I tried to send it to my Apple LaserWriter, but what I got was several
copies of the front material and none of the rest. It turned out that it
was actually two PS documents in one file, with some strangeness (I don't
remember the details) with the headers, and I had to manually split the
file into two pieces and make some minor changes to each part, and I
*still* ended up getting multiple copies on my LW, but at least I got it
printed and could hand-assemble the pages so I could read it.
I got into a bit of a discussion with the author about whether the
fault was in my line printer spooling software or the PS document producing
software he used. I was left with a bad feeling about the whole thing. I
agree; PS-only RFCs are not a good idea just yet. Take an example from
NYSERNet; they distribute PS maps of the network, but they always also have
ascii versions for people who can't deal with PS.
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
{att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu
"The connector is the network"jtw@lcs.mit.edu (John Wroclawski) (09/29/89)
In article <Sep.28.18.25.03.1989.1289@geneva.rutgers.edu> hedrick@geneva.rutgers.edu (Charles Hedrick) writes: (About RFC's in PostScript) If we get to the point where we can assume that everybody is using a workstation or X terminal, I'd be willing to consider a document format that could only be displayed on such a beast. This and the next several messages in this thread suggest that people might be happy if they could display PostScript RFC's online. That doesn't seem like enough to me -- I haven't seen a PostScript (dvi, whathaveyou) previewer yet that had search or cut-and-paste capability. I think ASCII will be the best choice unless/until there is some sort of universal WYSIWIG editor description format and a -whole bunch- of programs that use it. John Wroclawski - MIT Lab for Computer Science - jtw@lcs.mit.edu
peter@ficc.uu.net (Peter da Silva) (09/29/89)
The postscript guys want to use postscript so they can include figures
and other graphical information. How about doing it this way:
Start with some text text text text text text text text text
more text text text text text text text text text text text text
and more text text text text text text text text text text
text text text text text text text text text text text text
#!some magic line.
P(OSTSCRIPT) TYPE {stuff}
#!some other magic line.
Converting this to something either postscript or text folks can deal
with would be a SMOP.
--
Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation.
Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-'
"That is not the Usenet tradition, but it's a solidly-entrenched U
delusion now." -- brian@ucsd.Edu (Brian Kantor)henry@utzoo.uucp (Henry Spencer) (09/30/89)
In article <932@manta.NOSC.MIL> budden@manta.nosc.mil.UUCP (Rex A. Buddenberg) writes: >At the risk of sounding too rational, why don't you employ >the CALS standards for what they were settled on for? >(SGML for text, IGES for CAD, CCITT Group 4 for images). Because only a very small percentage of the intended audience has software that can understand them, and the purpose of the exercise is supposed to be communication, not standards conformance for its own sake. -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
rwa@cs.AthabascaU.CA (Ross Alexander) (09/30/89)
I agree, let's ban (severely deprecate, anyway) postscript RFC's. I don't have a postscript printer handy - if I want I can print them, but they're a royal pain on-line. And they're so **big**! Ross
CERF@A.ISI.EDU (10/01/89)
Merton, I assume that your tongue was firmly in cheek in proposing to have the IAB acquire a PostScript printing/display capability for every Internet site. The last host count was 118,000+ and growing. The principal reason for considering PostScript as an allowable publishing medium was the belief that it is widely available already. Is it the case that your site has no PostScript capability at all? Vint
Mills@UDEL.EDU (10/01/89)
Roy, The problem you had was apparently spooler-specific, since the file printed without mishap on both our lasers and spoolers and the RFC editor's lasers and spoolers. However, the DP software did make rather rash assumptions and took naughty liberties in the file format. With help from my friends, including you, I found the problem and manually massaged the file, which is now in the archives. I apologize for your inconvenience and any others who snarfed the file during the first couple of days after its appearance and promise to be ever vigilant in future submissions. Dave
Mills@UDEL.EDU (10/01/89)
John (and others), I have a serious dillema. My students and I work with several text, image and statistics systems, all of which produce PostScript. My advice has been to use the best technology currently available to maximize research productivity and exposure in the many scientific and engineering archives available to us, including RFCs. Unless a document is in fact pure text, this usually means PostScript. This is how we submit articles for publication in conference proceedings, archive journals and even our dear own Computer Communication Review. For the reasons mentioned in my recent message, we are not prepared to render every document in ASCII, regardless of content, and are not prepared to maintain documents in more than one form. Thus, the real question is whether PostScript submissions will be allowed in the RFC archives or whether they will be published elsewhere and not appear in the RFC archives at all. I am a stout supporter of the RFC process and would hope that our community can be viewed as a leader in technology of electric publishing, archiving and distribution. Just as CCR is viewed as a pioneer in print publishing by encouraging article submission in electric form (currently PostScript), I would hope our community can show that it is possible to save the production cost and even a few trees by remote access of the archives, while preserving the full capabilities of print media. There are lots of things that PostScript does not provide and that may become available in future, including ODA. When the standards have stabilized, when software is available and when such capability has spread even to the sites that have no PostScript printers now, I promise to become a zealot. Dave
LARSON@CRVAX.SRI.COM (Alan Larson) (10/01/89)
I think the writer who proposed that IAB buy us all PostScript
equipment had a good point. As Vint Cerf pointed out, the last host
count was over 100,000 hosts - and a large number of us do not have
Postscript displays that let us search, cut, paste, as well as display.
With real ascii, we can include excerpts cut from the RFCs in
messages (like this one) that we send to vendors who are delivering
non-conforming software.
With real ascii, I can search through the directory of RFCs for
the text string I remember, find it, and paste it (with good old-
fashioned tools like emacs) into a message. Just imagine what this
message would have looked like with a paragraph or two of postscript
included.
Alan
-------mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett) (10/01/89)
Vint: > I assume that your tongue was firmly in cheek in proposing > to have the IAB acquire a PostScript printing/display > capability for every Internet site. The last host count > was 118,000+ and growing. Yes. I did, however, require a surgical procedure to have it removed. > The principal reason for considering PostScript as an > allowable publishing medium was the belief that it is > widely available already. Is it the case that your site > has no PostScript capability at all? The technically accurate response is that we do have a PostScript capability; however, the problem is accessability. The PostScript capable printers are on classified systems which cannot be connected to the Internet. In order to print an RFC on those systems, I would have to modify the document to include the required "U N C L A S S I F I E D" banner at the top and bottom of each page and may have to include the "(U)" at the beginning of each para- graph unless, of course, the author has already done that for me. Should I fail to do that, I will get the system's default banner and be required to secure the document in a vault when not in use. The basic problem is that we have two different views of the "Information Age". There are those, like myself, who envision a world where paper is the exception rather than the rule. We want to be able to display the in- formation at a terminal, obtain the information that we require, and get on with business. Desktop publishing is an anachronism. Or is it the future for those whose performance is measured by the printed word? For this group desktop publishing is the future. Their ideas and observations can be rapidly distributed over the electronic medium with the publishing costs being absorbed by the target audience. The basic problem is that the first group wants the information but does not want the description of how the information is displayed on the printed page. How do we resolve this problem? From my perspective, the information is not in a usable form. Merton
WANCHO@WSMR-SIMTEL20.ARMY.MIL ("Frank J. Wancho") (10/02/89)
Dave, I think you answered your own dilemma: all instances you cited, except for RFCs, are in the print (paper) domain. Publishing in the paper domain is not what RFCs are all about - just expand the name. Note that this discussion is not about electronic publishing; it is about RFCs - to be able to cite and debate them in an electronic media - not about printing them. The RFCs should never have been made available in printed form - they should have been put on disk, tape, or even CD-ROM, not on paper for distribution outside the Internet access world. We have enough trouble with vendor implementations of network software without giving them yet another excuse - not being able to read them because they can't print them. --Frank
henry@utzoo.uucp (Henry Spencer) (10/02/89)
In article <8909302326.aa13204@huey.udel.edu> Mills@UDEL.EDU writes: >I would hope our community can show that it is possible to save the production >cost and even a few trees by remote access of the archives, while preserving >the full capabilities of print media. Remote access to the archives does not save trees -- indeed, it worsens tree mortality -- if the archives are in a form which is print-only (not readable on-line) for a good many sites. Never mind the issue of software that understands PostScript; a good many of us don't have the bitmapped displays to show it on even if we had the software. Agreed that this puts us somewhat behind the times, but saying that will not buy us new hardware. -- "Where is D.D. Harriman now, | Henry Spencer at U of Toronto Zoology when we really *need* him?" | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
frg@jfcl.dec.com (Fred R. Goldstein) (10/03/89)
As long as we're all dumping on PostScript -- and I'll not contradict
the will of the masses and approve of posting only PostScript -- I'll
throw in another complaint.
Some PostScript documents are prepared "last page first", which works
on Apple LaserWriters and other printers that don't put the pages facing
the right way up. The first time I printed the OSPF IGP spec, I got
a heap of pages in the wrong order. I just got a new .PS RFC-draft, and
at least this time I knew to tell the LPS40
/param=(data=post,output_tray=face_up).
So much for a de facto "standard"! While I don't dislike .PS files
so long as there's a .txt to play with too, they should indicate, in the
very beginning or somewhere like that, that they're backwards.
fredgwh@volcano.Berkeley.EDU (George William Herbert) (10/03/89)
Quick question: what are the locations that the RFC's are available from anon ftp wise? Thanks, george william herbert
pvm@VENERA.ISI.EDU (Paul Mockapetris) (10/03/89)
Most of the arguments to date have focused on two issues: Freedom to print RFCs and Freedom to GREP RFCs I personally think that the first should be guaranteed by the IAB or whoever calls the shots, and that vanilla Postscript plus FAX, or some other compromise should be made. I think that the second freedom is desirable but has to strike a balance against progress. I can't imagine RFCS about X, multimedia, or several other topics without graphics. I also wanted to add that we could view the passing of the second freedom as a step in the transition to OSI. I suggest the following sequence: 1 Text RFCs. 2 Text and PS RFCs which are less accessible. ... 7 Copyrighted RFCs with ISO/CCITT numbers which must be purchased. paul
roy@phri.UUCP (Roy Smith) (10/03/89)
In <506@jfcl.dec.com> frg@jfcl.nac.dec.com.UUCP (Fred R. Goldstein) writes: > Some PostScript documents are prepared "last page first", which works on > Apple LaserWriters and other printers that don't put the pages facing the > right way up. My feeling on this one is that *all* PS documents should be "first page first". It's the job of the spooler software to determine if page reversal is appropriate for a particular printer, and if so, do it during the spooling/printing process. We've got both face-up and face-down printers here; whichever order you put the pages in, the document is going to be wrong for at least some printers, so you might as well use the canonical ordering. And yes, I agree with Fred, if you absolutely, positively, must produce pre-page-reversed documents for distribution, at least there should be some easy way to tell what order the pages are in. Do the normal PS document formatting conventions provide some standardized %%line for this? -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
gww@EBAY.SUN.COM (Gary Winiger) (10/03/89)
In article <5446@asylum.SF.CA.US> karl@asylum.SF.CA.US (Karl Auerbach) writes: > >I propose that we ban postscript RFCs. > Here! Here! PostScript is wonderful for making good looking paper output, but useless for reading online or searching. If an RFC is to be offered in PostScript, let's also have the text version available. Gary..
ihm@NRC.COM (Ian H. Merritt) (10/04/89)
bkc@OMNIGATE.CLARKSON.EDU (Brad Clements) says: >Karl Auerbach has proposed that postscript RFC's be banned, presumably because >trying to index keywords in a postscript file is a pain, and not because >he feels that postscript printers are too obscure. (is that right?) > >I don't mind postscript format, but I think the question of keyword indexing >should be addressed. > >It would be useful if authors of any document that is shipped in postscript >were to add a postscript prologue to the file with the proper keyword indexes. > . . . I agree that a keywords section might be useful, but this would not address the main issue. When searching an RFC, you may not be looking for a keyword that is likely to appear in such a list. For example, probably the most common grep searches I make of the RFC directory look for some phrase or tag that I remember reading in the past, but can't quite recall the document from which it came. In this case, the context of the line around the hit is also useful to help separate likely matches vs. coincidences. Like one of the earlier postings said, I too bring up RFC's in EMACS more often than any other method of viewing. The ASCII-text pictures, while maybe a bit difficult to create, have the advantage that they can be viewed in this context. This is very handy. One other, perhaps less significant point is that many sites archive these online locally to avoid the necessity to continually transfer them over the net. PostScript images are BIG! Since grep isn't particularly useful on them anyway, I keep the PostScript ones compressed. Even so, they are still larger than most RFC's uncompressed. 184 -rw-r--r-- 1 172667 Sep 15 09:27 rfc1119.ps.Z 120 -rw-r--r-- 1 109731 Sep 20 14:06 rfc1124.ps.Z If RFC's were available in dual formats (i.e. a .ps file and a .txt file), I would definitely keep the .txt file online. The .ps file, however, I might be inclined to leave behind. -i -- US Snail: 2380 Rose Avenue; Oxnard, CA 93030 U.S.A. tel. 805-485-2700 InterNet: ihm@NRC.COM
gamiddleton@WATMATH.WATERLOO.EDU (Guy Middleton) (10/04/89)
In article <[A.ISI.EDU]30-Sep-89.19:47:54.CERF> you write: > I assume that your tongue was firmly in cheek in proposing > to have the IAB acquire a PostScript printing/display > capability for every Internet site. The last host count > was 118,000+ and growing. I think it fascinating that anybody can actually come up with a count of sites on the Internet. Can you tell me how the number was arrived at? -Guy Middleton, University of Waterloo
kjm@ut-emx.UUCP (10/05/89)
In article <8910022323.AA11747@venera.isi.edu>, pvm@VENERA.ISI.EDU (Paul Mockapetris) writes: > Most of the arguments to date have focused on two issues: > > Freedom to print RFCs > and > Freedom to GREP RFCs > > [...] > I think that the second freedom > is desirable but has to strike a balance against progress. Losing a powerful capability is progress? Right... > I can't > imagine RFCS about X, multimedia, or several other topics without > graphics. Which could perfectly well be done as separate plates, as previously mentioned. > I also wanted to add that we could view the passing of the second > freedom as a step in the transition to OSI. I suggest the following > sequence: > > 1 Text RFCs. > 2 Text and PS RFCs which are less accessible. > ... > 7 Copyrighted RFCs with ISO/CCITT numbers which must be purchased. You want to make it as hard as you think you can get away with for people to implement new Internet software, do you? -- The above viewpoints are mine. They are unrelated to those of anyone else, including my wife, our cats, and my employer. Kenneth J. Montgomery Senior Operating System Specialist kjm@hermes.chpc.utexas.edu University of Texas System Center for High Performance Computing
sgrimm@sun.com (Steven Grimm) (10/05/89)
Seems to me that posting an entire RFC in PostScript is like posting a Sun-3
binary to comp.sources.unix.
---
" !" - Marcel Marceau
Steven Grimm Moderator, comp.{sources,binaries}.atari.st
sgrimm@sun.com ...!sun!sgrimmpeter@ficc.uu.net (Peter da Silva) (10/06/89)
In article <8910022323.AA11747@venera.isi.edu>, pvm@VENERA.ISI.EDU (Paul Mockapetris) writes: > I think that the second freedom [to have RFCs online for processing] > is desirable but has to strike a balance against progress. > I suggest the following sequence: > 1 Text RFCs. > 2 Text and PS RFCs which are less accessible. > n Copyrighted RFCs with ISO/CCITT numbers which must be purchased. This is "progress", Mr. Mockapetris? Looks like a giant step backwards to me. Why on earth is this in any way a desirable step? -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' ``I feel that any [environment] with users in it is "adverse".'' 'U` -- Eric Peterson <lcc.eric@seas.ucla.edu>
CERF@A.ISI.EDU (10/10/89)
Guy, check with Craig Partridge at BBN (Craig@nnsc.nsf.net) concerning host count. I think I got this data from Tracey LaQuey at University of Texas. Vint
louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") (10/10/89)
Geez. What a fuss. Do you all have a serious interest in the particular RFC's that were published in PostScript, or is this just another opportunity to flame? Have you tried to USE these RFCs and found them deficient? A measure of success for an RFC is if it meets the needs of the audience it was written for. I can't speak to RFC 1124, but have quite intimate experince with the NTP spec; or rather with its many, many draft versions. I'd like to speak to the utility of RFC1119, on the Network Time Protocol. The development of the NTP RFC took quite a long time. I wrote an implementation of NTP based on many of the draft NTP protocol specificiations. The idea was to find out if the protocol described by the document actually matched and could interoperate with the version that Mills, the author, developed. Also during this process the protocol was changed and improved due to the testing that was performed. During this entire process I read literally 20 different versions of this specification. They were all in the form of a PostScript document. A number of other folks on the NTP mailing list also read this document and submitted suggestions to Mills relating to the content and typographical appearence of the document. I can't recall a single occasion when someone complained that the document was only available in PostScript form. My point is that the *content* of the RFC was what this group of folks were interested in, and not the form. It really didn't impact *my* use of the spec. Yes, it's a little more difficult to print the thing, but having the spec published in PostScript enhances the understanding of the material. The result of this experience is that, yes, the spec does describe the protocol in sufficient detail that at least two different implementations of NTP were built from the document. The talk to each other as well as the implemention built by the author of the protocol. I think that's a wonderful thing from the point of view of a protocol implementor. I suppose that some folks don't have a PostScript printer available to print these documents; the quick answer is that paper versions are available from the NIC. I think PostScript capable printers are becoming very popular and affordable these days. It is true that you can't grep the text of the document. But, IMO the added readability of the PostScript form outweighs the utility to grep it. This is my perspective as a serious user of RFC 1119. Before you condemn the form, print the document and ask yourself if it would be as easy to understand if it was a "dumb" ASCII text document? louie
karl@asylum.SF.CA.US (Karl Auerbach) (10/11/89)
In article <8910100305.AA19076@sayshell.umd.edu> louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes: >Do you all have a serious interest in the particular RFC's that were >published in PostScript, or is this just another opportunity to flame? >Have you tried to USE these RFCs and found them deficient? As the author of the original message in this discussion, I find your comment personally offensive. Are you really asserting that I took the trouble to obtain RFC1124 just because I wanted to flame on its form, not its content? If so, you are badly mistaken. In any event, this discussion has gone on long enough and I believe the concensus is that postscript as the sole representation is not a good idea. --karl--
gja@mullian.ee.mu.oz.au (Inspector Gadget) (10/11/89)
In article <8910100305.AA19076@sayshell.umd.edu> louie@SAYSHELL.UMD.EDU ("Louis A. Mamakos") writes: >Geez. What a fuss. > [.......] >This is my perspective as a serious user of RFC 1119. Before you >condemn the form, print the document and ask yourself if it would be >as easy to understand if it was a "dumb" ASCII text document? > >louie IMO you've missed the point entirely. If _all_ that was ever available was paper versions from NIC (or where-ever) and people were asked "Pretty Laser-printed or Plain 'ASCII' version?" I'm sure everyone would take the pretty laser-printed ones for their bookshelves. The problem is that the _form_ of the document is (for most people) on electronic storage/retrieval systems. Postscript forms are of no use at all until they're _printed_, yet not everyone wants to use paper versions of the documents (as has been re-iterated over and over). [ 'what ever happened to the paper-less office?', I thinks to meself] In case you think I don't understand how nice PS versions would be I should mention that I've just "wasted" a week or so transferring a collection of RFCS to a MAC and prettying them up for laser-printing. What I would have given for PS versions if they'd been archived somewhere. (no flames about me stupidly ignoring "archive something-or-other" please. what's done is done). However regardless of the inconvenience to me when producing paper versions I'd still see it as important that ASCII versions as stored for online reference (until everyone has graphics screens and a collection of programs to search PS documents just like we can now search plain text documents. 'PSgrep' and 'PSmore' spring to mind.....). The issue is not simply ease of understanding, it's ease of information retrieval. Grenville Armitage
dan@ccnysci.UUCP (Dan Schlitt) (10/12/89)
Well, now that you mention it, the NTP documentation was the exact place where I encountered this postscript mania. I tried to read it on-line and found it to be unreadable. Yes, I can get it to a postscript printer. But that is a pain in our case and I don't really want a paper copy. So I postponed looking at NTP and went on to something else. Please, please give us something we can use unix tools like grep on and can read on our terminals without having to have a display postscript based terminal. Thanks. -- Dan Schlitt Manager, Science Division Computer Facility dan@sci.ccny.cuny.edu City College of New York dan@ccnysci.uucp New York, NY 10031 dan@ccnysci.bitnet (212)690-6868