Team BBL
Previous Page Next Page

21.2. The Internet Printing Protocol

IPP specifies the communication rules for building network-based printing systems. By embedding an IPP server inside a printer with an Ethernet card, the printer can service requests from many computer systems. These computer systems need not be located on the same physical network, however. IPP is built on top of standard Internet protocols, so any computer that can create a TCP/IP connection to the printer can submit a print job.

Specifically, IPP is built on top of HTTP, the Hypertext Transfer Protocol (Section 21.3). HTTP, in turn, is built on top of TCP/IP. The structure of an IPP message is shown in Figure 21.1.

Figure 21.1. Structure of an IPP message


IPP is a requestresponse protocol. A client sends a request message to a server, and the server answers with a response message. The IPP header contains a field that indicates the requested operation. Operations are defined to submit print jobs, cancel print jobs, get job attributes, get printer attributes, pause and restart the printer, place a job on hold, and release a held job.

Figure 21.2 shows the structure of an IPP message header. The first 2 bytes are the IPP version number. For protocol version 1.1, each byte has a value of 1. For a protocol request, the next 2 bytes contain a value identifying the requested operation. For a protocol response, these 2 bytes contain a status code instead.

Figure 21.2. Structure of an IPP header


The next 4 bytes contain an integer identifying the request. Optional attributes follow this, terminated by an end-of-attributes tag. Any data that might be associated with the request follows immediately after the end-of-attributes tag.

In the header, integers are stored as signed, two's-complement, binary values in big-endian byte order (i.e., network byte order). Attributes are stored in groups. Each group starts with a single byte identifying the group. Within each group, an attribute is generally represented as a 1-byte tag, followed by a 2-byte name length, followed by the name of the attribute, followed by a 2-byte value length, and finally the value itself. The value can be encoded as a string, a binary integer, or a more complex structure, such as a date/timestamp.

Figure 21.3 shows how the attributes-charset attribute would be encoded with a value of utf-8.

Figure 21.3. Sample IPP attribute encoding


Depending on the operation requested, some attributes are required to be provided in the request message, whereas others are optional. For example, Figure 21.4 shows the attributes defined for a print-job request.

Figure 21.4. Attributes of print-job request

Attribute

Status

Description

attributes-charset

required

The character set used by attributes of type text or name

attributes-natural-language

required

The natural language used by attributes of type text or name

printer-uri

required

The printer's Universal Resource Identifier

requesting-user-name

optional

Name of user submitting job (used for authentication, if enabled)

job-name

optional

Name of job used to distinguish between multiple jobs

ipp-attribute-fidelity

optional

If true, tells printer to reject job if all attributes can't be met; otherwise, printer does its best to print the job

document-name

optional

The name of the document (suitable for printing in a banner, for example)

document-format

optional

The format of the document (plaintext, PostScript, etc.)

document-natural-language

optional

The natural language of the document

compression

optional

The algorithm used to compress the document data

job-k-octets

optional

Size of the document in 1,024-octet units

job-impressions

optional

Number of impressions (images imposed on a page) submitted in this job

job-media-sheets

optional

Number of sheets printed by this job


The IPP header contains a mixture of text and binary data. Attribute names are stored as text, but sizes are stored as binary integers. This complicates the process of building and parsing the header, since we need to worry about such things as network byte order and whether our host processor can address an integer on an arbitrary byte boundary. A better alternative would have been to design the header to contain text only. This simplifies processing at the cost of slightly larger protocol messages.

IPP is specified in a series of documents (Requests For Comments, or RFCs) available at http://www.pwg.org/ipp. The main documents are listed in Figure 21.5, although many other documents are available to further specify administrative procedures, job attributes, and the like.

Figure 21.5. Primary IPP RFCs

RFC

Title

2567

Design Goals for an Internet Printing Protocol

2568

Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol

2911

Internet Printing Protocol/1.1: Model and Semantics

2910

Internet Printing Protocol/1.1: Encoding and Transport

3196

Internet Printing Protocol/1.1: Implementor's Guide


    Team BBL
    Previous Page Next Page