IETF Working On New Printing Standards

A reader writes: "The IETF has announced that they are developing new printing standards for network printing." Printing -- exciting, eh? But one of those necessary evils in life.

Comments

Network Printing Standards

[Greyfox]

Most of the stuff that at least the Printer Working Group was working on last time I talked to them involved transport rather than rendering. They recognized that there was a problem with rendering languages too, but no one was doing anything about it.

What would be really neat would be if they could implement a rendering model based either on XML + CSS, or DVI, both of which are open standards. An XML based rendering standard would have more hope of catching on, though a DVI based one would almost certainly yield (substantially) better output.

1996

[Robert S Gormley]

The standard has been around since 1996, fully documented and open. What this is is the IETF giving their stamp of approval (after concerns about security etc). Microsoft implemented the standard minus one feature, which allowed you to pass a URL to a printer, and have it download and print the document itself.

Re:What about lpr

[elandal]

Nobody's changing it. And there is more than one way to handle print spooling in Unix already.

lpr isn't so great. I haven't reviewed IPP as I haven't needed it, but I assume it's designed to work in larger networks, too. Networks that suffer from failures, high latencies, low bandwidth, so on.

Also, it's a single protocol approved by several OS companies. Meaning we don't need to set up samba on Unix or separate lpr on Windows - Unix will come with IPP as the standard print queue as will Windows. And Mac. And anything else You want. Perhaps even Bluetooth Palm with IPP - want the notes You wrote in the meeting onto paper? No need to first sync to computer and then print through samba which redirects to remote printer using lpr - the remote printer being two meters from where You stood when You wanted the notes on paper.

printing is hard, lpr/smb not adequate

[jetson123]

Printing is actually a surprisingly difficult problem: it involves something that amounts to executable content, authentication, accounting, downloading of drivers, envelopes/covers, transferring large amounts of data, collating, device configuration, content negotiation, security, DoS attacks, and other issues.

The UNIX lpr protocol avoided dealing with most of those issues and assumes the whole world is PostScript or ASCII and having minimal security. And Windows now has a proprietary solution for installing drivers and other issues.

I hope IPP won't go overboard. Many of the issues I mentioned, I think, are best left unaddressed, because if the printing protocol makes it too easy to create a proliferation of configurations and printer drivers, people will do just that. But something a bit more featureful based on HTTP I think would definitely be a step forward.

Re:More Junk Fax^H^H^HPrintouts?

[Robert S Gormley]

Authorisation. What's needed is more importantly the default set up of said servers/printers to require authenticated, authorised users, and not be world-writeable. Kinda like passwd'ing your root account. :)

Here's a doubleclick-free, Junkbuster-safe link

[jsm]

Try this one instead:

http://www.nwfusion.com/news/2000 /0710ipp.html?nf

I actually use IPP

[jefftp]

I put together CUPS on a FreeBSD server. It's a dream.

With a quick trip to Windows Update, download the Internet Printing update, and add printers with the location of http://corporation.com:631/printers/hp4000 (A work around, since MS Internet Printing doesn't allow you to use ipp://...) and bam, that machine can print to that printer from anywhere. Before anyone can print to the printer they need to A) be from an approved IP, and B) enter a user name and password. At the moment I'm not using SSL, but that's an option to add security.

Currently I have no problem printing documents from anywhere in the state back to the home office.

The CUPS suite can accept LPD print requests, with Samba can handle SMB print requests (although you'd only want to do that for NT 4 and Win3.1 clients). It has a web-based interface for both configuring/administering the printers as well as viewing the print queue. And print classes allow you to effortlessly set up a single queue for several printers.

Of all the things Unix does right, printing was a administrative heap of dung until CUPS. If you're not using it, you're probably working too hard.

If your office is moving to a dispersed office (everyone telecommuting) then CUPS and IPP is your best option for allowing workers, from home, to print back in the office.

On a final note, I'm not really sure why anyone finds pushing IPP through a firewall difficult. It's all on TCP port 631. It's just HTTP. Maybe just that no current turn-key firewall software has a button/checkbox to "enable IPP"?

Re:What about lpr

[Shimbo]

Unix print spooling has worked fine until now - why change it?

There are several things it doesn't address very well. The main one is that it is a hack on direct network connected printers: you can print to them but then the printer has no way of communicating status back.

Compare with say, how printing on Appletalk works, where you open a bidirectional channel to the printer, and it tells you on the channel if it's out of paper or whatever.

Furthermore, lpd includes no way of managing networked printers remotely. How do you set up access lists, or retrieve accounting information?

lpr is a 'just good enough' protocol. Don't believe that it can't be improved on.

\ vs /

[zaugg]

IPP is built on top of HTTP, which in turn runs over TCP/IP. IPP traffic is sent as a Multi-purpose Internet Mail Extensions-type using HTTP's feature for posting information. End users submit a print request using a command in the browser address line that starts with "ipp:\\" rather than "http:\\."

Oops, hope the backslashes don't make there way into the protocol :)

zaugg

.sig free for six months