IPP (Internet Printing Protocol)

History

IPP originated from proposals in the mid-1990s. According to published histories, Novell proposed an Internet printing protocol project in 1996, with related precursor work including a Xerox/Novell "Lightweight Document Printing Application" (LDPA) and an IBM "HyperText Printing Protocol" (HTPP). These efforts, with contributions routed through the Printer Working Group (PWG), led to an IETF Birds-of-a-Feather session in December 1996 and a chartered IETF IPP working group that later concluded in 2005. (These pre-standardization details come from secondary published histories rather than a primary IETF or PWG charter document, and are reported here as such.)

IPP/1.0 was published in 1999 as a set of Experimental RFCs (RFC 2565 and companion documents 2566–2569 and 2639). IPP/1.1 followed in September 2000 as two Standards-Track documents: RFC 2910 (Encoding and Transport) and RFC 2911 (Model and Semantics), together with companion documents added later — RFC 3196 (Implementor's Guide, November 2001), RFC 3510 (IPP URL Scheme, April 2003), and RFC 7472 (HTTPS transport binding and the ipps URI scheme, March 2015).

In January 2017, IPP/1.1 was reissued as RFC 8010 and RFC 8011, which obsolete RFC 2910 and RFC 2911 respectively and carry full Internet Standard status as STD 92. (Some secondary sources instead date the STD 92 designation to 2018.)

Under PWG stewardship, IPP/2.x was first issued as a Candidate Standard in 2009 (PWG 5100.10-2009), revised (PWG 5100.12-2011), approved as a full PWG standard in 2015 (PWG 5100.12-2015), and updated in a later edition (PWG 5100.12-2024, dated November 8, 2024). The IPP Everywhere driverless-printing profile (PWG 5100.14) was first published in January 2013, with a self-certification manual and tool suite released in 2016; version 1.1 is dated May 15, 2020.

What problem it solved

Before IPP, network printing relied on a fragmented mix of protocols and mechanisms — LPR/LPD (documented in RFC 1179), raw port 9100 socket printing, SMB/CIFS printer shares, AppSocket, and various proprietary schemes. Most of these offered little or no standard way to negotiate capabilities, report rich job and printer status, authenticate users, or work cleanly across the public Internet and through firewalls and proxies.

IPP set out to provide a single, vendor-neutral, Internet-friendly protocol that could:

• Let a client learn what a printer can actually do (media, formats, duplex, color, and so on) before submitting a job.
• Submit jobs and receive detailed, standardized status and error feedback.
• Manage the job lifecycle (hold, release, cancel, restart).
• Inherit mature Internet security and transport by riding on HTTP rather than inventing a new wire protocol.

How it works

IPP defines an abstract object model with two core object types (RFC 2911 / RFC 8011):

• A Printer object represents the print service or device. It exposes printer-description attributes (identity, state, location, supported formats) and job-template attributes (supported and default processing options).
• A Job object represents a submitted print job of one or more documents, with job-template attributes (the client's requested processing) and job-description attributes (state, size, identity).

Clients act on these objects through synchronous request/response operations. Printer operations include Print-Job, Print-URI, Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs, Pause-Printer, Resume-Printer, and Purge-Jobs. Job operations include Send-Document, Send-URI, Cancel-Job, Get-Job-Attributes, Hold-Job, Release-Job, and Restart-Job.

On the wire (RFC 2910 / RFC 8010), each IPP message uses a compact, big-endian binary encoding. A message opens with a two-byte version number (0x01 0x01 for IPP/1.1), a two-byte operation-id (in requests) or status-code (in responses), and a four-byte request-id, followed by tagged attribute groups. Each attribute is encoded as a value-tag, a name (with length prefix), and a value (with length prefix); multi-valued attributes repeat values with a zero-length name. This binary body is sent inside an HTTP POST with Content-Type: application/ipp, and the response is likewise an application/ipp body. IPP defines its own ipp: URI scheme (default port 631), which clients map onto http:/https: for the actual HTTP exchange.

Where it sits in the print/document pipeline

IPP is the job-submission and job-management transport and control layer between the client's print subsystem and the printer or print server. It sits above TCP and HTTP and below the page-description or document layer: IPP carries the document data and the processing instructions, but it does not itself define how a page is rendered.

The actual content is a document format or page-description language — for example PDF, PostScript, PWG Raster, or JPEG — transported inside the IPP job. The flow is roughly: application → operating-system print subsystem → (rasterization or format conversion as needed) → IPP job over HTTP → printer or print server → interpreter and marking engine.

Relationship to printers

IPP can be implemented directly in a printer's firmware, making the device an IPP Printer object reachable on port 631, or it can be fronted by a print server or spooler that presents an IPP interface on the printer's behalf.

Modern network printers commonly implement IPP natively, advertise themselves via DNS-SD (Bonjour) and/or WS-Discovery, and expose their capabilities through Get-Printer-Attributes so that clients can configure jobs without a vendor driver. IPP is also usable over USB through the IPP-USB binding, allowing the same protocol to serve directly attached devices.

The PWG states that IPP is supported by the large majority of printers currently sold; its IPP Everywhere page reports that "98% of all printers sold today support IPP/2.0 and DNS-SD." This figure is presented here as a PWG claim rather than an independently verified benchmark.

Relationship to operating systems

• Linux and Unix: CUPS (the Common UNIX Printing System) uses IPP as its native protocol and serves as a de facto reference implementation across many IPP versions; the OpenPrinting project maintains driverless and IPP tooling.
• Apple: macOS and iOS/iPadOS printing is built on CUPS and IPP. AirPrint is Apple's driverless-printing program layered on IPP plus Bonjour discovery.
• Microsoft Windows: Windows has long supported IPP as a printing transport. Microsoft's Windows Protected Print Mode (introduced with Windows 11 version 24H2 and Windows Server 2025) uses the inbox IPP class driver exclusively and blocks third-party drivers. Per Microsoft's published timeline, no new third-party drivers are accepted to Windows Update from January 15, 2026, and new printer installations default to the IPP inbox driver from July 1, 2026.
• Mobile and Android: Mopria and the Android print framework use IPP for driverless printing.

Relationship to PDF / PostScript / drivers

IPP is format-agnostic transport and control, not a page-description language — it complements PDF and PostScript rather than replacing them. A printer advertises which document formats it accepts via its supported-document-format attributes, and the client sends the matching format inside the IPP job.

The historically important shift enabled by IPP is driverless printing. Instead of a vendor-specific driver generating a proprietary data stream, the client sends a well-known format — notably PWG Raster, PDF, or JPEG — that a compliant printer must understand. This is what IPP Everywhere, AirPrint, and Mopria formalize, which is why IPP is central to the industry's move away from per-model printer drivers.

PostScript and vendor page-description languages can still be sent over IPP where a printer supports them, but they are payloads carried by IPP, not part of IPP itself.

Modern use

Today IPP — via RFC 8010, RFC 8011, and STD 92 together with the PWG IPP/2.x specifications — is the mainstream network-printing protocol and the substrate for driverless printing.

IPP Everywhere (PWG 5100.14) defines a self-certifiable baseline so that any conforming client can print to any conforming printer without vendor software. Per the PWG specification, its required elements include IPP/2.0, DNS-SD network discovery, PWG Raster, and JPEG/JFIF (with JPEG required only for color devices), while PDF and IPP-USB are recommended.

The same IPP foundation underlies Apple AirPrint and Mopria, giving desktop and mobile users out-of-the-box printing. Security in modern deployments uses TLS via the ipps: scheme and HTTPS transport binding defined in RFC 7472.

Advantages

• Vendor-neutral and standardized (IETF STD 92 plus PWG standards), enabling cross-vendor interoperability.
• Capability negotiation: clients can query exactly what a printer supports before submitting a job.
• Rich, standardized status and job management, including state, errors, and hold/release/cancel/restart.
• Rides on HTTP, inheriting mature transport, streaming, proxy traversal, authentication, and TLS security.
• Enables driverless printing through well-known formats (PWG Raster, PDF, JPEG), removing the need for per-model drivers.
• Integrates with discovery via DNS-SD/Bonjour and WS-Discovery, and works over both network and USB (IPP-USB).
• Has broad ecosystem adoption (CUPS, AirPrint, IPP Everywhere, Mopria).

Limitations

• IPP standardizes submission, control, and capability discovery, but actual output depends on the printer's supported document formats; interoperability still requires a shared format.
• Security is only as strong as its deployment: plain IPP over HTTP is unencrypted, and confidentiality and integrity require TLS (ipps/HTTPS) and proper authentication, which are optional to configure.
• Firewall and port considerations: IPP relies on TCP 631 (and HTTP/HTTPS), which may need explicit network allowances.
• The full attribute model is large; older or minimal devices may implement only subsets, and legacy protocols (LPD, port 9100) persist in mixed environments.
• Advanced and finishing features vary by device; not every job-template attribute is universally supported.

Related standards and protocols

• LPR/LPD (RFC 1179) — an earlier Unix line-printer protocol. RFC 1179 is Informational and documents existing BSD practice; it is not an IETF-ratified standard.
• Raw port 9100 / AppSocket — simple socket printing with no capability negotiation.
• SMB/CIFS printer sharing — Windows-centric print sharing.
• PWG Raster, PDF, PostScript, JPEG/JFIF, and PCL — document and page formats carried by IPP.
• DNS-SD / mDNS (Bonjour) and WS-Discovery — printer discovery mechanisms used with IPP.
• HTTP, HTTPS, and TLS (RFC 7472 for the ipps scheme) — transport and security.
• AirPrint, IPP Everywhere, and Mopria — certification programs built on IPP.
• IPP-USB — a binding of IPP over USB.

Timeline

1. 1996

   According to published histories, Novell proposes an Internet printing protocol project; precursor work includes Xerox/Novell LDPA and IBM HTPP; an IETF Birds-of-a-Feather session is held in December 1996.

2. 1999

   IPP/1.0 published as Experimental RFCs (RFC 2565 and companion documents).

3. September 2000

   IPP/1.1 published: RFC 2910 (Encoding and Transport) and RFC 2911 (Model and Semantics).

4. November 2001

   RFC 3196, IPP/1.1 Implementor's Guide.

5. April 2003

   RFC 3510, IPP URL Scheme.

6. 2005

   IETF IPP working group concludes.

7. 2009

   IPP/2.x published as a PWG Candidate Standard (PWG 5100.10-2009).

8. 2011

   IPP/2.x revised (PWG 5100.12-2011).

9. January 2013

   IPP Everywhere first published (PWG 5100.14 v1.0).

10. March 2015

    RFC 7472 (ipps/HTTPS transport binding) published; IPP/2.x was approved as a full PWG standard (PWG 5100.12-2015) later that year.

11. 2016

    IPP Everywhere self-certification manual and tool suite released.

12. January 2017

    RFC 8010 and RFC 8011 published (obsoleting RFC 2910 and RFC 2911) and assigned Internet Standard status as STD 92. (Some secondary sources instead date the STD 92 designation to 2018.)

13. May 2020

    IPP Everywhere v1.1 (PWG 5100.14) dated May 15, 2020.

14. November 2024

    IPP/2.x Fourth Edition (PWG 5100.12-2024).