RFC 8011
Internet Printing Protocol/1.1: Model and Semantics
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 implementations.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 Device.
2.3. Model Terminology
2.3.1. Administrator
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 [RFC2567].2.3.2. Attributes
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 Section 4. 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 the Printer.2.3.2.1. 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.2.3.2.2. 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.2.3.2.3. 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.
2.3.2.4. 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 [RFC2567].2.3.4. Impression
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.2.3.7. Keyword
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.2.3.9. Operator
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.2.3.10. Set
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 Sets.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"
attribute.
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
and value.
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 "ipp-attribute-fidelity"). 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 Printer.
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.2.4. Abbreviations
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 [PWG5100.12]) 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
Section 5.2)
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
Section 5.4)
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
writer.
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
Devices
3a. The associated Output Devices are or are not capable of
spooling Jobs
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).
Legend:
##### 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
embedded Printer:
Output Device
+---------------+
O +--------+ | ########### |
/|\ | Client |------------IPP------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+
hosted Printer:
+---------------+
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 in detail. 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 Section 5.3) 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 Section 3.4). 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 reference.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" Printer attribute. 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 attributes. 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.
To summarize:
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
DEPRECATED.
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.
(page 29 continued on part 3)
