ietf-822
[Top] [All Lists]

Re: ps;1 or ps -- problems with the postscript application type

1992-03-28 11:52:24

Ned,
   While I agree with your conclusion that Postscript should say and
with most of the reasoning that leads up to it, perhaps there is the
germ of a good idea or two hiding beneath the "it can't be precisely
defined, take it out" reasoning.
   If I'm a user, and I go to send a Postscript file to someone else,
I'm likely to have a very good idea whether I've tried to construct
things using an interchangeable Postscript or whether I've used enough
weird stuff to require "prior agreement" with the recipient.  Now, it
may not have gotten it right, but I'm likely to know if I've made the
effort.  It seems to me that might be a useful parameter-distinction to
make, so that, e.g., a mail receiver/reader could be able to make a
better guess as to where it could display or whether the thing had to be
routed to something special (this has some of the same tone as the
text/file issue, doesn't it?).
   Much of MIME, at sort of the second level, seems to be designed
around the assumption of letting the user (or originating UA) send
useful information to the receiver (or target UA).  It would seem that
this "intent of interchange" vs "big, complex, preformatted file"
distinction would be consistent with things one might want to tell a
receiving UA.
  So, would it make sense to spread a little sugar on the syntax to
permit senders to distinguish between "this is a Postscript file that is
intended to be enough self-contained that almost anyone with Postscript
capability should be able to read" and "this is a Postscript file that
you are going to need to know my conventions and architecture to read"?
   Note that I'm *not* suggesting that we need to define (precisely or
otherwise) just what is in the minimal set.  I think that, to a 90%
level at least, we pretty much know.  The idea is to capture and
transmit sender intent.

I don't necessarily see this as something that needs to be dealt with
"now": it might be better to advance the document and get a little field
experience as to whether it is as much a problem in practice as people
think it might be.

    --john
p.s.: I think your characterization that suggests that no revisable form
file or markup file is useable without external information is a bit
exaggerated.  Offline discussion on request.