Feature:A Response to IPP 59
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.
LPP - The birth of BEOWULF (Score:1)
Linux to Postscript printers. This is with the aid of my soon to be announced GCC postscript backend. The Linux port will also include MPI, and I am now considering implementing IP over IPP. This will obviously be most efficient, as IPP will be implemented already on the hardware.
I need volunteers to help with the XFree86 Port, as I do not know X that well. I have nearly completed the conversion of Mesa, so it will contain direct rendering of OpenGL-to-postscript to be speedy. I am aiming for inclusion in XFree86 4.0 .
Any one want to help?
leader@postscriptlinux.org
URL doesn't mean HTTP (Score:1)
The first piece of information in a URL is the protocol. Currently, the most common protocols used are http, ftp and mailto. There is nothing to stop them from petitioning the IETF for adding an ipp protocol to the URL standard. Such a protocol could have it's own security mechanism, default port, and so on. From everything I've seen, this is what they intend to do.
Postscript (Score:1)
Eliminating Drivers (Score:1)
Seems reasonable enough -- the client/driver can thus easily tell the user that my printer can print in 3D. But, at print time, how can 3D printing data get to the printer if the client's never heard of such a thing?
Seems to me like you'd have to update your client/driver somehow, which is a concern you want to avoid with IPP. Otherwise you'd have to encapsulate the 3D instructions at the application level and then count on the server/driver at the other end to understand what you mean. But if you require that, you're requiring the remote user to know about the printer and have the right software to print on it, specifically -- in other words, forcing the user to worry about drivers, again.
As I believe I've already said, IPP sounds like it'll handle non-bizarre cases just fine -- mind you, so will Postscript.
Eliminating Drivers (Score:3)
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.
It's all nice, but this is how I do that: (Score:1)
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.
<whatever produces postscript to the stdout>| \
ssh firewall.foo.com ssh internalbox lpr -Ppsprinter42
IPP: Hmmm, Postscript on IP? (Score:1)
---
Kinko's could sell printer accounts. (Score:1)
Sounds cool to me!
IPP layering and security (Score:1)
IPP is using HTTP as a substrate, but (at the insistence of the Internet Engineering Steering
Group) it's using a separate port. So it won't submarine through firewalls (at least by default) and layering is less of an issue. Basically,
IPP defines MIME types for use in POST and the response to POST.
IPP 1.0 uses HTTP/1.1 digest authentication; though most vendors will probably support SSL 3 also. IPP 1.1 (still in draft stage) will allow
use of TLS 1.0 in addition to HTTP digest.
Note that IETF approved IPP 1.0 as an Experimental protocol; IPP 1.1 is expected to (eventually) be approved as a Proposed Standard.
I did advertising design/layout for a few years (Score:1)
PDF sucks dead pigs through a straw.
I'm sick and tired of receiving documents that
cannot be decoded with the PDF tools that are
available on my machine. I think it's actually
worse than PostScript, if that's possible.
Document Formats ARE supported by IPP (Score:1)
Having implemented a commercial IPP solution, I can tell you that IPP does indeed support document formats via the "document-format" job attribute. Document formats are basically MIME types, for example application/postscript, application/text-plain, application/vnd.hp-pcl, or for those printers that can autosense emulations or for driver data, application/octet-stream.
KISS (Score:1)
What's wrong with emailing the document to me: To: From: Subject: For: begin 644 job1.ps ... end On my side, All I need is a user called printer with a .forward piping the mail to a simple script (which can hand it off to lpr).
If security is an issue, GPG the email, and I'll pipe it through GPG and then to the script.
If the client is a windows box, it will still need a driver or special handling, but everything involving a printer (including IPP) in windows needs a driver. OTOH, from a Unix box, magic filters can be easily hacked together to handle this (including using a keyserver, email, or wget to grab the public key).
That sort of setup is also transport agnostic. If email is too unreliable, POST to a cgi script on the web server (use SSL if security is a concern).
In short, there is no need to create so much hype over something that can be handled easily with a few scripts.
No. Just use Ghostscript. (Score:1)
The problem with Postscript (Score:1)
IPP for the Internet, JINI for the intranet? (Score:2)
IPP is a language? (Score:1)
So, how close is that? Is this what all the fuss is about? Seems to be the next logical step for a Print Server to me, my question would be this:
If you can use a print server, can you alias it to other IPP's so the same print server (physical box) can run multiple printers?
Lemme see... (Score:1)
Methinks what they are trying to circumvent is the proliferation of all those fugly cheap no-brain printers that require a Windoze driver to do their rasterisation work (like most ink-jet printers nowadays).
Document Formats ARE supported by IPP (Score:1)
^D
In other words, you do need drivers after all (Score:1)
I wonder if it's possible to create a PPD file for IPP?
--
Timur Tabi
Remove "nospam_" from email address
This is much less scary now (Score:2)
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.
Ohh... Ohh... I know... (Score:1)
You could put the printers in some sort of large rack with a robotic arm, and have the robotic arm colate the pages from each of the printers into one giant output bin. (like an OSAR - Opticalmedia Storage And Retrival - unit... except for paper.)
Why does the phrase "Get a life." come to mind?
Loren Osborn
Good Arguments (Score:1)
This is much less scary now (Score:1)
Client: connect(),
keepAlive = true;
Accept: Postscript/1.0,Win32DIB
Server: 302 Redirect, Location of Postscript printer is: URL1, Location of Win32DIB printer is: URL2
Client: OK thanks, close()
Client: follows redirect
Client: connect(), keepAlive = true
HTTP/1.1 PUT Content-Type: application/win32DIB (data follows here
And that's it. Just by using the facilities of HTTP servers and the protocol you should get automatic language selection based on what you have. Redirects probably would be the best way to then send it to the printer that supports both your requirements and the internal driver requirements.
¿LPP - The birth of BEOWULF????? (Score:1)
If they can write a ray tracer in PS I'm pretty sure that somebody must have hacked a network driver with the stuff somewhere....
IPP for the Internet, JINI for the intranet? (Score:2)
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!
This is much less scary now (Score:1)
I think, however, that a printer that groks IPP would tell the client which file formats it can print, then it would be up to the client to translate the file into a stream that the printer can understand
another idea for the FAXing analogy could be that the IPP device would automatically translate text documents into the language that the recipient is most comfortable with (of course the translation software would have to be good, but...)
IPP vs. lpr (Score:1)
URL doesn't mean HTTP (no, but the standard does) (Score:1)
IPP Spec calls for "drivers" (Score:1)
Open standard (Score:1)
The author of LPRng has already announced he'll be implementing it, from a post in the other IPP article.
Junk standards (Score:1)
Traditionally, the standards which can get themselves accepted and widely adopted by multiple vendors/systems (which is one of the things we still have in the non-MS world) tend to have the great benefit of simplicity: they only try to do one thing at a time. The IPP, though built on HTTP (at least they've figured out the idea of composing standards from smaller building blocks), seems to want to do several things: printing, platform independence, security, printer management.
It runs the risk of becoming another mongrel like SMB.
Driverless network printers? (Score:1)
I CAN see a use for IPP as a facilitator, a mechanism for regulating and advertising access to a printer. And I'm a big fan of CORBA and related technologies. As long as IPP stays in the role of facilitator and not Yet Another Printer Driver Protocol, I'll welcome it into my toolkit.
Microsoft (Score:1)
Personally, I think it's neat-o, but hey... I've been wrong before.
Microsoft (Score:1)
You're half wrong. The big half. (Score:3)
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):
In other words, presumably something like HTTP content negotiation, but in reverse.
The problem with Postscript (Score:1)
Any turing machine is subject to the halting theorem, which is basically the fact that you can't tell if a program will finish without running it. (Any 'analysis' of the program to determine halting is essentially another form of running the code) This is different from simple infinite loops (which are easily detectable). An example would be a program which tries to calculate the complete value of Pi. _We_ know that it's irrational, but the program doesn't, the compiler doesn't, and the machine doesn't.
The halting problem means you can't tell how far away the program is from finishing, if it ever will.
Postscript is a language. Thus, it is subject to the Halting problem. You know exactly how long it will take to load a bitmap, but you don't know how long a postscript program will take to finish. Who's had a printer blink away for an hour without producing output or errors?
In an open network, you're therefore resigned to the fact that people can submit 'programs' to your printer. If there are bugs in the printer rendering code, you've got the possibility of a virus or malicious crash. If not, you've got the possibility of a denial-of-service attack because of halting. "Timeouts will solve it" you might say, but then how do you make sure large-but-legal documents don't get killed?
And, job management goes out the window when you can't predict how long a job will take. It's easy to construct a 10k postscript program that takes 100 times longer than a 10Mb file. You can't measure progress, either.
Though postscript is a beatiful system, and widely implemented, it's too much for the task. Much too much. HTML showed us how simple interchange formats can be good. Don't ignore that lesson.
I did advertising design/layout for a few years (Score:1)
Acrobat does a _great_ job on this already!!
Basically, if this thing is sturdy enough to keep vendors from playing the extend game, then it will succeed. I really like the idea, though. And I speak without having read the standard.
Are you down with IPP? (Score:1)
So, what does this have to do with IPP. Well, even if I could print in Chicago, even though I live in Austin TX, what would be the point. Why would I want to be able to print in Chicago. I can't feesably get the printout. If I wanted to send a document, I would e-mail a PDF, or text document, or whatever. Then the recieving party could choose to print it if they wanted to. There would be no need for me to be able to force their printer to print it. The only use for IPP in this sense, would be to cause trouble.
Now IPP might be usefull for Intranets. You could use IPP to print a document down the hall, and then get up and go get it. However, I can already do this with Post Script, and lpr. Almost all printers understand Post Script. I don't see the need to have IPP, if what I have already works well, and is cross platform capable. As it is, PS is available for all platforms.
Anyway, I have to go now, I am going to order a Pizza in Deleware. I wonder if they will guarantee 30 minute delivery?
Microsoft (Score:1)
"drivers" - means "drivers" (Score:1)
8.2.3 Document-format
Name-Length : 15
Name : Document-Format
Syntax: Keyword - values taken from [RFC 1759]
Meaning: Specifies the type of data included; PCL, PostScript, etc.
So it appears that one needs not only the IPP client software, but also a print driver matching the remote print device on the client machine (or ~shiver~ one emulated by the remote) to initiate a print job.
IPP Spec calls for "drivers" (Score:2)
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.
Good Job... (Score:1)
Would be a good scripterz kidz joke... (Score:1)
¿LPP - The birth of BEOWULF????? (Score:1)
Bottom Line: Still Platform Dependent (Score:1)
Microsoft specific problems? (Score:1)
IPP is a language? (Score:1)
As to setting up multiple printers on the same print server, IPP is designed around that idea. The spec even hints toward advanced capabilities, such as connecting to the print server, telling it what type of job you have, and the print server seamlessly picks the best printer for the job.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
Eliminating Drivers (Score:1)
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
Project Design Doc is lossy (Score:1)
Yes, the missing link. (Score:1)
I have been using magic filters, but they are just a kludge. New printer formats can be confused with others. I have been tending to make clients always use Postscript, but IPP will allow more flexibility...and safer configuration by users.
Down with lpd, up with CORBA-like solutions! (Score:1)
I've been hacking printcaps and print filters for six years, and I'll be
glad when lpd is dead and gone. lprNG isn't really an option, since
(correct me if I'm wrong) it doesn't meet the DFSG. I don't know if it
solves my main gripes with lpd, anyway.
Consider this true scenario. I set up an inkjet on a Debian GNU/Linux box
and set up netatalk and papd so Macs can print to it. Someone sends a 20
page print job to it, and then realizes the margins are wrong (a Ghostscript
driver screw up, the driver author hard-coded A4 margins and doesn't reply
to my emails). He can't kill the job from the mac, so he turns the printer
off and on. Now it starts spewing garbage characters. He panics and
reboots the GNU/Linux box. Only the job is still in the queue, so it starts
spewing garbage again. He calls me at home, I tell him to telnet to the
GNU/Linux box and run lprm. Only it doesn't let him, cuz the job is owned
by root (papd is a root daemon). So then I ssh in from home, su root, lprm.
But it keeps spewing garbage because the ghostscript process is still
running. Argh!
Sure, I came up with a solution, a desktop button that runs an suid root
program to clear each printer queue (there's no "lprm -all") and does a
"killall -9 gs". But this is a kludge. What I really want is network
methods like printer::clearqueue() and printer::reset(), have it
automatically kill the filter process, a sane way to handle permissions and
job ownership (no, I don't want to teach everyone how to use "sudo lprm"),
and it would be nice to do away with having a different queue for each
printer setting (draft, paper, transparency, two-sided, 2-up, etc.).