[703] in Enterprise Print Delivery Team
Re: thanks and a couple of follow-up questions
daemon@ATHENA.MIT.EDU (David F Lambert)
Sun Nov 19 07:58:55 2000
Message-Id: <10011191258.AA14514@MIT.EDU>
Date: Sun, 19 Nov 00 07:21:28 EST
From: David F Lambert <LAMBERT@MITVMA.MIT.Edu>
To: oliver thomas <othomas@MIT.EDU>
Cc: Enterprise Printing Delivery Project Team <printdel@MIT.EDU>
In-Reply-To: Your message of Thu, 16 Nov 2000 16:12:56 -0500
On Thu, 16 Nov 2000 16:12:56 -0500 Oliver said:
>
>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
Hi Oliver,
The team appreciated the time at your Support TLs Meeting last week. Thanks
for your follow up - it means somewhat one was listening & cared! :)
In the desktop scenario you presented, a new print driver would need
to perform the encryption of the Postscript file or a separate encryption
tool would be needed to encrypt a Postscript file from a standard print
driver.
I was not as clear about the encryption stuff as I could have been. We
are NOT encouraging encryption due to the lack of standards in this space.
We had a number of discussions with ITAG to resolve this issue. IPM
will not enforce encryption. It will be up to the clients to decide
if encryption is required to protect their sensitive print files. At
this point in time, only the student information systems folks are
pursuing encryption. ITAG supports a model where the customer needs to
make this call. We're hoping there are few needs for encryption since
the industry standards don't yet exist nor do any current printers sold
come with a built in decryption function. IPM basically passes an encrypted
file thru the IPM server to the printer.
So, I could have been clearer that IPM can handle encrypted print files but:
- there are no industry standards
- requires point solutions TBD by the customers
- we are not recommending de/encryption s/w or h/w
- we believe there are very few applications which require encryption
- ITAG has not made a formal statement on the topic from their Web pages
- it is the customers' responsibililty to determine if encryption is required
for their files
- it is the customers' responsibility to evaluate and select de/encryption
s/w & h/w
Your second issue re handling PDF files directly by the browser submittal
function is a good one. The scenario you present makes sense to me -
and rings true for what we think Admissions might use too. They plan
to receive applications in PDF and wish to print these centrally thru the
new service. Allowing the browser to snarf up PDF files and have the
server turn them into Postscript seems reasonable. However, please
note this may require two steps in the server since currently our
larger print engines speak IPDS not Postscript. So, the server
may have to convert the PDF to Postscript and then "transform" the
Postscript datastream to IPDS. We'll pursue your suggestion with IBM.
Thanks again for the note, Oliver. Just holler if my response didn't
make sense...
-Dave
for the Enterprise Print Delivery Project
