The InternetPrinting Protocol is a specialized Internet protocol for communication between client devices and printers. It allows clients to submit one or more print jobs to the printer or print server, and perform tasks such as querying the status of a printer, obtaining the status of print jobs, or cancelling individual print jobs. Like all IP-based protocols, IPP can run locally or over the Internet. Unlike other printing protocols, IPP also supports access control, authentication, and encryption, making it a much more capable and secure printing mechanism than older ones. IPP is the basis of several printer logo certification programs including AirPrint, IPP Everywhere, and Mopria Alliance, and is supported by over 98% of printers sold today.
History
IPP began as a proposal by Novell for the creation of an Internet printing protocol project in 1996. The result was a draft written by Novell and Xerox called the Lightweight Document Printing Application, derived from ECMA-140: Document Printing Application. At about the same time, Lexmark publicly proposed something called the HyperText Printing Protocol, and both HP and Microsoft had started work on new print services for what became Windows 2000. Each of the companies chose to start a common Internet Printing Protocol project in the Printer Working Group and negotiated an IPP birds-of-a-feather session with the Application Area Directors in the Internet Engineering Task Force. The BOF session in December 1996 showed sufficient interest in developing a printing protocol, leading to the creation of the IETF Internet Printing Protocol working group, which concluded in 2005. Work on IPP continues in the PWG with the publication of 23 candidate standards, 1 new and 3 updated IETF RFCs, and several registration and best practice documents providing extensions to IPP and support for different services including , scanning, facsimile, cloud-based services, and overall system and resource management. IPP/1.0 was published as a series of experimental documents in 1999. IPP/1.1 followed as a draft standard in 2000 with support documents in 2001, 2003, and 2015. IPP/1.1 was updated as a proposed standard in January 2017 and then adopted as Internet Standard 92 in June 2018. IPP 2.0 was published as a PWG Candidate Standard in 2009 and defined two new IPP versions with additional conformance requirements beyond IPP 1.1. A subsequent Candidate Standard replaced it 2011 defining an additional 2.2 version for production printers. This specification was updated and approved as a full PWG Standard in 2015. was published in 2013 and provides a common baseline for printers to support so-called "driverless" printing from client devices. It builds on IPP and specifies additional rules for interoperability, such as a list of document formats printers need to support. A corresponding self-certification manual and tool suite was published in 2016 allowing printer manufacturers and print server implementors to certify their solutions against the published specification and be listed on the page maintained by the PWG.
Implementation
IPP is implemented using the Hypertext Transfer Protocol and inherits all of the HTTP streaming and security features. For example, authorization can take place via HTTP's Digest access authentication mechanism, GSSAPI, or any other HTTP authentication method. Encryption is provided using the TLS protocol-layer, either in the traditional always-on mode used by HTTPS or using the HTTP Upgrade extension to HTTP. Public key certificates can be used for authentication with TLS. Streaming is supported using HTTP chunking. The document to be printed is usually sent as a data stream, and can be in various formats, such as PDF or JPEG, depending on the capabilities of the destination printer. IPP uses the traditional client-server model, with clients sending IPP request messages with the MIME media type "application/ipp" in HTTP POST requests to an IPP printer. IPP request messages consist of key/value pairs using a custom binary encoding followed by an "end of attributes" tag and any document data required for the request. The IPP response is sent back to the client in the HTTP POST response, again using the "application/ipp" MIMEmedia type. Among other things, IPP allows a client to:
