[694] in Enterprise Print Delivery Team
thanks and a couple of follow-up questions
daemon@ATHENA.MIT.EDU (oliver thomas)
Thu Nov 16 16:13:01 2000
Message-Id: <200011162112.QAA176133@mufasa.mit.edu>
To: printdel@MIT.EDU
Cc: oliver thomas <othomas@MIT.EDU>
Reply-To: oliver thomas <othomas@MIT.EDU>
Date: Thu, 16 Nov 2000 16:12:56 -0500
From: oliver thomas <othomas@MIT.EDU>
david and mary ellen, thanks for your presentation at support-tl today.
it was very informative. i have a couple of follow-up questions for the
team. the presentation was mostly high-level overview stuff, but i think
i understand the model at this point. just to make sure, though, i
currently see it working as follows (when printing form a client machine
as opposed to from an application server):
1. client app (word, excel) sends document to special printer driver.
2. printer driver formats print job (presumably as a postscript file),
encrypts the output, and sends it to klpr.
3. klpr authenticates user to print server and passes the encrypted
document to the print sever.
4. print server sends document to printer (there may be a second decrypt/
re-encrypt step here).
5. printer decrypts document and prints it.
this is the only way i can see it working without requiring a modification
to our existing klpr implementation. if i am missing something, though,
please let me know.
question: will the infoprint manager accept unencrypted documents?
i.e. do we place the burden of security on the client or will it be
enforced on the server? i ask because the concept of a "printer driver"
doesn't really exist on athena. an application generates postscript and
passes it along to klpr. also, i would imagine that special printer
drivers don't exist for all platforms. it would be useful to be able to
print unecrypted jobs directly from athena or pc's without a custom
printer driver in cases where security is not an issue, but cost and
resource utilization are. examples would be the e-reserves project, the
printing of course materials, and so on. the web-based alternative works,
but is cumbersome. lpr, on the other hand, is pretty well integrated,
especially on athena.
my second question is really more of a suggestion: david mentioned that
ibm is currently working on modifying a web interface for our needs which
will accept postscript files and process them through the enterprise
printing system. it would be really useful if this interface could also
deal with pdf format files directly, perhaps converting them to postscript
on the server end. a lot of web content, course materials, forms, and
other documents that would be prime targets for a central, large capacity
printing solution are in pdf format. being able to upload these files to
ipm directly without having to go through a conversion step would be a big
win for support, and may be do-able with very little effort while ibm is
still contracted for the web interface.
my two cents. thanks!
oliver
