Internet Printing Protocol/1.1: Model and Semantics

IPP uses URI-based object identity so Printers and Jobs can be unambiguously referenced across the Internet. A Printer exposes multiple URIs to support simultaneous access via different security configurations; 'uri-security-supported' and 'uri-authentication-supported' are required to have the same cardinality as 'printer-uri-supported' to keep security metadata aligned with each access channel.

security

The IPP Printer object deliberately abstracts all physical configurations (embedded device, hosted print server, fan-out to multiple devices) into a single logical entity, hiding implementation topology from Clients. This allows uniform Client behavior regardless of whether the Printer is a direct-attached device, a spooler, or a multi-device print farm.

Clients SHOULD supply 'utf-8' in 'attributes-charset' to maximize interoperability with IPP objects, even when the Client natively uses US-ASCII or ISO-8859-1. The Client must then perform charset conversion or filter characters in the response it cannot present. If both sides share another common charset, they MAY use it to avoid conversion overhead or data loss.

Clients SHOULD use 'printer-uri' together with 'job-id' to target Job operations rather than relying on 'job-uri' alone, whose use is DEPRECATED. Job numeric IDs are unique only within the context of the creating Printer, not globally, so the 'job-printer-uri' attribute is needed to resolve a Job's creating Printer when only 'job-uri' is available.

All Clients and IPP objects MUST support the 'utf-8' charset. If a Printer does not support the Client-supplied charset value, the Printer MUST reject the request, set 'attributes-charset' to 'utf-8' in the response, and return 'client-error-charset-not-supported' with any text or name attributes encoded in UTF-8.

Attributes within a group MUST be unique; a group with duplicate attribute names is malformed. Clients MUST NOT submit such requests, and Printers MUST NOT return such responses. Upon receiving a malformed request, the Printer MUST either reject it with 'client-error-bad-request' (RECOMMENDED) or process it by selecting only one of the duplicate instances without using values from more than one.

Printers SHOULD support IPP Job Template attributes and values that correspond to features the physical device is capable of performing. If a Printer is not physically capable of a feature (e.g., stapling), the corresponding value (e.g., 'staple') MUST NOT appear in the 'xxx-supported' attribute.

REQUIRED Printer operations include: Print-Job, Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs, Get-Job-Attributes, Cancel-Job, and Send-Document. OPTIONAL operations include Print-URI, Pause-Printer, Resume-Printer, Purge-Jobs, Hold-Job, Release-Job, and Restart-Job. An IPP object is non-conformant if it does not support a REQUIRED operation.

The 'attributes-charset' and 'attributes-natural-language' attributes MUST be the first two attributes in every IPP request and response as part of the initial Operation Attributes group; 'attributes-charset' MUST be first and 'attributes-natural-language' MUST be second.

The Client-supplied Printer URI in a Job Creation request MUST be one of the values in the Printer's 'printer-uri-supported' attribute, and that attribute MUST contain at least one URI. The Printer generates the Job URI based on its configured security policy and the URI used by the Client in the Job Creation request.

security

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

When an IPP object receives a request to perform an operation it does not support, it MUST return the 'server-error-operation-not-supported' status-code. Before using an OPTIONAL operation, a Client SHOULD first query the Printer's 'operations-supported' attribute via the REQUIRED Get-Printer-Attributes operation.

When 'ipp-attribute-fidelity' is 'true' in a Job Creation request, the Printer MUST reject the job if any supplied attribute or value is unsupported. When 'false' (the default if not supplied by the Client), the Printer accepts and processes the job while substituting or ignoring unsupported attributes and returning them in the Unsupported Attributes group.

IPP operations are synchronous request/response pairs. Every operation request carries: a version-number, an operation-id, a request-id, and any required attributes and/or Document data. Every response carries: a version-number, a status-code, the matching request-id, and any required attributes or status messages.

Job Template attributes defined in Section 5.2 include: job-priority (integer 1:100), job-hold-until (type2 keyword|name), job-sheets (type2 keyword|name), multiple-document-handling (type2 keyword), copies (integer 1:MAX), finishings (1setOf type2 enum), page-ranges (1setOf rangeOfInteger), sides (type2 keyword), number-up (integer), orientation-requested (type2 enum), media (type2 keyword|name), printer-resolution (resolution), and print-quality (type2 enum).

The Job object models a Print Job containing zero or more Documents. Job attributes are grouped as 'job-template' (Client-supplied processing instructions intended to override Printer defaults and embedded Document instructions) and 'job-description' (identification, state, size, and progress). An implementation MUST support at least one Document per Job and MAY support multiple Documents.

The Printer object encapsulates functions of physical Output Devices along with spooling, scheduling, and multi-device management, implementing the server side of IPP/1.1. Printer attributes are grouped as 'job-template' (supported capabilities and defaults) and 'printer-description' (identification, state, and location). A Printer can represent one or more physical devices, a logical print device, or non-marking services such as a fax gateway.

When 'application/octet-stream' is supplied as the document-format, the Printer auto-senses the actual document format from the data stream. If the Printer cannot determine the format, it SHOULD process it as the 'document-format-default'. Auto-sensing allows Clients that do not know the document format to still submit Print Jobs.

RFC 8011 specifies IANA registration procedures for IPP extensions via separate registries covering: object types (Section 7.1), attribute names and syntaxes (Section 7.2), type2 keyword values (Section 7.3), type2 enum values (Section 7.4), attribute group names (Section 7.5), out-of-band attribute values (Section 7.6), attribute syntax types (Section 7.7), operation IDs (Section 7.8), and status-code values (Section 7.9). Registration templates are in Appendix A.

registry

Each URI in 'printer-uri-supported' has a corresponding entry in 'uri-security-supported' (values: 'none', 'ssl3' [DEPRECATED], 'tls') and 'uri-authentication-supported' (values: 'none', 'requesting-user-name', 'basic', 'digest', 'certificate'). These parallel arrays have identical cardinality, allowing a single Printer to expose different security postures on different URIs simultaneously.

security, tls

IPP defines three security scenarios: Client and Server in the same security domain (internal network, relaxed requirements); Client and Server in different security domains (requiring authentication and message privacy via TLS); and Print by Reference, where the Printer fetches document data from a third-party URI, potentially exposing the document to intermediate servers with no IPP-enforced security.

security, tls

IPP objects SHOULD restrict query results for Job attributes to Operators, Administrators, and the job-owner. Privileged operations such as Pause-Printer, Resume-Printer, Cancel-Job (for others' jobs), and Purge-Jobs require Operator or Administrator privilege; implementations MUST enforce appropriate access control based on site policy.

security

Job objects transition through states: 'pending' (queued, awaiting processing), 'pending-held' (held, not ready for processing), 'processing' (actively being processed), 'processing-stopped' (halted mid-job), 'canceled' (canceled by Cancel-Job), 'aborted' (system-aborted), and 'completed' (successfully finished). The 'canceled', 'aborted', and 'completed' states are Terminating States from which no forward transitions occur.

Printer objects maintain three states: 'idle' (accepting jobs, none currently processing), 'processing' (one or more jobs actively processing), and 'stopped' (not processing, intervention required). The 'printer-state-reasons' attribute (1setOf type2 keyword) provides supplementary detail about conditions contributing to the current state.

The 'charset' syntax is a case-insensitive string of up to 40 octets identifying an IANA-registered charset (e.g., 'utf-8', 'us-ascii'). The 'uri' syntax carries a URI of up to 1023 octets. The 'mimeMediaType' syntax is a MIME media type string of up to 255 octets (e.g., 'application/postscript', 'application/octet-stream').

The 'integer' syntax represents a 32-bit signed value in the range -2**31 to 2**31-1; per-attribute allowed ranges are written as (m:n). The 'rangeOfInteger' syntax encodes a lower and upper integer bound pair. The 'resolution' syntax encodes cross-feed and feed resolution values in dots-per-inch or dots-per-centimeter.

The 'text' attribute syntax has two sub-forms: 'textWithoutLanguage' (natural language inferred from the 'attributes-natural-language' operation attribute) and 'textWithLanguage' (embeds an explicit language tag override alongside the text). Maximum size is specified per-attribute in octets; values exceeding the limit SHOULD be truncated at a natural word boundary.