IPP

Out of curiosity, I decided to write a little IPP client library in Python. An in-progress version can be found here.

In less than 500 lines of Python, I have an IPP message encoder/decoder, and some higher level classes to perform a few operations on printers and jobs. I've been able to successfully talk to the following IPP servers:

  • CUPS (I've also got a little code to perform some of the CUPS proprietary operations).
  • an HP LaserJet 5100 and a 2300 -- both with JetDirect 615n (J6057A) cards.
  • a Lexmark Optra C710.

The following didn't want to talk to me:

  • an HP LaserJet 4V with a JetDirect 400n (J4100A) card (it seems to always give me a client-error-bad-request response).
  • a Canon iR C3200. (incidentally, this printer/copier apparently runs an embedded version of SunOS 4.1.4)

I'm probably doing something wrong for these last two, although it is a bit difficult to work out what.

When talking to CUPS, I can use the proprietary CUPS-Get-Printers operation to list all the printers it knows about which would make it pretty easy to provide functionality of something like gnome-print-manager:

>>> import ipplib
>>> cups = ipplib.CUPSServer('ipp://localhost/')
>>> for info in cups.get_printer_info():
... print info['printer-name'], '-', info['printer-uri-supported']
...
harryplotter - ipp://hostname/printers/harryplotter
 ...
>>>

Similarly, it is easy to list the jobs (pending or completed) for a printer. I still haven't tried out any of the operations that can change a printer or job's status, but in theory that should all work :).

Thoughts on the protocol

While IPP uses HTTP as a transport, there is a fair bit of overlap between what the two protocols do, such as:

  • request methods/operations and response status codes.
  • identification of the resource the operation is being performed on.
  • IPP attributes seem quite similar to HTTP headers.
  • message body mime type declarations
  • compression of message bodies

Other things serve no purpose when tunneled through HTTP, such as message sequence numbers. Apparently the reason for this is so that IPP could in the future be sent directly using a custom protocol (in that case, the sequence numbers would allow for pipelining of requests, and out of order responses). However, I would be surprised if such a protocol ever gets developed. IPP will probably continue to use HTTP as its transport.

This does lead to complications though:

  • The URI you do an HTTP POST to may differ from the URI specified inside the IPP message. The spec says that the HTTP level URI should be ignored. If you have ever looked at the CUPS log files, you might have noticed that it almost always posts to "/" rather than the resource it is acting on. To make matters more complex, some of the proprietary CUPS operations require that you post to a different HTTP URI to the one in the IPP message.
  • A request can fail at one of two levels. An IPP client will need to detect and handle both HTTP level and IPP level error responses. In fact, most IPP error messages will come back as "HTTP/1.1 200 OK".

Apart from the few warts, IPP seems like a pretty nice protocol. It is fairly easy to parse (assuming you have an http client library to use), and is very extensible. A lot nicer than LPR :).