Slashdot Mirror
Internet Printer Protocol
Ok, I don't own a printer, but some of you guys might
still use that outdated paper thing. Here is an article about
the
Internet Printer Protocol (IPP)
which is being touted now as the latest greatest in allowing
people to print over the internet. Odd. I did it all
the time when I was writing papers and stuff.
A standard for networked printers rocks. The de-facto lpd `standard' is not secure and is often incorrectly implemented. Check the Apple color laser printers for an example. They run their own lpd internally, and it doesn't talk too well to both NT and various Unices' default lpd. It also denies you the ability to manage its queue. Suck.
Oh, and PostScript level 3 includes the facility to send a URL to the printer and have the printer fetch the document (WebReady Printing, although I can't find anything in the language reference). Betcha most of y'all never noticed that. I just wish there was an independently controlled standard for page descriptions. Good laser printers would be much cheaper without the Adobe PS license. There are a few non-Adobe PS-compatible alternatives, but Adobe controls true PostScript. They do cool stuff for printers (job ticketing for large volume printers, lots of other workflow support, PNG support), but I really like independent standards.
Jason, ejr@cs.berkeley.edu, who thinks the reference to Intel (r) NT (at the bottom) is kinda funny...
Avoid NIH and help an extant (and very good) project.
Jason
Let's start with the title: ``Printers to get their own Web addresses'' Umm, does that mean there will be a URL scheme to go with IPP?
That's exactly what it means. IPP Printers are referred to either as http:// for IPP v1.0, or ipp:// for IPP v1.1. In case you're interested, the TCP port pointed at by the ipp: scheme is 631.
How about ``A system administrator could manage his printers from a hotel room.'' Haven't these guys heard of lpq(8)/telnet(1)? Geesh.
Do you really want to expose those services over the public internet? Maybe if your printer supports ssh this will work, but with IPP you get management capabilities through a nice GUI (or text or however it's implemented) interface over a secure, authenticated connection.
Don't let this bit of CNN reporting dissuade you from IPP, however, because it looks like it will fix some of my pet peeves with Berkeley lpd(8)--namely, no decent authentication, no queue management in the protocol beyond deleting jobs, and no thought given to the actual format of the transported data (you've got to either use Postscript queues or raw text queues or use specific printer drivers on all clients).
IPP will support several authentication schemes, depending upon the client and server platforms.
IPP lets you specify the document-format attribute in the print job; it can be PostScript, pcl, text, printer driver output (e.g "octet-stream" type), or whatever other MIME types the printer supports. The printer will intelligently reject unsupported document formats sent to it, and you can query the printer ahead of time as to what it supports.
It should be noted that most expensive printers with network connections already support LPR and many support a strange feature where you can `print' HTML files (it's called ``Web printing'').
That's still supported in IPP (via the print-URI operation). Unfortunately not every OS supports lpr, and as you've pointed out there are big flaws in lpr that make it difficult to use over public networks.
I haven't looked at it myself, but there IS an IPP SDK available at http://www.shinesoft.com/shineprint/spsdk.html
-- I'm the root of all that's evil, but you can call me cookie..
Actually, after looking more at ShinePrints page, Linux IPP SDK and server already exist.. A commercial product, but still worth a mention..
-- I'm the root of all that's evil, but you can call me cookie..
I once worked at Adobe in the PostScript group. We were experimenting with printers that had an HTTPd server embedded in them. The printer had its own webpage displaying toner reserves, job-queue status, any recent error conditions, etc.
... a webpage for your car (mechanical & fluid status) a webpage for your cellphone (how many calling-minutes so far this month)... a webpage for the coke machine down the hall (been there, done that :)
Also, there were pointers to the manufacturer's webpage so that you could reorder supplies, get questions answered, and so on. To me, this seemed to be the perfect integration of "dumb" devices and the power of the WWW. I'm glad to see that, at least for printers, there is an evolving standard for this stuff.
Think a bit and extend the idea: disk drives with a webpage (giving usage stats, error rates)
Stan
From draft-ietf-ipp-protocol-07.txt:-
---snip---
The IPP Model document defines an IPP implementation with "privacy" as
one that implements Secure Socket Layer Version 3 (SSL3). Note: SSL3
is not an IETF standards track specification. SSL3 meets the
requirements for IPP security with regards to features such as mutual
authentication and privacy (via encryption). The IPP Model document also
outlines IPP-specific security considerations and should be the primary
reference for security implications with regards to the IPP protocol
itself.
The IPP Model document defines an IPP implementation with
"authentication" as one that implements the standard way for
transporting IPP messages within HTTP 1.1. These include the security
considerations outlined in the HTTP 1.1 standard document [rfc2068] and
Digest Access Authentication extension [rfc2069].
The current HTTP infrastructure supports HTTP over TCP port 80. IPP
server implementations MUST offer IPP services using HTTP over the IANA
assigned Well Known Port 631 (the IPP default port). IPP server
implementations may support other ports, in addition to this port.
See further discussion of IPP security concepts in the model document
[ipp-mod].
---snip---
If IPP is going to rely on SSL for security, that lets it in for all the difficulties of getting and using SSL that already exist.
Additionally, the whole specification looks pretty complex. Something of the second-system effect in there, I think. Expect to see IPP exploits on BugTraq.
I run the print system at Cisco we have something like 3000 printers on the network and something like 100 linux print servers.
Anyway, network printing is a good thing. It allows you to work with literally hundreds of printers reliably. The thing is how do you talk to a printer. In most cases you have two choices. LPR and port 9100. LPR is not well suited to talking to printers because it doesn't allow you to pass any information back from the printer. For example you don't know if your print job just failed becasuse of a PS error. You also can't ask the printer about its capabilities. Port 9100 and PS together solve these problems. Port 9100 is just a standard port for a bidirectional TCP/IP connection to the printer. That way when you get PS errors you can read the error messages back from the socket. PS allows you to interrogate the printer for information.
The thing is this sort of means that you have to have a fairly intelligent print server. The printer vendors want to build all that intellegence into the printer and the protocol that communicates with the printer. So that is why they invented IPP.
I like the general concept of this idea, I cannot comment on the way it is being done, but the idea is a great one. See, I am a firm beliver in OpenStandards. I like to use many different OSes, and many different apps. When one does not play well with others, it ruins my day. That is why I love html, plain text, mpeg, wav, jpeg, etc. I can use any of those formats, and use them on any OS I happed to be in front of that day.
Now, we could argue if this standard is being done right, but that will not accomplish anything. Lets insted be happy with the fact that people are working towards another cross-platform technology. And if you do not like the way this one works, draft up your own ideas, I am sure people would be more then happy to look at them.
Sometimes I get the idea that people would rather sit back and complian about the work of others, and not do anything to make it better. That is what is great about the internet, you don't have to be someone important to have a good idea that people latch onto.
Elwood
I don't know about this being all that great of an idea. I imagine that the same type of people who go around using Back Orifice for kicks would also find it amusing to hunt down people with open printers who don't realize they're open and either waste their paper by printing a hundred sheets with one word in the middle or waste their ink by printing a few completely black pages. Since it seems that most people I know who have computers don't know about 80% of what they can really do, it seems that a lot of people wouldn't realize their printers were open to pretty much everybody.
-mike kania
IPP has a lot more potential than simple lpd. For example, you would be able to query paper trays and direct your output there, rather than relying on the sysadmin to set up specific queues for each possible option the user might want.
Also, having a single standard means that you won't need to install netatalk, samba _and_ lpr to be able to talk to any printer you want. Ideally, everyone would support IPP so you'd only need one thing.
There's surely more and I've not read the standard, but iirc the author of LPRng was involved in standardization, so it should fix annoyances people have with lpr.
No, you can't just use "the appropriate model file". There are lots of useful printer capabilities that lpr just has no idea of. And most servers (well, none I know of) don't do anything with the PPD file (what I assume you're talking about).
Tell me, how do I tell the LPD server I'm sending it PDF which it should print in reverse order, 4 pages per sheet, both sides, first page from the letterhead tray and remainder from tray 3?
His comment "Hasn't this already been done?"
My reply "That is what everyone on Slashdot is saying."
Then he mentioned that he is amazed that a certain part of the lpr/lpd/etc code has not been updated... apprantly a certain part would be more clean if it used select(). Then again, he was a "dinky undergrad" when he wrote that entire package.
- Sam Trenholme
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
(Is anyone else amused by the statement that, "the bottleneck at this point is Microsoft"? ;-)
Your Servant, B. Baggins
That makes the task of sending threatening letters, religious panphlets, and nazi hate propaganda to my neighbors that much easier. With the task automated like this I'll have much more time to devote towards gathering memebers for my death cult. Laugh...
Seriously though... I thought there was already an accepted standard for printing via tcp/ip. Just about every device and operating system has direct support for LPR printing. Even the Neoware network computers can emulate an LPR printer for the LPT port they have on the back of them. Isn't that the whole point of RFC1179?
"One of these days... milkshake... BOOM!!!!" - emb
Am I the only one that leaves my printer off unless I'm printing something? This is useful ..
I haven't seen a piece of journalism this bad in a long time. Let's start with the title: ``Printers to get their own Web addresses'' Umm, does that mean there will be a URL scheme to go with IPP?
How about ``A system administrator could manage his printers from a hotel room.'' Haven't these guys heard of lpq(8)/telnet(1)? Geesh.
Don't let this bit of CNN reporting dissuade you from IPP, however, because it looks like it will fix some of my pet peeves with Berkeley lpd(8)--namely, no decent authentication, no queue management in the protocol beyond deleting jobs, and no thought given to the actual format of the transported data (you've got to either use Postscript queues or raw text queues or use specific printer drivers on all clients).
It should be noted that most expensive printers with network connections already support LPR and many support a strange feature where you can `print' HTML files (it's called ``Web printing'').
--jon. Postel is dead. May we all mourn his, and our, loss.
We provide dial-up access to an organization just next-door to ours, with a bunch of HP equipment. They have their own network (in fact, their own ISP), but they were unwilling to support their own employees, so... it's a long story. Anyway, about a year ago, we got a furious phone call from the organization's network admin saying that someone on our dialup was trying to crack their network. When we asked for some kind of log of the activity, he produced a firewall log tracking a bunch of SNMP access attempts to an IP address on their network.
So, I tracked the IP. Turns out it was an HP printer. The Jet-Direct software was too stupid to know it was connected via dial-up, and was tripping the firewall trying to get in. I took particular relish in informing them that the cracker was a fifty year old employee of theirs who was just trying to get her e-mail.
You say: "Many people would argue that because junk mail (the normal kind) is accepted by most, so should junk fax and email be."
:-) Again, with host-based control (using IPv6 hopefully) it'll have some degree of authentication, and with secure certificates it'll add that extra degree of security.
But you're forgetting one of the main differences between junk snail mail(UCM), junk email(UCE) and faxes(UCF). The cost for sending UCM resides solely on the sender, while the cost of sending UCE resides on the recipient. In the case of a UCF, the cost on the recipient is much more direct ("Hey, that's my ink and paper they're using!"). You can't compare UCM and UCE/UCF. They're two different bags of shit.
You don't need one firewall per printer inside your network, the purpose of a firewall is to block/allow ALL types of traffic to a network, with exceptions. And exceptions to those exceptions, and so on.
I personally find that there is a need for an intermediary between the sender and the printer anyway. If I have a printer on the net, I'll make sure that I review all print requests before they're printed. This will be fine for a small scale (personal), but for corporations and such I can see a scheme where there are trusted invididuals who are allowed to print directly, and everybody else either is disallowed or goes through a screener.
M.
M.
IPP is host to a slew of problems, the worst of which is the lack of access control. Fax machines already suffer badly from junk faxes, and legislation had to be put into effect to try and deter that behavior. (Please correct me if I'm wrong... The rapidly changing legislation on privacy vs. free speech gets the better of me sometimes.)
:)
From the cursory glance I gave HP's site of IPP a couple weeks ago, it didn't look like there was much of a standard for access control on the system. I mean, receiving a 100 page email is one thing -- you can delete it, and it doesn't use much in the way of material resources. However if someone uses IPP to send you a 100 page piece of junk, even if it's accidental (typed in the wrong ip?), it can cost quite a bit... Especially if it's a nice color transparency printer!
I'm all for standardizing printing protocols, but I really think IPP needs a little more work before it becomes mainstream. For now, I'm quite happy spooling stuff to port 515 on my printers
Taral
WARN_(accel)("msg null; should hang here to be win compatible\n");
-- WINE source code
"Eventually, if you had a printer that is IPP
compliant, that printer will have a Web address and anyone around the world who can get on the Internet can print to that URL," said Robert Palmer,
And he says this like it's a good thing.
Yet another protocol to filter at the firewall.
-- Alastair
Reading the CNN piece made me very hostile to this idea. Reading some of the documents on www.pwg.org made me less so. These guys are doing some genuinely clueful stuff in this protocol, and it's worth reading.
I do find some of their choices puzzling. For example, the FAQ dismisses the BSD LPR protocol as ``proprietary'' and therefore unusable. (Hello? By what bizarro definition of ``proprietary'' does 4.4BSD qualify?) They reject RFC 1179 because it's not an Internet standard, and then adopt SSL3 for security, even though it does not seem to be any more official in the IETF sense. A lot of the work seems to be more ad-hoc than they're willing to let on.
Other posters have noted that complex protocols are difficult to do right, and especially difficult to do securely. That's going to be a major problem right there. But overall, an IETF-blessed effort toward an open standard for network printing that includes participation from hardware vendors is probably going to be a good thing in the long run.
What is all the hype about? Samba can do this already. Perl scripts can do it if you want as well.
I think anyone who would be asked to implement this has probably already done this, or knows how to do it.
The 1.0 IPP specifications are available in PDF or in TXT formats. I'll post more once I've read them myself...
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
Scott Severtson
Senior Architect, Digital Measures
The links above are just for the IPP URL naming convention. Check out http://www.pwg.org/ipp/ for a full list of documents that are available.
Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
Scott Severtson
Senior Architect, Digital Measures
- IPP is secureThe protocol specifies that Transport Layer Security (TLS) Version 1.0 will be used to provided mutual authentication and encryption. Elsewhere in the documents, (optional) compression can be applied as well.
- IPP is complexWith support for multiple document protocols, multiple documents per "job", and a fairly detailed client querying process, it also won't be cheap.
- Document protocols are specified as MIME types, and they define a couple recommended ones: PCL, Postscript, HTML, and plain text.
- Documents can be sent as a URI (i.e. an HTTP URL), which, if the IPP server supports it, can be used to go out and retrieve the document when the printer is available to print it, instead of holding it in spool.
- Multiple configurations are specified, with just waiting to be created. For example, IPP allows a printer with an embedded spooler and internet interface, a printer hooked to a spooling server with an internet interface, and multiple printers hooked to a spooling, smart server with an internet interface, which routes the document to the printer best suited/least busy for the job.
- Supports extended properties for client querying. The single biggest advantage of the system is that the client does not have to have any idea of what type of print it is printing to, i.e. no more specific printer drivers. Instead, the client connects to the printer/spooler, asks it what it can do, and sends the document in a compatable format. This should (hopefully) save a lot of hassle in the work place for configuring printers on thousands of desktops.
Just my two cents.Scott Severtson
Software Developer
Auragen Communications
scotty@auragen.com
Scott Severtson
Senior Architect, Digital Measures
I don't get it. I just parse my logfiles looking for NETBIOS broadcasts on the cablemodem segment, run smbclient to scan for open shares then print interesting printers to people on my segment with open printers. I guess this is finally a solid standard that all systems will support. Yay.
--