Comment on RFC1124 (?)
Karl Auerbach
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
Steven Grimm
>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.)
>
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
sgr...@sun.com ...!sun!sgrimm
Russ Nelson
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.
Rex A. Buddenberg
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
Johnny Zweig
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
John Romkey
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: rom...@asylum.sf.ca.us Internet: rom...@ftp.com
"Live the life you love, Use a god you trust,
and don't take it all too seriously." - Love & Rockets
Bart Massey
Seconded. It's not like we don't have postscript printers and previewers
everyplace -- as Karl said, it's just really nice to be able to read/search
for/index/etc an RFC without having to invoke all of that machinery. And
it's not at all clear to me why PostScript is necessary. I have never been
confused by the lack of font support or the ASCII graphics in the older
RFCs. Seems like a solution to a non-problem, IMHO!
Bart Massey
Tektronix, Inc.
TV Systems Engineering
M.S. 58-639
P.O. Box 500
Beaverton, OR 97077
(503) 627-5320
..tektronix!videovax.tv.tek.com!bart
Samuel Lam
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 <s...@wimsey.bc.ca> or {uunet,ubc-cs}!wimsey.bc.ca!skl
Bart Massey
Seconded. It's not like we don't have postscript printers and previewers
CE...@a.isi.edu
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
Charles Lynn
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
Thomas Narten
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
JQ Johnson
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: j...@jessica.stanford.edu
Networking and Communications Systems
Pine Hall Rm 125-A
Stanford University
Stanford, CA 94305-4122
Merton Campbell Crockett
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
Brad Clements
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 b...@omnigate.clarkson.edu b...@clutx.bitnet
| Network Engineer Clarkson University (315)268-2292
------------------- Meet me at Interop '89 ---------------------------------
Edward Vielmetti
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.
Joachim Carlo Santos Martillo
>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
Craig Finseth
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 f...@msc.umn.edu [CAF13]
Minnesota Supercomputer Center, Inc. (612) 624-3375
Karl Auerbach
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--
Ian H. Merritt
>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 N...@NIC.DDN.MIL Mon Sep 25 12:03:02 1989
<Return-Path: <N...@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 <N...@NIC.DDN.MIL>
<Subject: Re: rfc1119
<To: i...@nrc.com
<Cc: N...@NIC.DDN.MIL
<In-Reply-To: <890918160...@nrc.com>
<Message-Id: <125291184...@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: i...@NRC.COM
rdr...@nri.reston.va.us
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 rdr...@nri.reston.va.us
1895 Preston White Drive, Suite 100 (703) 620-8990
Reston, VA 22091 (703) 620-0913 (fax)
Joerg Lehners
>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.
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: 066...@DOLUNI1.BITNET | Ammerlaender Heerstrasse 114-118 |
\ UUCP/Eunet: leh...@uniol.uucp | D-2900 Oldenburg /
Charles Hedrick
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.
Rob Austein
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
Eric P. Scott
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=-
David Collier-Brown
| There are really two distinct issues on the postscript RFC issue.
| The second, and to me much more important issue, is that postscript
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 Smith
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- r...@alanine.phri.nyu.edu
"The connector is the network"
John Wroclawski
In article <Sep.28.18.25...@geneva.rutgers.edu>
hed...@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 - j...@lcs.mit.edu
Peter da Silva
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: pe...@ficc.uu.net, +1 713 274 5180. Fun: pe...@sugar.hackercorp.com. `-_-'
"That is not the Usenet tradition, but it's a solidly-entrenched U
delusion now." -- br...@ucsd.Edu (Brian Kantor)
Henry Spencer
>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 he...@zoo.toronto.edu
Ross Alexander
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
CE...@a.isi.edu
I was among the several who pushed rather hard on this point,
largely out of a concern that we were losing opportunities to
improve our ability to express ourselves by continued lack of
quality figure/graphics which desktop publishing software has
placed in our hands. I'm less infatuated with multifont
capability. Creating figures with tools available almost never
results in an ASCII rendition. Rather, one gets bit maps or
PostScript or other encoding as output. Of course, one also
gets paper.
It's clear that PostScript is less widely available than I
had thought; more interestingly, and I think properly, Karl
and others have pointed out the difficulty of doing meaningful
searches through the PostScript forests. This I must agree with -
it is impossible to even imagine what the content means when
confronted with the PostScript (ASCII) rendition.
Here is the conundrum. Many of us are regular users of editing
tools which allow combined text and graphics. Since print medium
publishing still dominates (let's face it, it's cheap and
convenient), these tools are often the source of the documents
we'd also like to submit as RFCs. Some of these tools do permit
the preparation of simple, ASCII unformatted (or, sometimes,
formatted) presentations in addition to PostScript. Its a separate
production, though, because pagination changes with font, for
instance. So one would do one layout for multifont printing
and another one for plain ASCII on-line presentation.
It gets worse when you have to maintain two separate texts
for this purpose (e.g. a LATEX version and a plain ASCII version).
Keeping the texts in sync as changes are made is a pain - maybe
I just don't know about the right editing tools?.
Finally, if you do produce any graphics and they are only
printable by means of, say PostScript, then one would have to
do a separate set of ASCII graphics for the on-line version, or
forego the graphics altogether. We've been largely forced to do
the latter for a long time, in my opinion.
So, it comes down to wondering how we can ever introduce
an agreed and widely-shared on-line publishing infrastructure
which will give us support for non-textual content. It seems
apparent that, in the short term, we will have to produce
plain ASCII, non-graphic versions to satisfy search and
on-line display (not counting display-PostScript) and
allow PostScript files as alternatives. Is that the best we can
do? Are we on no noticeable vector which will allow us to
standardize on a common way of displaying non-text material?
Can we define such a vector and work towards it?
Vint
Mi...@udel.edu
I've been waiting for this discussion to ripen before commenting, but you
have nicely captured my own thoughts and said it better than I could. I
too argued the issue in favor of PostScript, not so much because of infatuation
with the language, but because I perceived it to be the most widely
supported in the various WP and DP packages and compatible printers most
widely distributed. While there have been squawks about compatibility on
my own submission (RFC-1119), which (hopefully) have been fixed, I still
cling to that view. In a world that must in my view encompass commercial
software and non-Unix systems, and if a non-ASCII-compatible presentation
capability is required, then PostScript is a logical choice.
On judgement calls, such as when is PostScript "justified" for figures,
tables and formulae, not to mention fonts, I stand mute. I don't think it
is productive to argue the conditions under which an author is "allowed"
to choose PostScript or be "required" to choose ASCII. Having submitted
bunches of RFCs of both kinds now, I probably would make different choices
a year back or a year hence. It does seem reasonable (as my friends tartly
reminded me) to avoid use of any but the basic PostScript features, for instance
found in the relatively ubiquitous Apple LaserWriter (standard model). It
may in any case be useful to scout the features (or lack thereof) with printers
of various manufacture and develop a hints-and-kinks guide for prospective
authors.
On the matter of duplicate submissions in PostScript and ASCII. I have to
resist this for the same reasons as Vint points out. The tools I use every
day include mathematics manipulation and presentation packages, image
scanners and other computer-aided publishing (CAP - you heard it here)
software which produce PostScript as output. My WP and DP software is
capable and even convenient for the process of combining and formatting
reports and papers containing that data. In fact, in my PostScript submissions
you may notice the images and graphs are in Encapsulated PostScript (EPSF)
format and can be snipped from the document. The point is that the job of
rendering that, not to mention formulae, stylish fonts and visually exciting
tables is simply beyond the resources of my time and the time of my supporting
staff.
Finally, there is the issue of production efficiency and staff training. In
the past most of us who wrote RFCs were intimately involved in the work
reported and edited, formatted and published the RFCs ourselves. I still do
this myself. However, I have a lot of friends in the university and industry
research community who depend on secretarial staff to do the legwork. Most
of the publishing done is in research reports, conference submissions and
journal submissions, which clearly call for something prettier than ASCII.
Therefore, staff are usually trained to produce good-looking documents
consistent with the quality expected in these publications. Asking them to
maintain dual-track editing, formatting and archiving with available software
systems (and that includes 'roff, 'Tek, Scribe, MS-Word, Ventura and the rest)
is simply not practical.
Now, it might even be possible to entertain an ad-hoc "standard" WP/DP
software suite, such as 4.3bsd Unix tools or Ventura/MS-Word or Slate or
something, but I don't think so. The WP/DP community is evolving like
fruitflies - I have gone through two versions each of WordPerfect, MS-Word,
Ventura and even several versions of hardware and operating systems in the
last couple of years. I conclude that such a standard is elusive, even if
ODA is said to be immensely imminent. When ODA and/or the other sprouting
standards mentioned recently become available more-or-less ubiquitously
to our community, I will be among the first to subscribe to them.
Meanwhile, note that PostScript contributors are asked to submit the source
files used in the preparation of the document, as I did. There is no
guarantee that these files would be compatible with every WP package; however,
it is true that the bulk of the text is available in a form that would
not violate the Principle of Least Astonishment assumed in many ASCII
editors. While I am not sure the RFC archive keepers would wish to make
these files part of the archive itself, I would assume the author could
make them available upon request.
Finally, I propose a cardinal rule that might satisfy the widest community
that have no access to PostScript printers. If an author chooses to publish
in PostScript, that author should be prepared to mail paper copies upon
request. I am happy to comply with that rule. Meanwhile, we have urgent need
for a browser program that can munch through PostScript output looking to
collect just the text and do something reasonable to produce an ASCII document
that can be gripped, grepped and grokked by the masses.
Dave
Marc Gibian
have missed what seems to me to be the real problem. Let me give
it a try ...
The issue here is that many of us have long ago stopped generating
simple ASCII documents. But, we need some way to interchange these
more complex, multimedia, documents. The use of Postscript seems
to me to miss the point because it is not a representation of the
document, rather it is a representation of its printed image.
Believe it or not there is actually a standard that addresses
the interchange of these sophisticated documents.. I believe
it is titled ODIF (Office Document Interchange Format), and
is part of ODA (Office Document Architecture). Rumor has it
that some of the majors in the desktop publishing business
have announced products capable of reading and writing ODIF,
therefore supporting the interchange of documents with ODIF.
Finally, x.400 includes ODIF as one of its defined body part
types, so when we start emailing RFCs over x.400 services,
it is a natural function to send them out in ODIF format.
SO, my conclusion is that a reasonable approach to solving this
problem is to do two things:
1. always, always provide an ASCII version of all RFCs, since
as much as we wish it were different, not everyone has a
workstation, or even a PC, on their desktop.
2. provide an ODIF version of all RFCs to support interchange
of the complex, multimedia, form of the documents.
It will be interesting to see what really happens...
Marc
--
Project Engineer, email project: Apollo Systems Division of HP
Internet: ma...@apollo.hp.COM
NETel: Apollo: 508-256-6600 x2077
(Copyright 1989 by author. All rights reserved. Free redistribution allowed.)
Peter da Silva
raster-output-only CAP systems.
If an RFC is in PostScript, then include the source in whatever markup
language (*roff, TeX, or Wysiwyg) you use, without any of the graphics.
CE...@a.isi.edu
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
Mi...@udel.edu
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
Mi...@udel.edu
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
Alan Larson
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
-------
Rick Adams
unix and ms-word on the Macintosh) have the capability to produce a
pretty reasonable looking text only version from the original input
IN ADDITION to the intended fancy postscript output. I believe a filter
is also available for TeX to produce reasonable ASCII.
What systmes are you using that cant produce ASCII output? Granted
it won't be of the same quality as the postscript, but it certainly
will have the content necessary for the text only people.
Producing both text and postscript would be absolutely no problem for me.
I would not have to maintain a second source file. Perhaps these
"powerful" CAP systems you are using aren't as powerful as you were
lead to believe.
How about examples of the inadequate systems you are complaining about.
--rick
Merton Campbell Crockett
> 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
Mi...@udel.edu
We use ?roff and MS-Word, as well as Ventura, LaTeX and everything else as
well. The problem is not simply ASCIIfying the text, but rendering images,
figures, graphs and whatnot that are difficult or impossible to ASCIIfy and
are the reason to select PostScript in the first place. When we produce
text-only documents we do exactly as you do - ASCIIfy with readily
available conversion utilities.
Dave
Dave Crocker
We may recall that people used to refer, rather simply, to having
their software run on "Unix". These days, people are a little more careful
to indicate the specific FLAVOR of Unix that it runs on.
I use WordPerfect, at home, and am going through some wars to get it
to print a postscript file on a non-directly attached and non-Apple
postscript engine. No luck. Wordperfect apparently produces a file
that is a) broken and b) tailored specifically to the Apple. Even if I
have some details wrong, my point is that we need to have VERY precisely
specified details about what Postscript is acceptable and, I believe,
we will then find that much/most Postscript-generating software is
marginally non-compliant.
There can be no reasonable question about the benefit of being able to
use mixed text/graphics for document production and it seems remarkable
that there is still a barrier to doing it. I suspect that there needs to
be a coordinated effort to get a sufficiently universal and consistent
mechanism, particularly if you wish to avoid excessively favoring any
single word-processing/publishing-package vendor.
Dave
Rick Adams
with the notation that some figures may olny be found in the postscript
versions.
David L Stevens
> The problem is not simply ASCIIfying the text, but rendering images,
> figures, graphs and whatnot that are difficult or impossible to ASCIIfy and
> are the reason to select PostScript in the first place.
I'd find it useful even if only the text were available in ASCII
form. If your concern is the wasted time generating a complete document, I
agree and I'd say "don't bother." If you make the text available, then
I can use RFC's as (many are) intended-- as references. That's what
distinguishes them from many papers, where the overall meaning is more
important than the details.
Being able to search and quote text from a standard is certainly an
important part of having the standard-- to have a "judge" when implementations
differ. It's clearly more time consuming to use a paper (or even on-screen
display PS) document and either type in the text or say "section X, about
page YY, if you're using a Z-point font," etc. etc. when sending e-mail to
point out why an implementation isn't quite right.
I just want ASCII for search and reference text and agree with all of
your (and other's) points about moving towards easier preparation, higher
quality and greater expressive power.
Just leave a hacked partial paper around to be used as a full index
and not as a duplicate or replacement for the PS version and I, at least, will
be happy.
--
+-DLS (d...@mentor.cc.purdue.edu)
Frank J. Wancho
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
Eric P. Scott
I hadn't considered, and a valid point. So far the best
suggestion I've seen is { complete PS, plain ASCII, illustrations
} . Then we don't have to upgrade 118K+ sites.
Just NIC.DDN.MIL. :-)
I don't know how things are where you live, but in California if
you don't have PostScript capability "at home" you go to the
local copy shop with a diskette. Since they make a healthy
profit on laser printing, having a "just the illustrations"
package appeals to the save-every-nickel types. For text-only
material, I still want the PostScript. For a small example, look
at the Internet Resource Guide files on NNSC.NSF.NET.
Everything's in both forms, the information's identical, but the
PostScript is much easier on the eyes.
Rather than argue about how widespread PostScript is, why not
support software such as FSF's GhostScript that will make it
unquestionably available to the neo-Luddites?
-=EPS=-
P.S. Authors don't need to assume responsibility for mailing
hardcopies when the NIC already provides this service.
Russ Nelson
Or use some PostScript interpreter to put the figures into a well-known
bitmap format, like X11 bitmaps, or GIF images.
--
--russ (nelson@clutx [.bitnet | .clarkson.edu])
Live up to the light thou hast, and more will be granted thee.
Peter da Silva
> you don't have PostScript capability "at home" you go to the
> local copy shop with a diskette.
Do they accept either cpio or tar-format disks or cartridges? No? Well,
I'll just use my personal computer. How about 16-sector hard-format CP/M
diskettes, or AmigaDOS 880K floppies? This is only an option if you have
an IBM-clone (running Messydos, to boot) or a Mac in-house.
> Everything's in both forms, the information's identical, but the
> PostScript is much easier on the eyes.
1245(yes)P
1960(Postscript)P
128(is)P
2250(much)P
196(easier)P
1747(to)P
456(read)P
6(.)P
> Rather than argue about how widespread PostScript is, why not
> support software such as FSF's GhostScript that will make it
> unquestionably available to the neo-Luddites?
Matter of opinion. From my point of view folks who want to tie us down in
the paper age are the Luddites. I have enough slaughtered trees floating
around my office as it is. Hardcopy, to me, means "time to order another
bloody filing cabinet".
And I have a question about GhostScript. The support files and fonts in
this package fall under the Copyleft. If RMS and his buddies are being
consistent, that makes anything printed with GhostScript a derivitive work
and subject to the Copyleft. Is this so, or is RMS making a special
exception for the sake of expediency?
Jack Haverty
MCIMail has a capability which allows me to send it a message for paper
delivery, by running any program on my Macintosh and "Print"ing to a
special output device which creates a file instead of actual output
(i.e., a pseudo-device). I then tell MCIMail that this is an "image"
message, which causes it to laser-print it and deliver the hardcopy.
I'm not sure whether the "image" is actually postscript. It's also a
bit clunky since I have to send any particular message twice - once to
recipients who can accept it electronically and deal with it (i.e. they
have a Mac), and once to recipients who need hadcopy.
It does work however, and demonstrates that there *could* be a server
somewhere on the Internet to which the sender, or receiver, of a
document could send that document and get a hardcopy delivered. It
might make sense to even offer two qualities of output (QOS bits at
layer 7!), one for laser-print, and one for FAX (which could be
delivered to most people directly as well).
Comments? Anyone got something like this working yet?
Jack
Terry Slattery, SECAD
requests have been to retain an ascii version of RFCs. Vint stated that we
should declare a goal and begin working towards it. The most reasonable
goal seems to be the one stated by Marc Gibian.
> 1. always, always provide an ASCII version of all RFCs, since
> as much as we wish it were different, not everyone has a
> workstation, or even a PC, on their desktop.
>
> 2. provide an ODIF version of all RFCs to support interchange
> of the complex, multimedia, form of the documents.
For ASCII versions of the RFCs, most people have been willing to compromise
on having pictures as text and are willing to accept a pointer to the
postscript image. This seems reasonable for all parties. Someone (the
NIC?) could keep track of CAP systems that support ODIF (listed in a file in
the info directory, or in a "How to write an RFC" file), and we could
encourage vendors to begin working on ODIF.
Until ODIF (or equivalent) is widely available, we still need ascii versions
for interchange.
-tcs
ps. I've been wrestling with many of these same issues for my
publications. There are problems with Postscript only files, vendor
specific CAP system formats, and markup languages. Long lived publications
(like RFCs) will need to be ported to each new release of a CAP or become
obsolete (Dave, are you and your people planning on keeping your CAP files
current with each vendor's supported product?). I'm currently using vendor
independent markup languages for text and CAP for producing figures, etc as
a compromise.
Henry Spencer
>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.
Michael Padlipsky
Not only is there no reason for Dave not to furnish an ASCII, unpretti-
fied version, there's a rather good reason for him not to attempt to stand
by his offer to send hardcopy to all requesters of same: he can no more
afford the P**3 (Paper, Postage, Personnel) than Vint can afford to give
all requesters appropriate "iron"....
justtryingtohelp cheers, map
-------
Perry Metzger
>I don't know how things are where you live, but in California if
>you don't have PostScript capability "at home" you go to the
>local copy shop with a diskette.
Sorry, but here in New York, things are different. I still want ASCII,
if you don't mind. The beauty of ASCII is that everyone can in fact
read it. Most RFC's even convert pretty well into EBCDIC with simple
tools.
>Rather than argue about how widespread PostScript is, why not
>support software such as FSF's GhostScript that will make it
>unquestionably available to the neo-Luddites?
What about people who want to read their RFC's today? So far as I
know, GhostScript has no outline fonts and doesn't drive any laser
printers that I own. Besides, it is written in C. What happens to
those people who are using machines other than Unix boxes? Since when
did they become second class citizens? What happened to people without
laser printers? Not everyone has them, you know.
The point here is this. PostScript may claim to be the new ASCII, but
in fact ISO Latin 1 is the new ascii :-).
Perry
Fred R. Goldstein
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.
fred
Stuart Lynne
>Another idea into the fray:
>
>MCIMail has a capability which allows me to send it a message for paper
>delivery, by running any program on my Macintosh and "Print"ing to a
>might make sense to even offer two qualities of output (QOS bits at
>layer 7!), one for laser-print, and one for FAX (which could be
>delivered to most people directly as well).
Yes, lots of people are working on these types of services. Canada Post has
a Fax/Mail delivery service that will send your message (received by fax or
at a post office) to a remote fax machine or laser printed and hand
delivered.
AT&T Mail has fax delivery (and I think mail delivery as well).
X.400 of course will handle it. It's referred to as a Physical Delivery
Option.
Our fax product has a Unix Mail gateway to allow you to send mail via fax.
Just give an address like ...fax!1-800-555-1234!fred and off it goes.
It would be fairly easy to setup a server to offer these types of services
on the Internet. The hard part would getting someone to fund it. Until we
get secure mail services its very hard to bill back to the originator.
I would suspect that you'll see many sites offerring these services to their
own users, but not allowing remote access.
--
Stuart...@wimsey.bc.ca uunet!van-bc!sl 604-937-7532(voice) 604-939-4768(fax)
George William Herbert
from anon ftp wise?
Thanks,
george william herbert
Paul Mockapetris
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
Gary Bridgewater
>This has been a very interesting discussion, but everyone seems to
>have missed what seems to me to be the real problem. Let me give
>it a try ...
Nice try, too. A standard, actual, honest data interchange format as opposed
to a proprietary, multi-versioned pseudo-standard.
Wrong.
Postscript looks OK but I think we are really missing an opportunity here.
We have a chance to solve two problems at once. The new, improved CMIDEF -
Cloistered Monk Illuminated Document Exchange Format.
Surely all of us have a monastery near by which would be all to happy to produce
great looking, hand-lettered (in black and red) copies of the RFCs with
illuminated capitals, gilt edges, all solidly bound on vellum with pure
leather binders. The data can be conveyed between the monasteries with a few
simple dial up lines provided by helpful local sites. Or, even better, at last
something for all those homeless burros in Arizona to do - ferrying the
originals from site to site.
Their income would be supplemented and you would have something to treasure
for the rest of your life. Just the index alone would be suitable for framing!
Special Illumination Groups could spring up - we could trade them like baseball
cards since each one would be unique. Bind Or Frame sessions could be held at
Interop.
Paper? Hell No - Vellum Forever !!
;->
--
Gary Bridgewater, Data General Corp., Sunnyvale Ca.
ga...@sv4.ceo.sv.dg.com or
{amdahl,aeras,amdcad,mas1,matra3}!dgcad.SV.DG.COM!gary
No good deed goes unpunished.
Roy Smith
> 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- r...@alanine.phri.nyu.edu
"The connector is the network"
Gary Winiger
>
>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..
Ian H. Merritt
>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: i...@NRC.COM
Guy Middleton
> 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
Jon Zeeff
ascii) tacked on to the end.
You have just one version, you can grep through it, you till have nice
diagrams for people who can deal with cutting out and printing postscript.
Might also be nice if there was a us mail address that you could send
off for paper copies.
--
Branch Technology | ze...@b-tech.ann-arbor.mi.us
| Ann Arbor, MI
Mi...@udel.edu
Sources to RFC-1119.PS are in the compressed tar file pub/ntp/ntp.tar.Z
on louie.udel.edu. See if the files ntpr.doc and ntprh.doc come close
to what you want. They are in MS-Word format.
Dave
Mi...@udel.edu
I fully understand your desire that the CAP source files follow the
latest versions of vendor software; however, I do not have the resources
necessary to upgrade all my old submissions to follow the newest versions.
Maybe in time ODA will converge, the vendors will follow and I can get
some sleep.
Dave
Ds
k...@ut-emx.uucp
(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
k...@hermes.chpc.utexas.edu University of Texas System
Center for High Performance Computing
Steven Grimm
binary to comp.sources.unix.
---
" !" - Marcel Marceau
Steven Grimm Moderator, comp.{sources,binaries}.atari.st
sgr...@sun.com ...!sun!sgrimm
Peter da Silva
> 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: pe...@ficc.uu.net, +1 713 274 5180. Fun: pe...@sugar.hackercorp.com. `-_-'
``I feel that any [environment] with users in it is "adverse".'' 'U`
-- Eric Peterson <lcc....@seas.ucla.edu>
Ben Thornton
>What about people who want to read their RFC's today? So far as I
>know, GhostScript has no outline fonts and doesn't drive any laser
>printers that I own. Besides, it is written in C. What happens to
>those people who are using machines other than Unix boxes? Since when
>did they become second class citizens? What happened to people without
>laser printers? Not everyone has them, you know.
Hear, hear.
Postscript is very inefficient about getting something onto paper in a
hurry, so far as text is concerned. Where is excels is its ability to
execute algorithmic procedures for plotting mathematically-defined
entities (besides the cubic-splined fonts). Unfortunately, not very
many applications support that aspect of the language. Oh well.
--
Ben Thornton packet: WD5HLS @ KB5PM
Video Associates Labs uucp: ...!cs.utexas.edu!oakhill!val!ben
Austin, TX fidonet: 1:382/40 - The Antenna Farm BBS
CE...@a.isi.edu
check with Craig Partridge at BBN (Cr...@nnsc.nsf.net)
concerning host count. I think I got this data from Tracey LaQuey
at University of Texas.
Vint