Print-friendly Version

Using IPP as the Preferred Network Printing Protocol

Juanita Heieck, November 2006

Abstract

This article describes the Internet Printing Protocol (IPP) and how to use it as the preferred network printing protocol in the Solaris Operating System (Solaris OS). Support for IPP is one of several changes recently made to the Solaris print system to promote easy interoperability with both CUPS and Microsoft Windows clients. Also covered are the FSG OpenPrinting Open Standard Print API (PAPI) implementation of the IPP, providing both server-side and client-side support, the re-architecture of existing Solaris client print commands, and tips for using this technology.

Contents

• Introduction
• Solaris Print System Architecture
• IPP at a Glance
• IPP Support in the Solaris OS - A Closer Look
• Disabling and Enabling the IPP Network Service
• Configuring IPP Server and Client Data
• Printing With IPP
• What's on the Horizon for Solaris Printing?

Introduction

If you thought all there was to printing in the Solaris OS was the lp command, think again. Solaris printing is moving full steam ahead, and has set sail for "Open" waters. The printing story in the Solaris OS is nearing completion of an important and significant phase. Rounding out some of the changes that were started in the Solaris 10 OS are improvements to server-side support for IPP, the implementation of client-side support for IPP, and the layering of applications on top of the Open Standard Print API. The PAPI implementation in the Solaris OS makes it possible to layer print commands on top of a print service-neutral, protocol-neutral interface.

In addition, the Solaris print client command implementation has been rewritten on top of the PAPI. With the PAPI support that is currently available, these command implementations can be used with RFC-1179 and IPP-based servers. Support of the attributes, printer/server/job, from job submission and query to the printer, thereby enables the print client, which includes both applications and the print commands themselves, to query the print system about characteristics of a printer and to request this information. All of these changes are geared towards making IPP the preferred network printing protocol in Solaris. Several of these recent changes were introduced in the Solaris Express 8/06 release.

More information about new printing features and printing in the Solaris OS can be found in the System Administration Guide: Advanced Administration in the System Administration Collection at http://docs.sun.com/app/docs.

Solaris Print System Architecture

The following block diagram is a high-level representation of the Solaris print system architecture.

Figure 1
(Click to Enlarge)

IPP at a Glance

IPP is a full-featured network printing protocol that is rapidly becoming the industry standard. IPP provides a common set of network printing services. The protocol was initiated to provide universal solutions for printing documents from the Internet. IPP is employed by several system and printer vendors because the protocol has all the tools that are required to make a rich set of standard requests and receive standard responses from print client systems. IPP provides versioning, extensibility, and security, as well as enhanced functionality that includes vast improvements in job and printer status retrieval.

IPP enables a print client to query a printer for its supported capabilities, features, and parameters to allow the selection of an appropriate printer for each print job. With IPP, you can find out about a printer's capabilities, submit print jobs, determine the status of a printer or a print job, or cancel a previously submitted print job. You can hold, release, restart, or modify print jobs, as well as move print jobs between queues, accept, reject, enable, and disable print queues. With IPP, you can also modify and delete printers, and much more.

On the front end, IPP is layered on top of HTTP/1.1. The server receives IPP operations through an HTTP POST request. The server then performs the requested operation and sends a response back to the client via HTTP. These operations include, but are not limited to, submitting and canceling a print job, and querying attributes of a printer, a print job, or all the print jobs that have been queued to a printer. On the back end, the IPP listener performs operations by communicating with a print spooler. In the Solaris OS, this spooler is currently the lpsched daemon.

Why Use IPP?

IPP is a protocol that can be used locally for sending print jobs to a printer across the room, or over the Internet for sending print jobs to printers across the country, or around the globe. Besides this fact, IPP is unique, in that it also supports access control, authentication, and encryption, making it a much more capable and secure printing solution.

The motivation to implement IPP in the Solaris OS is threefold:

1. Although adequate, the functionality that is available in the LPD wire protocol is lacking in features, extensibility, security, and interoperability at anything more than a basic level. IPP is more efficient and rich in its capabilities and features, making it the preferred protocol over the LPD wire protocol.
2. The majority of companies that provide printers and print services are beginning to utilize IPP as their primary printing protocol. This gives Sun the ability to compete and interact with other companies by providing the same printing solutions to customers.
3. Because IPP is a protocol that is fast becoming the universal standard in the industry, customers can print to and from Solaris servers to a variety of other platforms and operating systems.

IPP Compared to the BSD Protocol (RFC-1179)

The BSD protocol has served as the de facto standard network printing protocol for decades. It was originally designed to perform a very limited set of operations. The BSD protocol lacks a common representation for status information, and anything more than very basic print job options. On the other hand, the design of IPP includes many of the features that are lacking in the BSD protocol. With IPP, a rich set of operations can be performed. These operations make use of a core set of common attributes by using a common representation and encoding. Also, the protocol allows for encryption and authentication to be used between client and server. Finally, IPP provides an avenue for extending operations and attributes, while maintaining backward compatibility and interoperability.

Breakdown of the Components

These are the basic components of the IPP support available in the Solaris OS. Each component is described in detail later.

IPP Support in the Solaris OS - A Closer Look

IPP support in Solaris is split into client-side and server-side support. Both the client-side support and the server-side support share some common elements, as well as elements that are unique to either the client or server operation. As a result, the IPP client and server components share a code base that implements these common elements.

IPP Client-Side Support

The IPP client-side support in the Solaris OS is implemented underneath the PAPI. This support enables any applications that are using the PAPI to also use IPP, as well as other print services and protocols.

These applications include:

• GNOME Desktop Environment - Applications using libgnomeprint
• BSD commands - BSD UNIX LPD print service commands
• lpr
• lpq
• lprm
• lpc
• LP commands - System V UNIX LP print service commands
• lp
• lpstat
• cancel
• lpmove
• accept
• reject
• enable
• disable

The IPP client-side support for applications is provided through a loadable module, psm-ipp.so. This module is loaded at runtime, based on the printer-uri for the printer or job that is being manipulated.

Because IPP is layered on top of an HTTP transport, both client-side and server-side support need the ability to read and write HTTP protocol. On the server-side, this support is provided by the Apache web server. On the client side, this support is provided by an HTTP library, libhttp-core.so.

IPP Server-Side Support

The IPP Listening Service provides an IPP network protocol service that enables print client systems a means of interacting with a print service on the system that is running the IPP listener. This listener implements server-side IPP protocol support, which includes a rich set of standard operations and attributes. The listener is implemented in Solaris as an Apache module and a series of shared libraries that contain IPP operation and wire support. The IPP software stack is installed when the Solaris OS is installed. The listening service is an SMF service that depends on the print service to run. As a result, IPP is automatically enabled on a print server when the first print queue has been added. IPP is also disabled when the last print queue has been removed.

The listening service implementation is embedded under the Apache web server. The web server receives IPP operations through HTTP POST requests. When an HTTP POST request is received it is passed on to the Apache IPP module (mod_ipp.so). Based on configuration, the Apache web service may provide an authentication service and it may also use encryption between client and server. The listening service runs as its own dedicated instance of Apache.

Server-side support for IPP starts with the IPP module, mod_ipp. The listening service uses the Apache web server because the Solaris OS already ships with Apache software. The Apache module uses the Dynamic Shared Object (DSO) interface to plug in under the web server. Using the DSO interface, the module includes configuration support for the listening service and an entry point for the web server to hand the listener the HTTP connection. This modular approach enables the IPP support to reuse Apache-delivered encryption and authentication mechanisms.

Here's the basic process:

1. An IPP request is sent from the client to the server.
2. The Apache web server accepts the connection.
3. The Apache web server then hands the connection to mod_ipp.
4. mod_ipp passes the connection and configuration data to libipp-listener.
5. libipp-listener reads the request by using lipipp-core.
6. libipp-listener dispatches the request to the operation handler located in libipp-listener.
7. The operation handler converts the request to a PAPI call and then makes the call.
8. The PAPI call is translated to a print service-specific request by using psm-lpsched.
9. The print service responds to the request.
10. The psm-lpsched command converts the response to PAPI results.
11. The libpapi operation returns to the libipp-listener operation handler.
12. The libipp-listener operation handler passes the results to the dispatcher.
13. The libipp-listener dispatcher writes the results to the client using the libipp-core library.
14. The dispatcher returns the mod_ipp entry point return.

IPP Libraries

The IPP Listening Service library, libipp-listener, is where the bulk of the protocol request processing occurs. The library reads and validates requests using the core IPP library, libipp-core.so. After the request has been validated, the request is translated to a series of client API calls. The results of these calls are then translated into an appropriate IPP response using the core IPP library. The response is returned to the client system by the web server.

Note: The interface to the listening service library is a project private interface that is specific to the IPP server-side implementation.

The IPP Core Library is shared between client and server operations. The IPP core library, libipp-core.so, contains routines that enable it to read and write protocol requests and responses. The library converts IPP request and response data between the standard binary representation and a set of common data structures. Ultimately, this common data representation is used in translating requests to and from a print service-neutral representation and passed through a generic printing interface, libpapi.so. Since both client-side and server-side IPP support must perform this function, this component is shared by both clients and servers.

The PAPI library provides applications a print service-independent means of interacting with a print service or a protocol. In this instance, the library provides the Apache IPP listening service a means of interacting with the local LP service. It determines which print service to interact with, based on the client-side queue configuration data that is stored in the printers.conf configuration database.

lpsched Support

The psm-lpsched command provides a translation between the print service-independent representation of the PAPI and the LP print spooler, lpsched. The command takes the PAPI attributes passed into various PAPI functions and converts these attributes into an internal lpsched representation of the data. The psm-lpsched command then contacts the lpsched command to perform the requested operation. Once performed, psm-lpsched converts the results back into a print service-neutral PAPI representation and returns these results to the caller.

The LP print spooler (lpsched) provides a spooling service, translations of job data to a printer-ready format, and transmission of job data to the physical printer.

Enabling and Disabling the IPP Network Service

The Solaris OS ships with a default Apache httpd configuration file that may be used to start an httpd instance dedicated to listening for IPP requests. Also included with the IPP listener is an SMF manifest that describes the application/print/ipp-listener service. Upon installation, this manifest is imported into the SMF repository and will start automatically when the LP service (application/print/server) is started. Using the SMF svcadm command, you can enable, disable, and restart the IPP network service.

After making a configuration change, you will want to restart the service to load the new configuration.

Note: You must be superuser or the equivalent to run these commands.

Enabling the IPP Network Service

To enable the IPP network service, type:

# svcadm enable application/print/ipp-listener

To enable the rfc1179 network service, type:

# svcadm enable application/print/rfc1179

Disabling the IPP Network Service

If you do not want to share a printer on the network, you can disable the IPP network service.

To disable the IPP network service, type:

# svcadm disable application/print/ipp-listener

To disable the rfc1179 network service, type:

# svcadm disable application/print/rfc1179

Restarting the IPP Network Service

To restart the IPP network service, type:

# svcadm restart application/print/ipp-listener

To restart the rfc1179 network service, type:

# svcadm restart application/print/rfc1179

Configuring IPP Server and Client Data

The IPP Listening Service provides print client systems a means of interacting with a print service using the IPP protocol. This protocol includes a rich set of standard operations and attributes. It is implemented on Solaris as an Apache module and a series of shared libraries containing IPP operation and wire support.

Since the listening service consists of a dedicated instance of an Apache web server managed through SMF, you can enable and disable the service through the use of the svcadm command. The specific SMF service that is used is svc:/application/print/ipp-listener. The Apache configuration for this web server instance runs as the lp print service user, which provides enough privileges to support all of the existing IPP operations, but limits access to print service specific resources. It's also important to note that the listening service runs as its own web server instance, specifically configured to support IPP. This is intended to minimize potential security risks.

Note that if you make any configuration changes, you need to restart the service to load the new configuration.

Apache Configuration File

The IPP Listening Service configuration file, /etc/apache/httpd-standalone-ipp.conf, is like any normal Apache 1.3 configuration file. The configuration file takes any Apache 1.3 configuration directives that you want to use. Starting with Solaris 9 10/04 and in the Solaris 10 OS, the default configuration includes the following features:

• Listening on port 631
• Loading of a minimal set of Apache modules
• Enabling all supported IPP operations at the /printers/ path (ipp://server/printers/) without requiring authentication

The default operations that are enabled for /printers/ are limited to a set of operations that poses less of a security risk. However, all operations are enabled at the /admin/ path (ipp://server/admin/), with basic authentication required.

The mod_ipp Apache configuration options to choose from are described in the following table.

The following table shows the conformance checking types for the Apache Web Server Configuration.

The syntax to use is:

ipp-conformance  value

The following table shows the IPP operation keywords for the Apache Web Server configuration.

Here is an annotated example of an Apache configuration file:

if mod_ipp is loaded User lp run as "lp"
URI: ipp://{host]/printers/{queue}
SetHandler application/ipp use mod_ipp for this location
ipp-conformance strict enable strict protocol checking (default)
ipp-operation all enable enable all supported operations

Configuring the /etc/printers.conf File

Under PAPI support, the bsdaddr value (server,q) is converted to its equivalent printer-uri-supported value (lpd://server/printers/q), when the printer-uri-supported value is missing from the printers database. However, in some situations, such as when there is a mix of client systems and the queue is on an IPP-capable server, you might need to add this piece of configuration data manually.

To add configuration data, use a text editor to add the following information to the client system's /etc/printers.conf file:

/etc/printers.conf:queue: \
    :bsdaddr=server,queue,Solaris: \
    :printer-uri-supported=ipp\://server/printers/queue:

Restart the IPP listener for the changes to take effect.

Printing With IPP

If you have a server running at least the Solaris 9 10/04 OS, or a CUPS server, lpstat will provide you with more information about remote print queues (and jobs), as well as their capabilities, when you use IPP to talk to those servers.

For example:

# lpset -a printer-uri-supported=lpd://server/printers/test test
# lpstat -p test -l
printer test disabled since Fri Nov 03 11:43:30 2006. available.
        Warning: test is down: new printer

        Form mounted:
        Content types:
        Description:
        Connection:
        Interface:
        After fault: continue
        Users allowed:
                (all)
        Forms allowed:
                (none)
        Media supported:
                (none)
        Banner required
        Character sets:
                (none)
        Default pitch:
        Default page size:
        Default port setting:
        Options:



# lpset -a printer-uri-supported=ipp://server/printers/test test
# lpstat -p test -l
printer test disabled since Fri Nov 03 11:48:53 2006. available.
        new printer
        Form mounted:
        Content types: application/postscript
        Description:
        Connection:
        Interface: /usr/lib/lp/model/uri
        PPD: /usr/lib/lp/model/ppd/system/foomatic/HP/HP-Color_LaserJet_4600-Postscript.ppd.gz
        On fault: write root
        After fault: continue
        Users allowed:
                (all)
        Forms allowed:
                (none)
        Media supported:
                Letter
                A4
                11x17
                A3
                A5
                B5
                Env10
                EnvC5
                EnvDL
                EnvISOB5
                EnvMonarch
                Executive
                Legal
        Banner required
        Character sets:
                (none)
        Default pitch:
        Default page size:
        Default port setting:
        Options:

You can accept, reject, enable, and disable remote print queues with proper authorization, when IPP is in use. See the section on Setting Authorizations That Enable You to Accept Print Queues When IPP Is in Use.

You can remotely move jobs between print queues on a print server when IPP is in use.

For example:

$ lpmove {request-id} {new-destination}

$ lpmove {old-destination} {new-destination}

You can modify your print jobs remotely when IPP is in use.

Here are some other examples:

To submit your job held:

$ lp -d {destination} -H hold /etc/motd

To change the number of copies:

$ lp -i {request-id} -n 5

To turn on duplexing and release it for printing:

$ lp -i {request-id} -o Duplex=DuplexNoTumble -H resume

How Do I Share Printers Using IPP?

These operations include:

• print-job
• validate-job
• create-job
• get-jobs
• get-printer-attributes
• send-document
• cancel-job
• get-job-attributes
• cups-get-default
• cups-get-printers
• cups-get-classes
• cups-move-job

Can I Select IPP From Solaris Print Manager?

There is currently no means of selecting IPP when adding access to remote print queues when using Solaris Print Manager. This feature should be available in Solaris Express soon, and at some point, will be back ported to Solaris 10.  When this functionality becomes available in Solaris Print Manager, IPP will be automatically selected, if the print service is determined to support IPP. Bug 6488443 describes the problem and the solution.

Authentication Mechanisms

IPP is layered on top of HTTP. As a result, it uses the authentication mechanisms built into HTTP (and Apache). The default configuration that is shipped in Solaris doesn't make use of these authentication mechanisms. Starting with the Solaris 9 10/04 release, and in the Solaris 10 and Solaris Express releases, client authentication is required to access some uri-path and operation combinations.

For example, the more common form of printer-uri that is used by client systems is:

ipp://server/printers/queue

For printing on Microsoft Windows systems, you need to specify the URI by using:

http://server:631/printers/queue

Setting Authorizations That Enable You to Accept Print Queues When IPP Is in Use

To set authorizations for accepting print queues when IPP is in use, edit the /etc/apache/httpd-standalone-ipp.conf file.

To set up authentication, add the following entries:

• AuthType
• AuthName
• AuthUserFile

For an example, see the /etc/apache/httpd-standalone-ipp.conf file.

If you are running at the least the Solaris Express 10/06 release, the /printers path turns on the following operations:

• print-job
• validate-job
• create-job
• get-jobs
• get-printer-attributes
• send-document
• cancel-job
• get-job-attributes
• cups-get-default
• cups-get-printers
• cups-get-classes
• cups-move-job

Turning On the Authentication Mechanism

The following command will fail under the default configuration, because the operation is not enabled for that uri path:

$ accept ipp://server/printers/queue

To authenticate, type:

$ accept ipp://server/admin/queue

You are prompted for authentication.

Enter the proper authentication information to enable the processing of the operation for the uri path.

For example:

system% accept ipp://printing/printers/wspe
accept: ipp://printing/printers/wspe: operation-not-supported
system% accept ipp://printing/admin/wspe
passphrase for user-name to access ipp://printing/admin/wspe:
accept: ipp://printing/admin/wspe: not-authorized
system%

Adding a User to the AuthUser File

To add a user to AuthUser file, type:

 # /usr/sfw/bin/htpasswd /etc/ipp-users user-name

To verify the user was added, check the /etc/ipp-users file.

 # grep user-name /etc/ipp-users

What's on the Horizon for Solaris Printing?

Some additional work is currently underway to resolve more pressing issues with highly mobile systems that have local printers.

The following are among the list of projects that are focused on this goal.

PPD Management: The current implementation's use of PPD files in the printmgr relies on a cache to list and display the supported printer manufacturers, models and drivers. The cache was created for performance, as reading through 2800+ zipped PPD files takes longer than any user's patience with a GUI. The cache is currently static and built against the PPD files, as shipped. Several people have expressed a desire to have tools to locate and install additional PPD files into the cache. This project aims to do just that.

Presto (Automatic Printing Configuration): A project aimed at improving Solaris approachability, specifically the print service, by automatically (or as automatically as possible) discovering and configuring access to directly-attached, network-attached, and remotely-served printers.

You can find more information about OpenPrinting at http:/sf.net/projects/openprinting.

To learn more about the OpenSolaris printing community and ongoing projects, go to http://www.opensolaris.org/os/community/printing/.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.