Feature:A Response to IPP
I just got through browsing through all the comments posted about CNN's IPP story. I thought I'd send you my thoughts on the matter, since I believe I'm in a rather unique position to talk about IPP. From June, 1998 through the end of February, 1999, I worked with 3 other classmates on a Senior Project sponsored by Xerox Corporation, mapping the current IPP 1.0 specification into a distributed object model, using Xerox' Inter Language Unification (ILU) system, which is Xerox' Palo Alto Research Center's CORBA like system.
(Here comes the disclaimer), the views that I've represented here are my views, they do not represent the views of Xerox, Rose-Hulman Institute of Technology, any members of the Printer Working Group, or any members of my Senior Project team.
Why is IPP better than lpr, HP Jet-Admin, or any of the currently available printer solutions?
In all the discussion, one major point, I believe, has been missed. One of the major goals of the IPP projects is to eliminate the client's need for printer drivers. lpr needs drivers, HP Jet-Admin needs drivers (besides only working w/ HP printers :)), NT/win98/95, MacOS -> they all need drivers to communicate with printers. What IPP allows for is a communication between the client and the printer (or printer server, the two do NOT have to be the same), where the printer informs the client of its capabilitie. The client can then present these capabilities to the user who can select which of the capabilities ought to be used in printing the document. However - this isn't *required* ... a print job can be constructed and 'validated' against the particular printer you want to use, and the client can simply inform the user if the printer is capable of printing the document with the settings you've previously selected. I could go into many more example situations where this printer/client communication can be extremely useful, however - suffice it to say that the language is extensible, so the sky is the limit, in this sense.
What about security?
Whenever we hear about something being 'at large' on the Internet - security concerns are raised. Let me express my faith in the members of the Printer Working Group. I've personally met many of the individuals involved with developing the IPP specification and I've actually *read* the IPP specification (many, many, many times). The security that is built into this system, this *open standard* system, is very much better than anything we have now. And if there's a system out there that has BETTER security, please - contribute your knowledge to the standard, don't sit and whine about how IPP is going to be insecure and open to attacks. Any online system is open to attacks, just because a system exists. This doesn't mean the system ought to be rejected/abolished ... if this were our modus operandi, then we would close down the Internet, close down the phone systems, close down our utilities. All systems that are in use today are open to attack, in varying degrees. Security means limiting the degree to which a system is vulnerable to attack. Perfect security costs an infinite amount of $$ and is not feasible.
Is everything CNN said true?
Well, no - not exactly. Microsoft does not hold the key to the success of IPP - you do. We face a problem these days of trying to get another person to visualize what we've created, without being physically present to show them. The fact that we will be able to FAX in color isn't the *only* thing that IPP will allow us to do. Think about how FAXing (the *primary* means of communication for many large corporations) takes place today. Your FAX number is on your business card ... so, someone needs to send you some information ... your FAX number is busy, so they try again ... still busy. As some phone company commercials have touted, you're potentially losing business. Then ... how many times have you received an illegible FAX? I have. How many times has a FAX been misplaced on its way from the company FAX machine to your inbox? IPP is a new player in the field of communication that is an effort to address some of these major problems.
Imagine the following situation (which I've attempted to make somewhat realistic): you're an advertisement/marketing firm with a new layout for a magazine spread, for company X. As is always the case, the more time you have to work on this spread, the better it will be. Working up to the deadline is almost a certainty in the fast paced business world. If company X, your client, needs this spread for their board meeting this evening. It is too late to send color printouts of the new layout via Federal Express. Currently, your only recourse is to send a FAX or to attempt to negotiate a document format that your client understands and that doesn't lose any of the layout that your expensive graphics software allows for (Pagemill, Illustrator, Corel?). Enter IPP. Your client contact simply gives you the url of a printer that is capable of printing your layout in acceptable quality, as well as the username & password to access the resource, OR, the client sends you the url of the high quality, high capacity color printer at the Kinko's across the street. Problem solved. Notice that you don't need to (a) know what kind of printer is printing your layout, only the capabilities of the printer are important. Also, (b) you didn't need to download drivers for the printer that you are using. These are *very* important useability issues.
All these things that I've tried to visualize for the readers of Slashdot represent only a fraction of the possibilities that IPP allows for.
I encourage you to read the IPP Model document as well as the Specifications and Implementers Guide for IPP.
If you'd like more information on my Senior project, feel free to visit this page.
0 of 59 comments (clear)
No comments match the current filter.