Slashdot Mirror
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.
Don't get me wrong; IPP's a nice idea. I just wish it weren't based on HTTP; the layering issues get Interesting. HTTP just *started* using SASL; what's IPP doing for security these days?
Uhm, the printer has to understand what you're sending it. IPP doesn't seem to have a standard format (ie. postscript) for actually sending the data.
So, beyond having an "IPP" driver for the desktop, an operating environment needs to know what kind of data the remote print will accept. This requires a driver of some kind. This format will necessarily dictate what kind of capabilities the remote printer has as well.
The only advantage *I* can see is simply the advantage of being a cross platform distributed standard. However the marketing claim of "no drivers!" is silly and overblown, IMO.
So now my webserver needs access to my printer too?
I have been distributing documents in Postscript for several years now, and never had any problems. Postscript is a de facto standard and works pretty well.
The only person who could not make head or tail of a Postscript file was running Windows. Duh.
LPP should mean that all those old printers sittin g on top of cupboards should be dusted off and connected up to form ultimate Beowulf Clusters.
I suggest using Laser Printers for this due to them usually having the highest amounts of memory.
I wonder if there is some way of using the lasers to generate signals down fibre.......
A lot of folks are saying "But I do this in PostScript now, and it works just fine." IPP is the transport mechanism, not the PDL. IPP will do any PDL - it just doesn't care. The shortfall of PS & LPD (or whichever transport you choose) is that you as the client have no idea what features the printer supports unless you happen to have the PPD (and know it's the right one, and it is updated for all the features installed in the remote printer, etc). One of the features of IPP is that it centralizes that information in a place closer to the printer (if not the printer itself).
Imagine never having to find/download/install/update another PPD (as a user, anyway - or having to update your users PPDs as a sysadmin).
Kurt Werle
kwerle@pobox.com
I think this achieves little that magic filters can't or couldn't achieve. IPP seems a crufty solution - not a clean one.
Linux print servers with magic filters work well *now*. IPP seems helpful mainly to the kind of idiots who think that NT is a passable OS.
Maybe you should look at magic filter that you're using--it's probably pretty crufty too, even if it does what you want. I like magic filters as much as the next guy, but they're not standard (as anyone who has typed "lpr foo.dvi" on a system *without* magic filters finds out very quickly), and they still don't help the problem of lpr's crappy access control. I think lprNG helps here (as in having print access doesn't go quite as far) but requiring printcap entries etc. is a pain.
So yeah, IPP is a standard for magic filters in a way, except it also includes a transport layer, access control, and more, plus it asks the client what format the data is in first instead of guessing (or rather, it tells the client what formats are usable, which is almost the same thing).
I am currently in the process of converting
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
They said an IPP printer gets a URL address. Nowhere did they say it uses HTTP. Having a URL doesn't mean HTTP.
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.
----
Open mind, insert foot.
Postscript has many problems that would prevent it from being the protocol for IPP. First, as you've already pointed out, it is pretty proprietary. Secondly, it is a page definition language, not a printer control language. There is no standard way using Postscript to, for example, tell it to print out duplex, or to wait for the operator to load 35# bond letterhead paper, or to colate and staple. These are all things that people need to tell their printers, and Postscript wasn't designed for this level of communication. Hopefully IPP would be.
----
Open mind, insert foot.
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.
Mind the Gap
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.
Mind the Gap
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
Contrary to the popular belief, there indeed is no God.
---
--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";
Posted by jpepin:
Sounds cool to me!
Posted by kmoore:
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.
Posted by kmoore:
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.
Right now, the thing that I don't quite grasp is that of IPP not specifying the document format that the printer supports (i.e., PostScript, PCL, etc.). This would surely conflict with the claim that IPP would eliminate drivers (that is, you would at least have the IPP driver). Suppose that someone creates a new PostScript killer for some new device: wouldn't you need a different driver to print to that printer?
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.
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 Adobe required. Postscript may have started out as very proprietary, but it's getting rather close to an open standard now. Postscript was and is a smart idea - well thought out. An effort to beef up Ghostscript further, and an big push for PS as *the* standard seems like a much cleaner and more direct solution to me.
-- Mike Greaves
For certain classes of languages, you can decide if a program halts or not. It would be easy to write a program, as well, which sees if it takes more than, let's say, one hour, and rejects the input.
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?
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?
Right now, the thing that I don't quite grasp is that of IPP not specifying the document format that the printer supports (i.e., PostScript, PCL, etc.). This would surely conflict with the claim that IPP would eliminate drivers (that is, you would at least have the IPP driver). Suppose that someone creates a new PostScript killer for some new device: wouldn't you need a different driver to print to that printer?
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).
In Soviet Russia, Jesus asks: "What Would You Do?"
And how do you support application/vnd.i-farted-this-crap, if anyone ever came up with it? How do you extend the client's capabilities to support it?
^D
In Soviet Russia, Jesus asks: "What Would You Do?"
I wonder if it's possible to create a PPD file for IPP?
--
Timur Tabi
Remove "nospam_" from email address
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.
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
Loren Osborn
Where I work, IPP would be a god-send. I wish you and IPP much success.
Do not read this
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.
Life is complete only for brief intervals in between toys or projects -- John Dalton
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....
Life is complete only for brief intervals in between toys or projects -- John Dalton
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!
Life is complete only for brief intervals in between toys or projects -- John Dalton
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...)
Hmm, at first look I was like. Um, thats just another lpr hack, whoopdie - just more Microsoft spin (wich is half true). Then I read this article. I come to these conclusions: IPP is a good idea as an alternative to faxing. IPP is a good idea as an alternative to email attchments. IPP is a great thing for lan environments. IPP is different than lpr. Reasons they dont use postscript (imho): there is no free postscript interpreter. ghostscript-alladin is non-free. postscript was designed for printers and therefore not optimised for internet traffic. postscript favors a certain operating system (Unix/Mac), therefore -- microsoft will create own standard and try to clobber IPP if it didn't have its own native printer language (that is easy for any os). Question: Why not PDF? There /are/ free PDF creators/viewers. PDF is convertable from postscript. (well, kind of.) PDF is allready avaliable, and PDF seems to do /alot/. Lastly, all this flaming about "it doesn't have X feature"! (for printing) Remember this: IPP wasn't developed to be a publishers printing tool, IPP was developed to make administration of computers eaiser, and provide an easy way to send print commands over the internet. Why does it matter if it doesn't do backwards upside down with a watermark. I don't. Give em a break! Scott
-- dieman - Scott Dier
Check out the IPP documents. It uses HTTP as a transport mechanism. (That way, they hope to take advantage of HTTP security mechanisms and existing implementations.)
IPP does not specify a page description language. It does allow a printer to specify the forms it can accept, so your software can know that sending it a tiff will work, but fortran formatting codes won't.
It's from an IETF working group, and on the IETF standards track. Isn't that the definition of "open"?
The author of LPRng has already announced he'll be implementing it, from a post in the other IPP article.
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.
I personally rely on Postscript. I can convert nearly anything to Postscript; just about the only format I can't convert from the command line is graphic-embedded HTML, and that I can do with Netscape. So I don't see the need for "one more driver". And as far as "taxes to Adobe", I have yet to pay a single red cent to Adobe for any of the Postscript-aware software I use (Netscape, a2ps, etc.)
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.
Nothing worth doing is worth doing today.
Umm, call me ignorant, but what does this have to do with MS? They're NOT a body of standardization; they just make stuff that a large percentage of the population uses.
Personally, I think it's neat-o, but hey... I've been wrong before.
-- Minds are like parachutes... they work best when open.
Normally, this would be the case. Something like this, however, almost seems to be suited for unix. If the various unix vendors were to adopt it, and implement it well, MS might have to adopt it out of necessity.
-- Minds are like parachutes... they work best when open.
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.
Postscript has one issue which will probably disqualify it from future systems: The Halting Problem.
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.
Jeremy Lee | Orinoco
I find great potential in this, but really, POSTSCRIPT and EPS have done a great job.
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.
I said no... but I missed and it came out yes.
Hmmm, Let's look at it this way. You could, if you wanted to, order a pizza in Chicago, even if you lived in Austin. However, what would be the point. If it were not a prank, then there would be no purpose. A pizza is a material object. You have to be there, or near by to get the pizza.
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?
-Master Switch, one more element in the machine
Unfortunately, as long as Microsoft operating systems run a majority of the world's computers, vendors are unlikely to implement a standard like this until Microsoft systems can use it. This doesn't necessarily mean that Microsoft itself needs to implement this standard; I'm sure some third-party developer could develop an IPP implementation for Windows. The problem there is, if a third-party product makes IPP popular, Microsoft is likely to "integrate" it into their OS, as they did with memory management, disk compression, etc. Maybe HP or one of the other printer makers will provide an implementation for Windows. Hopefully, the spec really is open enough to allow for a Free Software implementation for Linux.
Weblogging Considered Harmful:
Thanks for your posts, helping me cut through my ignorance. I read one of the other specs and it sez
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.
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.
Maybe some of the whiners should read this article again....IPP is like JINI in a sense that you plug your printer into the network with an IP address and it becomes like instantly printing e-mail. Unlike printing e-mail however, you know the capabilities of the printer before you send it so you can be pretty sure what it will look like when printed ( right now you could print this post on a laser printer, and ink jet or a dot matrix for all I know ..it will certainly look different every time). On my network right now ther are 5 different printers and a plotter. I need the drivers for all of them on my machine to use them. IPP means I don't need the Cannon BJ400 driver AND the Lexmark driver (crap I know!) I only need the IPP. That eliminates alot of drivers on my system. It also allows me to send to any printer because I can know instantly its capabilities without having to get a driver for it. IPP is a Protocol (that 2nd P). Sure all this may mean I might need a new kind of software to manage what printers I have access to and/or what they are capable of doing so I can choose whether or not to send my do to that printer. The choice is mine...think of this as a convergence of e-mail/fax and printing all in one. Just as TCP/IP doesn't know how one client handles an e-mail message (HTML,ASCII, POSTSCRIPT), IPP doesn't need to know either.. it just gets the info there. With the added bonus of knowing that if my e-mail doesn't handle HTML (Eudora Lite) I won't send it (If that printer cant't print high quality colour bitmaps, the one at Kinkos will).
Never by hatred has hatred been appeased, only by kindness - the Buddha
I can imagine it now.. Hmm.. I want to print off the unabridged dictionary to some unexpecting guy.. But this would be helpfully anywhere actually... Wouldn't you have to install a driver for IPP??? Eh, who cares? Hmmm... The posibilities!!!
I ate my tag line.
-=Ellis (D)25=-
Umm... How in the heck do you think you could posibly make printers to do operations in a cluster?!?!??
I ate my tag line.
-=Ellis (D)25=-
It appears that for raster format printers (i.e., affordable ones), driver code is still required on the client machine and the quality of the output will depend on the quality of driver code. You will still be stuck with ghostscript quality output on raster language printers where the manufacturer chooses not to port drivers to non-MS and non-Mac operating systems.
so you pay your "taxes" to Adobe rather than Microsoft, that doesn't seem like a super-big step up to me.
IPP is a communications protocol, which can be used to encapsulate a printer language. As I said during the original argument, the IPP spec lists a couple of "recommended" protocols, including Postscript, PCL, HTML, and plain text, however, any printer protocol can be used. Normally, no drivers are sent - the client "IPP driver" knows already how to communicate in most standard printer protocols, so there is no need for a special driver. If the client "driver" doesn't know a common protocol, then there is the possibility of sending a minidriver, although such capability is not explicitly defined in the original specification.
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
Scott Severtson
Senior Architect, Digital Measures
The IPP spec supports metadata about each printer and it's capabilities. If the IPP "client driver" is written correctly, it takes this metadata, and turns it into user choices on screen. The IPP spec does not know/care about any capabilities of your printer directly, i.e. color v. b&w, page size, resolution - it's all sent through metadata.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
Scott Severtson
Senior Architect, Digital Measures
Your Project Design Document is in Word97 format. It will become increasingly unreadable. At least you could print it to a file in Postscript format...while your Word can still read the file.
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.
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.).