2. Conventions Used in This Document
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The key word "DEPRECATED" in this document refers to an operation,
attribute, or value that SHOULD NOT be used or supported in new
2.2. Printing Terminology
Client: Initiator of outgoing IPP session requests and sender of
outgoing IPP operation requests (Hypertext Transfer Protocol
(HTTP/1.1) user agent, as defined in [RFC7230]).
Document: An object created and managed by a Printer that contains
description, processing, and status information. A Document object
can have attached data and is bound to a single Job [PWG5100.5].
'ipp' URI: An IPP URI as defined in [RFC3510].
'ipps' URI: An IPP URI as defined in [RFC7472].
Job: An object created and managed by a Printer that contains
description, processing, and status information. The Job also
contains zero or more Document objects.
Logical Device: A print server, software service, or gateway that
processes Jobs and either forwards or stores the processed Job or
uses one or more Physical Devices to render output.
Output Device: A single Logical or Physical Device.
Physical Device: A hardware implementation of an endpoint device,
e.g., a marking engine, a fax modem, etc.
Printer: Listener for incoming IPP session requests and receiver of
incoming IPP operation requests (HTTP/1.1 server, as defined in
[RFC7230]) that represents one or more Physical Devices or a Logical
2.3. Model Terminology
An End User who is also authorized to manage all aspects of an Output
Device or Printer, including creating the Printer instances and
controlling the authorization of other End Users and Operators
An attribute is an item of information that is associated with an
instance of an IPP object (Printer, Job, etc.). An attribute
consists of an attribute name and one or more attribute values. Each
attribute has a specific attribute syntax. All object attributes are
defined in Section 5, and all operation attributes are defined in
Job Template attributes are described in Section 5.2. The Client
optionally supplies Job Template attributes in a Job Creation request
(operation requests that create Job objects). The Printer object has
associated attributes that define supported and default values for
18.104.22.168. Attribute Group Name
Related attributes are grouped into named groups. The name of the
group is a keyword. The group name can be used in place of naming
all the attributes in the group explicitly. Attribute groups are
defined in Section 4.
22.214.171.124. Attribute Name
Each attribute is uniquely identified in this document by its
attribute name. An attribute name is a keyword. The keyword
attribute name is given in the section title in this document that
describes that attribute. In running text in this document,
attribute names are indicated inside double quotation marks (") where
the quotation marks are not part of the keyword itself.
126.96.36.199. Attribute Syntax
Each attribute is defined using an explicit syntax type. In this
document, each syntax type is defined as a keyword with specific
meaning. The "Encoding and Transport" document [RFC8010] indicates
the actual "on-the-wire" encoding rules for each syntax type.
Attribute syntax types are defined in Section 5.1.
188.8.131.52. Attribute Value
Each attribute has one or more values. Attribute values are
represented in the syntax type specified for that attribute. In
running text in this document, attribute values are indicated inside
single quotation marks ('), whether their attribute syntax is
keyword, integer, text, etc. where the quotation marks are not part
of the value itself.
2.3.3. End User
An End User is a person or software process that is authorized to
perform basic printing functions, including finding/locating a
Printer, creating a local instance of a Printer, viewing Printer
status, viewing Printer capabilities, submitting a Print Job, viewing
Print Job status, and altering the attributes of a Print Job
An Impression is the content imposed upon one side of a Media Sheet
by a marking engine, independent of the number of times that the
sheet side passes any marker. An Impression contains one or more
Input Pages that are imposed (scaled, translated, and/or rotated)
during processing of the Document data.
2.3.5. Input Page
An Input Page is a page according to the definition of "pages" in the
language used to express the Document data.
2.3.6. Job Creation Operation
A Job Creation operation is any operation that causes the creation of
a Job object, e.g., the Create-Job, Print-Job, and Print-URI
operations defined in this document.
Keywords are used within this document as identifiers of semantic
entities within the abstract model (see Section 5.1.4). Attribute
names, some attribute values, attribute syntaxes, and attribute group
names are represented as keywords.
2.3.8. Media Sheet
A Media Sheet is a single instance of a medium, whether printing on
one or both sides of the medium. Media Sheets also include sections
of roll media.
An Operator is an End User that also has special rights on the Output
Device or Printer. The Operator typically monitors the status of the
Printer and also manages and controls the Jobs at the Output Device
[RFC2567]. The Operator is allowed to query and control the Printer,
Jobs, and Documents based on site policy.
A Set is a logical boundary between the delivered Media Sheets of a
printed Job. For example, in the case of a ten-page single Document
with collated pages and a request for 50 copies, each of the 50
printed copies of the Document constitutes a Set. If the pages were
uncollated, then 50 copies of each of the individual pages within the
Document would represent each Set. Finishing processes operate on
2.3.11. Support of Attributes
By definition, a Printer supports an attribute only if that Printer
accepts it in a request or responds with the corresponding attribute
populated with some value(s) in a response to a query for that
attribute. A Printer supports an attribute value if the value is one
of the Printer's "supported values" attributes. The device behind a
Printer can exhibit a behavior that corresponds to some IPP
attribute, but if the Printer, when queried for that attribute,
doesn't respond with the attribute, then as far as IPP is concerned,
that implementation does not support that feature. If the Printer's
"xxx-supported" attribute is not populated with a particular value
(even if that value is a legal value for that attribute), then that
Printer does not support that particular value.
A conforming implementation supports all REQUIRED attributes.
However, even for REQUIRED attributes, conformance to IPP does not
mandate that all implementations support all possible values
representing all possible Job processing behaviors and features. For
example, if a given instance of a Printer supports only certain
Document formats, then that Printer responds with the
"document-format-supported" attribute populated with a set of values,
or possibly only one value, taken from the entire set of possible
values defined for that attribute. This limited set of values
represents the Printer's set of supported Document formats.
Supporting an attribute and some set of values for that attribute
enables IPP End Users to be aware of and make use of those features
associated with that attribute and those values. If an
implementation chooses to not support an attribute or some specific
value, then IPP End Users would have no ability to make use of that
feature within the context of IPP itself. However, due to existing
practice and legacy systems that are not IPP aware, there might be
some other mechanism outside the scope of IPP to control or request
the "unsupported" feature (such as embedded instructions within the
Document data itself).
For example, consider the following for the "finishings-supported"
1) If a Printer is not physically capable of stapling, the
"finishings-supported" attribute MUST NOT be populated with the
value of 'staple'.
2) A Printer is physically capable of stapling; however, an
implementation chooses not to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST NOT be a
value in the "finishings-supported" Printer Description
attribute. Without support for the value 'staple', an IPP
End User would have no means within the protocol itself to
request that a Job be stapled. However, an existing Document
data formatter might be able to request that the Document be
stapled directly with an embedded instruction within the Document
data. In this case, the IPP implementation does not "support"
stapling; however, the End User is still able to have some
control over the stapling of the completed Job.
3) A Printer is physically capable of stapling, and an
implementation chooses to support stapling in the IPP
"finishings" attribute. In this case, 'staple' MUST be a value
in the "finishings-supported" Printer attribute. Doing so
enables End Users to be aware of and make use of the stapling
feature using IPP attributes.
Even though support for Job Template attributes by a Printer is
OPTIONAL in IPP/1.1, Printers whose associated device(s) is capable
of realizing any feature or function that corresponds to an IPP
attribute and some associated value SHOULD support that IPP attribute
The set of values in any of the supported value attributes is set
(populated) by some administrative process or automatic sensing
mechanism that is outside the scope of this document. For
administrative policy and control reasons, an Administrator can
choose to make only a subset of possible values visible to the
End User. In this case, the real Output Device behind the IPP
Printer abstraction can be capable of a certain feature; however, an
Administrator is specifying that access to that feature not be
exposed to the End User through IPP. Also, since a Printer can
represent a logical print device (not just a Physical Device), the
actual process for supporting a value is undefined and left up to the
implementation. However, if a Printer supports a value, some manual
human action might be needed to realize the semantic action
associated with the value, but no End User action is required.
For example, if one of the values in the "finishings-supported"
attribute is 'staple', the actual process might be an automatic
staple action by a Physical Device controlled by some command sent to
the device. Or, the actual process of stapling might be a manual
action by an Operator at an Operator-attended Printer.
For another example of how supported attributes function, consider an
Administrator who desires to control all Print Jobs so that no Job
sheets are printed in order to conserve paper. To force no Job
sheets, the Administrator sets the only supported value for the
"job-sheets-supported" attribute to 'none'. In this case, if a
Client requests anything except 'none', the Job Creation request is
rejected or the "job-sheets" value is ignored (depending on the value
of "ipp-attribute-fidelity"). To force the use of Job start/end
sheets on all Jobs, the Administrator does not include the value
'none' in the "job-sheets-supported" attribute. In this case, if a
Client requests 'none', the Job Creation request is rejected or the
"job-sheets" value is ignored (again depending on the value of
Job Template attributes will typically have corresponding
"xxx-supported" and "xxx-default" Printer Description attributes that
contain the supported and default values for the attribute. For
capabilities that are not associated with a Job, the convention is to
have an "xxx-supported" Printer Description attribute that lists the
supported values and an "xxx-configured" Printer Description
attribute that contains the value being used by the Printer. For
example, the "charset-supported" Printer Description attribute
(Section 5.4.18) lists the supported character sets for the Printer
while the "charset-configured" Printer Description attribute
(Section 5.4.17) specifies the character set being used by the
2.3.12. Terminating State
The final state for a Job or other object is called its Terminating
State. For example, the 'aborted', 'canceled', and 'completed' Job
states are Terminating States.
ABNF: Augmented Backus-Naur Form [RFC5234]
ASCII: American Standard Code for Information Interchange [RFC20]
HTTP: Hypertext Transfer Protocol [RFC7230]
HTTPS: HTTP over TLS [RFC2818]
IANA: Internet Assigned Numbers Authority
IEEE: Institute of Electrical and Electronics Engineers
IESG: Internet Engineering Steering Group
IPP: Internet Printing Protocol (this document, [RFC8010], and
ISTO: IEEE Industry Standards and Technology Organization
LPD: Line Printer Daemon Protocol [RFC1179]
PWG: IEEE-ISTO Printer Working Group
RFC: Request for Comments
TCP: Transmission Control Protocol [RFC793]
TLS: Transport Layer Security [RFC5246]
URI: Uniform Resource Identifier [RFC3986]
URL: Uniform Resource Locator [RFC3986]
UTF-8: Unicode Transformation Format - 8-bit [RFC3629]
3. IPP Objects
This document defines IPP objects of types Printer and Job. Each
type of object models relevant aspects of a real-world entity such as
a real Printer or real Print Job. Each object type is defined as a
set of possible attributes that can be supported by instances of that
object type. For each object (instance), the actual set of supported
attributes and values describe a specific implementation. The
object's attributes and values describe its state, capabilities,
realizable features, Job processing functions, and default behaviors
and characteristics. For example, the Printer object type is defined
as a set of attributes that each Printer object potentially supports.
In the same manner, the Job object type is defined as a set of
attributes that are potentially supported by each Job object.
Each attribute included in the set of attributes defining an object
type is labeled as:
o "REQUIRED": each object MUST support the attribute.
o "RECOMMENDED": each object SHOULD support the attribute.
o "OPTIONAL": each object MAY support the attribute.
Some definitions of attribute values indicate that an object MUST or
SHOULD support the value; otherwise, support of the value is
OPTIONAL. However, if an implementation supports an attribute, it
MUST support at least one of the possible values for that attribute.
3.1. Printer Object
The major component of the IPP Model is the Printer object. A
Printer object implements the server side of the IPP/1.1 protocol.
Using the protocol, End Users can query the attributes of the Printer
object and submit Print Jobs to the Printer object. The actual
implementation components behind the Printer abstraction can take on
different forms and different configurations. However, the model
abstraction allows the details of the configuration of real
components to remain opaque to the End User. Section 4 describes
each of the Printer operations in detail.
The capabilities and state of a Printer object are described by its
attributes. Printer attributes are divided into two groups:
o "job-template" attributes: These attributes describe supported Job
processing capabilities and defaults for the Printer object (see
o "printer-description" attributes: These attributes describe the
Printer's identification, state, location, references to other
sources of information about the Printer object, etc. (see
Since a Printer object is an abstraction of a generic Document Output
Device and print service provider, a Printer object could be used to
represent any real or virtual device with semantics consistent with
the Printer object, such as a fax device, an imager, or even a CD
Some examples of configurations supporting a Printer object include:
1. An Output Device with no spooling capabilities
2. An Output Device with a built-in spooler
3. A print server supporting IPP with one or more associated Output
3a. The associated Output Devices are or are not capable of
3b. The associated Output Devices possibly support IPP
Figure 2 shows some examples of how Printers can be realized on top
of various distributed printing configurations. The embedded case
below represents configurations 1 and 2 above. The "hosted Printer"
and "fan out" items represent configurations 3a and 3b, respectively.
In this document, the term "Client" refers to a software entity that
sends IPP operation requests to an IPP Printer and accepts IPP
operation responses. A Client MAY be:
1. contained within software controlled by an End User, e.g.,
activated by the "Print" menu item in an application, or
2. the print server component that sends IPP requests to either an
Output Device or another "downstream" print server.
The term "IPP Printer" is a network entity that accepts IPP operation
requests and returns IPP operation responses. As such, an IPP
Printer object MAY be:
1. an (embedded) device component that accepts IPP requests and
controls the device, or
2. a component of a print server that accepts IPP requests (where
the print server controls one or more networked devices using IPP
or other protocols).
##### indicates a Printer object that is
either embedded in an Output Device or
hosted in a server. The Printer object
might or might not be capable of queuing/spooling.
any indicates any network protocol or direct
connect, including IPP
O +--------+ | ########### |
/|\ | Client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
O +--------+ ########### | |
/|\ | Client |--IPP--># Printer #-any->| Output Device |
/ \ +--------+ # Object # | |
fan out: | |
+-->| Output Device |
any/ | |
O +--------+ ########### / +---------------+
/|\ | Client |-IPP-># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+-->| Output Device |
Figure 2: IPP Printer Object Architecture
3.2. Job Object
A Job object is used to model a Print Job. A Job object contains
zero or more Documents. The information required to create a Job
object is sent in a Job Creation request from the End User via an IPP
Client to the Printer. The Printer validates the Job Creation
request, and if the Printer accepts the request, the Printer creates
the new Job object. Section 4 describes each of the Job operations
The characteristics and state of a Job object are described by its
attributes. Job attributes are grouped into two groups as follows:
o "job-template" attributes: These attributes can be supplied by the
Client or End User and include Job processing instructions that
are intended to override any Printer defaults and/or instructions
embedded within the Document data (see Section 5.2)
o "job-description" attributes: These attributes describe the Job's
identification, state, size, etc. The Client supplies some of
these attributes, and the Printer generates others (see
An implementation MUST support at least one Document per Job object.
An implementation MAY support multiple Documents per Job object. A
Document is either:
o a stream of Document data in a format supported by the Printer
(typically a Page Description Language -- PDL), or
o a reference to such a stream of Document data.
All Job processing instructions are modeled as Job object attributes.
These attributes are called "Job Template attributes", and they apply
equally to all Documents within a Job object.
3.3. Object Relationships
IPP objects have relationships that are maintained persistently along
with the persistent storage of the object attributes.
A Printer object can represent either one or more physical Output
Devices or a Logical Device that "processes" Jobs but never actually
uses a physical Output Device to put marks on paper. Examples of
Logical Devices include a web page publisher or a gateway into an
online Document archive or repository. A Printer contains zero or
more Job objects.
A Job object is contained by exactly one Printer; however, the
identical Document data associated with a Job could be sent to either
the same or a different Printer. In this case, a second Job object
would be created that would be almost identical to the first Job;
however, it would have new (different) Job object identifiers (see
A Job either is empty (before any Documents have been added) or
contains one or more Documents. If the contained Document is a
stream of Document data, that stream can be contained in only one
Document. However, there can be identical copies of the stream in
other Documents in the same or different Jobs. If the contained
Document is just a reference to a stream of Document data, other
Documents (in the same or different Job(s)) contain the same
3.4. Object Identity
All IPP objects (Printers, Jobs, etc.) are identified by a Uniform
Resource Identifier (URI) [RFC3986] so that they can be persistently
and unambiguously referenced. Since every URL is a specialized form
of a URI, even though the more generic term "URI" is used throughout
the rest of this document, its usage is intended to cover the more
specific notion of "URL" as well.
An Administrator configures Printers to either support or not support
authentication and/or message privacy using Transport Layer Security
(TLS) [RFC5246]; the mechanism for security configuration is outside
the scope of this document. In some situations, both types of
connections (both authenticated and unauthenticated) can be
established using a single communication channel that has some sort
of negotiation mechanism. In other situations, multiple
communication channels are used, one for each type of security
configuration. Section 9 provides a full description of all security
considerations and configurations.
If a Printer supports more than one communication channel, some or
all of those channels might support and/or require different security
mechanisms. In such cases, an Administrator could expose the
simultaneous support for these multiple communication channels as
multiple URIs for a single Printer where each URI represents one of
the communication channels to the Printer. To support this
flexibility, the IPP Printer object type defines a multi-valued
identification attribute called the "printer-uri-supported" attribute
that MUST contain at least one URI. The "printer-uri-supported"
attribute has two companion attributes, the "uri-security-supported"
attribute and the "uri-authentication-supported" attribute. Both
have the same cardinality as "printer-uri-supported". The purpose of
the "uri-security-supported" attribute is to indicate the security
mechanisms (if any) used for each URI listed in
"printer-uri-supported". The purpose of the
"uri-authentication-supported" attribute is to indicate the
authentication mechanisms (if any) used for each URI listed in
"printer-uri-supported". These three attributes are fully described
in Sections 5.4.1, 5.4.2, and 5.4.3.
When a Job is submitted to the Printer via a Job Creation request,
the Client supplies only a single Printer URI. The Client-supplied
Printer URI MUST be one of the values in the "printer-uri-supported"
IPP/1.1 does not specify how the Client obtains the Client-supplied
URI, but it is RECOMMENDED that a Printer be registered as an entry
in a directory service. End Users and programs can then interrogate
the directory, searching for Printers. Appendix D defines a generic
schema for Printer object entries in the directory service and
describes how the entry acts as a bridge to the actual IPP Printer.
The entry in the directory that represents the IPP Printer includes
the possibly many URIs for that Printer as values in one of its
When a Client submits a Job Creation request to the Printer, the
Printer validates the request and creates a new Job object. The
Printer assigns the new Job a numeric identifier that is stored in
the "job-id" Job attribute and a URI that is stored in the "job-uri"
Job attribute. Both the numeric identifier and URI can then be used
by Clients as the target for subsequent Job operations; the numeric
identifier is preferred. The Printer generates the Job numeric
identifier and URI based on its configured security policy and the
URI used by the Client in the Job Creation request.
For example, consider a Printer that supports both a communication
channel secured by the use of TLS (using HTTP over TLS with an
"https" schemed URI) and another open communication channel that is
not secured with TLS (using a simple "http" schemed URI). If a
Client submits a Job using the secure URI, the Printer assigns the
new Job a secure URI as well. If a Client were to submit a Job using
the open-channel URI, the Printer might assign the new Job an
open-channel URI. Clients SHOULD use the "printer-uri" and "job-id"
attributes to target a Job to avoid any ambiguity about the security
of the communication channel.
In addition, the Printer also populates the Job's "job-printer-uri"
attribute. This is a reference back to the Printer that created the
Job. If a Client only has access to a Job's "job-uri" identifier,
the Client can query the Job's "job-printer-uri" attribute in order
to determine which Printer created the Job. If the Printer supports
more than one URI, the Printer picks the one URI supplied by the
Client when creating the Job to build the value for and to populate
the Job's "job-printer-uri" attribute.
In addition to identifiers, IPP objects have names -- "printer-name"
for Printers and "job-name" for Jobs. An object name is not
guaranteed to be unique across all instances of all objects. A
Printer's name is chosen and set by an Administrator through some
mechanism outside the scope of this document. A Job's name can be
chosen and supplied by the Client submitting the Job. If the Client
does not supply a Job name, the Printer generates a name for the new
Job. In all cases, the name only has local meaning.
o Each Printer is identified by one or more URIs. The Printer's
"printer-uri-supported" attribute contains the URI(s).
o The Printer's "uri-security-supported" attribute identifies the
communication channel security protocols that have been configured
for the various Printer URIs (e.g., 'tls' or 'none').
o The Printer's "uri-authentication-supported" attribute identifies
the authentication mechanisms that have been configured for the
various Printer URIs (e.g., 'digest', 'none', etc.).
o Each Job is identified by a numeric identifier, which is a 32-bit
positive integer. The Job's "job-id" attribute contains the
Job ID. The Job ID is only unique within the context of the
Printer that created the Job.
o Each Job is also identified by a URI. The Job's "job-uri"
attribute contains the URI, although its use by Clients is
o Each Job has a "job-printer-uri" attribute, which contains the URI
of the Printer that was used to create the Job. This attribute is
used to determine the Printer that created a Job when given only
the URI for the Job. This linkage is necessary to determine the
languages, charsets, and operations that are supported on that Job
(the basis for such support comes from the creating Printer).
o Each Printer has a name, which is not necessarily unique. The
Administrator chooses and sets this name through some mechanism
outside the scope of this IPP/1.1 document. The Printer's
"printer-name" attribute contains the name.
o Each Job has a name, which is not necessarily unique. The Client
optionally supplies this name in the Job Creation request. If the
Client does not supply this name, the Printer generates a name for
the Job. The Job's "job-name" attribute contains the name.