Internet Printing Protocol/1.1: Model and Semantics

Both Job URI and numeric Job ID are required because many existing printing systems identify jobs only by 32-bit integer IDs unique within one Printer's context, while URI-based identification enables flexible distributed deployments where a Job may reside remotely from the Printer that accepted the create request. Supporting both allows all client types to access Job objects regardless of local constraints.

Documents are not modeled as first-class IPP objects in IPP/1.1: they have no object identifier or associated attributes. All job processing instructions are modeled as Job Template attributes that apply equally to all documents in a Job, intentionally simplifying the model at the cost of per-document control.

The notification service (push-based event delivery) is explicitly out of scope for IPP/1.1. Clients must poll using Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes. This simplification keeps IPP/1.1 focused on core end-user printing functionality, deferring notification to a separate future extension.

IPP/1.1 Printer objects MUST support version '1.1' and SHOULD support '1.0'. The Printer returns the highest version it supports that is not greater than the client-requested version. If the requested major version is not supported, the Printer returns 'server-error-version-not-supported' with the closest supported version.

To maximize interoperability, client implementers SHOULD supply 'utf-8' in 'attributes-charset' even when the client only uses a simpler charset such as US-ASCII, since IPP objects are only required to support utf-8. The client must then filter or convert characters it cannot present from the response.

All clients and IPP objects MUST support the 'utf-8' charset. If the Printer does not support the client-supplied charset value, it MUST reject the request, set 'attributes-charset' to 'utf-8' in the response, and return the 'client-error-charset-not-supported' status code.

An IPP implementation MUST support at least one document per Job object and MAY support multiple documents. If multiple documents are supported, the 'multiple-document-jobs-supported' boolean Printer attribute MUST be set accordingly.

Attributes within a group MUST be unique; duplicate attribute names make the group malformed. Clients MUST NOT submit such malformed requests and Printers MUST NOT return such malformed responses. A Printer receiving a duplicate-attribute request MUST either reject it with 'client-error-bad-request' or process it selecting only one instance.

Before using an OPTIONAL operation, a client SHOULD first use the REQUIRED Get-Printer-Attributes operation to query the Printer's 'operations-supported' attribute and SHOULD NOT attempt an unsupported OPTIONAL operation. An IPP object receiving an unsupported operation MUST return 'server-error-operation-not-supported'.

In Job operations using both 'printer-uri' and 'job-id' as targets, 'printer-uri' MUST be the third attribute and 'job-id' MUST be the fourth attribute in the operation attributes group. All target URIs in requests and responses MUST be in absolute format, not relative.

The 'attributes-charset' attribute MUST be the first attribute and 'attributes-natural-language' MUST be the second attribute in the Operation Attributes group of every IPP request and response. These two attributes MUST appear in every IPP request and response.

The client-supplied Printer URI in a create request MUST be one of the values in 'printer-uri-supported'. The Printer MUST assign the new Job a URI consistent with the security level of the URI used in the create request (e.g., a secure submission URI yields a secure Job URI).

security

The IPP object MUST accept any natural language and any Natural Language Override value supplied by the client, independent of 'generated-natural-language-supported' and independent of 'ipp-attribute-fidelity'. The IPP object MUST NOT reject a request based on an unsupported natural language.

The 'request-id' in every operation request MUST be an integer in the range 1 to 2^31-1 inclusive. The IPP object copies all 32 bits of the client-supplied 'request-id' into every response. If the request is terminated before the complete 'request-id' is received, the IPP object returns a response with 'request-id' of 0.

When the Printer successfully processes a create request, it MUST generate both a Job URI (stored in 'job-uri') and a Job ID (stored in 'job-id'), a 32-bit positive integer unique only within the context of the creating Printer object.

IPP defines two primary object types: Printer and Job. A Printer object encapsulates output device functions, spooling, scheduling, and device management. A Job object models a print job containing one or more documents with associated job-template and job-description attributes.

Job Template attributes (section 4.2) specify job processing instructions: job-priority (integer 1:100), job-hold-until, job-sheets, multiple-document-handling, copies, finishings (type2 enum), page-ranges (rangeOfInteger), sides, number-up, orientation-requested, media, printer-resolution, and print-quality. These override Printer defaults and embedded document instructions.

Status codes are type2 enum values in range 0x0000 to 0x7FFF. Successful: 0x0000 (successful-ok), 0x0001 (ignored-or-substituted-attributes), 0x0002 (conflicting-attributes). Client errors span 0x0400–0x040F including charset-not-supported (0x040D) and conflicting-attributes (0x040E). Server errors span 0x0500–0x0509.

The 'ipp-attribute-fidelity' operation attribute controls unsupported Job Template attribute handling. When 'true', the Printer MUST reject the job if any supplied attribute or value is unsupported; when 'false', the Printer accepts the job and ignores unsupported attributes, returning them in the Unsupported Attributes group.

The 'job-printer-uri' Job attribute contains the URI of the Printer object that created the Job. When the Printer supports multiple URIs, it uses the specific URI supplied by the client in the create request to populate this attribute, enabling reverse lookup from job to printer.

The 'job-state-reasons' attribute (1setOf type2 keyword) provides supplemental detail about a Job's current state. Values include 'job-incoming', 'job-data-insufficient', 'job-hold-until-specified', 'processing-to-stop-point', 'document-access-error', 'job-completed-successfully', 'job-completed-with-warnings', and 'job-completed-with-errors'.

The Natural Language Override mechanism allows individual 'text' or 'name' attribute values to carry an explicit language tag using 'textWithLanguage' or 'nameWithLanguage' encoding when the value's language differs from the 'attributes-natural-language' operation attribute. The IPP object MUST store and return the associated natural language for all client-supplied attributes.

The 'printer-uri-supported' (1setOf uri) attribute contains one or more URIs identifying communication channels to the Printer. Each URI has a parallel entry in 'uri-security-supported' (indicating security mechanism, e.g., 'tls' or 'none') and 'uri-authentication-supported' (indicating authentication mechanism, e.g., 'digest' or 'none'); all three attributes have the same cardinality.

security, tls

IANA registries are established for: type2 and type3 keyword and enum attribute value extensions, new IPP attributes and attribute syntaxes, new operations, attribute groups, status codes, and out-of-band attribute values. Section 11 provides registration proposal formats for each category. MIME type and charset registrations also apply.

registry

A Printer MAY implement Restricted Queries, returning a subset of attribute values to unauthorized requesters. The 'job-originating-user-name' attribute supports access control so operators can view all jobs while regular users are restricted to their own. Operations by operators and administrators require elevated privilege verification.

security

For queries on jobs submitted using non-IPP protocols (e.g., LPD), the Printer object SHOULD return job information but MAY omit sensitive attributes. The 'job-originating-user-name' for such jobs depends on the authentication information available from the non-IPP protocol.

security

IPP security relies on Transport Layer Security (TLS) [RFC2246] for message privacy and integrity. The 'uri-security-supported' Printer attribute indicates the security mechanism per URI. Three deployment scenarios are identified: client and server in the same security domain, different security domains, and print-by-reference (Printer fetches document from third-party URI).

security, tls

Print-URI and Send-URI operations cause the Printer to fetch document data from a third-party URI, making the Printer act as a client to a potentially hostile server. URIs embedded in job and printer attributes may also leak sensitive location information about document origins.

security

A Job object transitions through seven states: 'pending' (queued awaiting resources), 'pending-held' (held, not eligible for processing), 'processing' (actively printing), 'processing-stopped' (paused mid-job), 'canceled' (canceled before completion), 'aborted' (system-aborted), and 'completed' (finished successfully). Transitions are triggered by Cancel-Job, Hold-Job, Release-Job, Restart-Job, and normal job completion.

A Printer object has three states: 'idle' (ready to accept and print jobs), 'processing' (printing one or more jobs), and 'stopped' (not currently capable of printing, needs attention). Transitions are driven by Pause-Printer, Resume-Printer operations, and job processing events.