Feature:A Response to IPP

Brice Ruth has written a response to the lengthy debates sparked a few days ago on these pages regarding the new Internet Printer Protocol. He has a lot to say, and from an informed position. You should check this out if you're interested in the issue- a lot of good information seperating fact from fiction. Hit the link below to read it. The following was written by Slashdot reader Brice Ruth A Response to the 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.

Comments

Eliminating Drivers

[Eric S. Smith]

One of the major goals of the IPP projects is to eliminate the client's need for printer drivers.

Except, of course, for an IPP-friendly driver.

Similarly, you can print a Postscript file on any printer -- provided that you can translate the Postscript into something the printer likes. In this case, you have to translate your print job into something that IPP can handle. For the user, it comes to the same thing.

Doesn't the IPP impose a sort of lowest common denominator, since it is standardized, and it is what tells the client what the printer can do? How do I tell an arbitrary client that my printer can print 3D and backward if the standards designers didn't think anyone ever would?

This isn't necessarily bad, but it means that I'm unlikely to use IPP to print to my own new turbo whiz-bang printer (until a new version of the protocol fully supporting it comes out). If I had occasion to do remote printing to others' printers, or to allow others to do remote printing on my printer, IPP would become a plausible choice.

OTOH, if they wanted to print 3D and backward -- if the whole point of their wanting to print on my printer was that it could do that -- then we'd have to do the negotiate-a-file-format, send-me-the-file shuffle, as before.

Similarly, a Java binary may run anywhere a JVM can, but we can't expect it to exploit the features of a PIII and a G3 equally. The advantage is that it runs at all. The question is, how good is "at all," and is that good enough?

If IPP lets me print colour bitmaps on most common/popular printers, that'd probably do the trick in most cases.

IPP for the Internet, JINI for the intranet?

[Moredhel]

Has anyone looked at IPP and JINI together, and figured out how they could help each other, and interoperate, at least as far as connecting printers to users is concerned?

This is much less scary now

[substrate]

I haven't read through the whole document, but it scares me a lot less now and I can see the utility. There are a couple more needed items in the protocol to make it really useful, but OpenSource is pretty good at that:

1) Protocol translation, there needs to be a mechanism so that the transmitted document is translated to the appropriate language for the printer. For instance if you're sending a PostScript document to somebody with an Epson ink jet printer it should be able to figure out that running the document through GhostView will do the trick.

2) Colour matching, this protocol would be a blessing to the graphic design community but they need colour matching. An additional datatype has to be specified that sends along an optional colour map and applies a corresponding one to make the colour output match what was intended. GIMP also needs this if its to be a serious contender by the way, the last time I looked it didn't.

IPP for the Internet, JINI for the intranet?

[Mithrandir]

As I understand it (I know lots about HTTP and networking, and enough to be dangerous with JINI), the two couldn't work together nicely without a lot of extra work.

The main cause for the difference is that JINI relies on RMI to do the dirty work of communications. RMI is based on Sockets, so are HTTP connections. Both of them form at least some layer of abstraction that are totally different. For example, to use HTTP in a Java application normally you just do this

java.net.URL url = new URL("http://www.vlc.com.au/");
Object contents = url.getContents();

Now on the JINI side, you do a lot of different things (too much code to explain here). You can't simply layer the HTML over the top of the JINI calls.

Now, stuff that I'm playing with for the IETF, can do this sort of stuff. URNs are a sibling to URLs but without the location and protocol specific parts. So, it is technically possible to name a printer eg:

urn:kinkos:somestore_id/the_colour_lazer/2

Ask for a connection to it and then pass the document down it. Underneath all of this JINI would find the printer for you and then IPP would pass the document to the printer. Having seem this IPP stuff come back into my radar I'm really tempted to hack this together over the top of my existing URN java libs. Also, a JINI resolver is on the way soon so I reckon given a couple of months I could have this whole shebang working for ya!

You're half wrong. The big half.

[hatless]

Yes, a legacy desktop app that's printing via OS printing services would need a generalized IPP driver.

But regarding a need for a driver for the end printer, no, the point of IPP is that the operating environment does not need to know the printer's capabilities or have a driver for the printer itself. Rather, I assume they're doing something like the following (and I'd have to read the spec to see if this is exacltly right):

1. the print request starts by asking the IPP server what kinds of print jobs it accepts
   
2. the IPP server responds by stating what kinds of jobs it accepts (postscript, HTML4, HPGL, XML+XSL, plain ASCII, whatever). There's even an opportunity here to offer the client something akin to a printer description file so the client can do optimizations based on available resolution options, etc.
   
3. the client decides which of these formats it likes best, and sends the output that way.

In other words, presumably something like HTTP content negotiation, but in reverse.

IPP Spec calls for "drivers"

[Processor AL]

To quote the IPP ftp://ftp.pwg.org/pub/pwg/ ipp/new_REQ/ipp-req-981116.txt "Driver here refers to the code installed in some client operating system to generate the print data stream for the intended printer. The actual details for installing a printer driver are operating system dependent and are also outside the scope of IPP. However, an IPP printer or a directory service advertising an IPP Printer should be capable of telling a client what drivers are available and /or required, where they can be found, and provide pointers to installation instructions, installation code or initialization strings required to install the driver. See section 4.1 (SECURITY CONSIDERATIONS) for security implications of driver download and installation."

Am I missing something here?

IPP in concept may be a good idea and we may well find ourselves shipping things to Kinko's for output in the future. Why not use PostScript instead of creating a whole new markup language that will no doubt end up with vendor-specific rendering issues similar to current web browsers? Anyone who has tried to make a webpage look good cross-platform/cross-browser knows what I am talking about...

Save your flames about PostScript being a proprietary architechture; one of the things Adobe has been able to pull off with PostScript is a standard for printing that you can send anywhere and obtain predictable results in the output, which is exactly what I would want if I were sending output to a client as described in Brice's hypothetical situation.