4. IPP Operations
IPP objects (Printers, Jobs, etc.) support operations. An operation
consists of a request and a response. When a Client communicates
with a Printer or its Jobs, the Client issues an operation request to
the Printer URI and object's numeric identifier, if needed.
Operation requests and responses have parameters that identify the
operation. Operations also have attributes that affect the runtime
characteristics of the operation (the intended target, localization
information, etc.). These operation-specific attributes are called
"operation attributes" (as compared to object attributes such as
Printer attributes or Job attributes). Each request carries along
with it any operation attributes, object attributes, and/or Document
data required to perform the operation. Each request requires a
response from the object. Each response indicates success or failure
of the operation with a status-code as a response parameter. The
response contains any operation attributes, object attributes, and/or
status messages generated during the execution of the operation
This section describes the semantics of the IPP operations, both
requests and responses, in terms of the parameters, attributes, and
other data associated with each operation.
The Printer operations defined in this document are:
Print-Job (Section 4.2.1)
Print-URI (Section 4.2.2)
Validate-Job (Section 4.2.3)
Create-Job (Section 4.2.4)
Get-Printer-Attributes (Section 4.2.5)
Get-Jobs (Section 4.2.6)
Pause-Printer (Section 4.2.7)
Resume-Printer (Section 4.2.8)
Purge-Jobs (Section 4.2.9)
The Job operations defined in this document are:
Send-Document (Section 4.3.1)
Send-URI (Section 4.3.2)
Cancel-Job (Section 4.3.3)
Get-Job-Attributes (Section 4.3.4)
Hold-Job (Section 4.3.5)
Release-Job (Section 4.3.6)
Restart-Job (Section 4.3.7)
The Send-Document and Send-URI Job operations are used to add
Documents to an existing Job created using the Create-Job operation.
4.1. Common Semantics
All IPP operations require some common parameters and operation
attributes. These common elements and their semantic characteristics
are defined and described in more detail in the following sections.
4.1.1. Required Parameters
Every operation request contains the following REQUIRED parameters:
o a "version-number",
o an "operation-id",
o a "request-id", and
o the attributes that are REQUIRED for that type of request.
Every operation response contains the following REQUIRED parameters:
o a "version-number",
o a "status-code",
o the "request-id" that was supplied in the corresponding request,
o the attributes that are REQUIRED for that type of response.
The Encoding and Transport document [RFC8010] defines special rules
for the encoding of these parameters. All other operation elements
are represented using the more generic encoding rules for attributes
and groups of attributes.
4.1.2. Operation IDs and Request IDs
Each IPP operation request includes an identifying "operation-id"
value. Valid values are defined in the "operations-supported"
Printer attribute section (see Section 5.4.15). The Client specifies
which operation is being requested by supplying the correct
In addition, every invocation of an operation is identified by a
"request-id" value. For each request, the Client chooses the
"request-id", which MUST be an integer (possibly unique, depending on
Client requirements) in the range from 1 to 2**31 - 1 (inclusive).
This "request-id" allows Clients to manage multiple outstanding
requests. The receiving IPP object (Printer, Job, etc.) copies all
32 bits of the Client-supplied "request-id" attribute into the
response so that the Client can match the response with the correct
outstanding request, even if the "request-id" is out of range. If
the request is terminated before the complete "request-id" is
received, the IPP object rejects the request and returns a response
with a "request-id" of 0.
Note: In some cases, the transport protocol underneath IPP might be a
connection-oriented protocol that would make it impossible for a
Client to receive responses in any order other than the order in
which the corresponding requests were sent. In such cases, the
"request-id" attribute would not be essential for correct protocol
operation. However, in other transport mappings the operation
responses could come back in any order, in which case the
"request-id" is essential.
Operation requests and responses are both composed of groups of
attributes and/or Document data. The attribute groups are:
o Operation Attributes: These attributes are passed in the operation
and affect the IPP object's behavior while processing the
operation request, and they can affect other attributes or groups
of attributes. Some operation attributes describe the Document
data associated with the Print Job and are associated with new Job
objects; however, most operation attributes do not persist beyond
the life of the operation. The description of each operation
attribute includes conformance statements indicating which
operation attributes are REQUIRED and which are OPTIONAL for an
IPP object to support, as well as which attributes a Client MUST
supply in a request and an IPP object MUST supply in a response.
o Job Template Attributes: These attributes affect the processing of
a Job. A Client MAY supply Job Template attributes in a Job
Creation request, and the receiving object MUST be prepared to
receive all supported attributes. The Job object can later be
queried to find out what Job Template attributes were originally
requested in the Job Creation request, and such attributes are
returned in the response as Job object attributes. The Printer
object can be queried about its Job Template attributes to find
out what type of Job processing capabilities are supported and/or
what the default Job processing behaviors are, though such
attributes are returned in the response as Printer object
attributes. The "ipp-attribute-fidelity" operation attribute
affects processing of all Client-supplied Job Template attributes
-- see Section 22.214.171.124 and Appendix C for a full description of
"ipp-attribute-fidelity" and its relationship to other attributes.
o Job Object Attributes: These attributes are returned in response
to a query operation directed at a Job object.
o Printer Object Attributes: These attributes are returned in
response to a query operation directed at a Printer object.
o Unsupported Attributes: In a Job Creation request, the Client
supplies a set of operation and Job Template attributes. If any
of these attributes or their values are unsupported by the Printer
object, the Printer object SHOULD return the set of unsupported
attributes in the response. Section 4.1.7, Section 126.96.36.199, and
Appendix C give a full description of how Job Template attributes
supplied by the Client in a Job Creation request are processed by
the Printer object and how unsupported attributes are returned to
the Client. Because of extensibility, any IPP object might
receive a request that contains new or unknown attributes or
values for which it has no support. In such cases, the IPP object
processes what it can and returns the unsupported attributes in
the response. The Unsupported Attributes group is defined for all
operation responses for returning unsupported attributes that the
Client supplied in the request.
Later in this section, each operation is formally defined by
identifying the allowed and expected groups of attributes for each
request and response. The model identifies a specific order for each
group in each request or response, but the attributes within each
group can be in any order, unless specified otherwise.
The attributes within a group MUST be unique; if an attribute with
the same name occurs more than once, the group is malformed. Clients
MUST NOT submit such malformed requests, and Printers MUST NOT return
such malformed responses. If such a malformed request is submitted
to a Printer, the Printer MUST either (1) reject the request with the
'client-error-bad-request' status-code (RECOMMENDED -- see
Appendix B.1.4.1) or (2) process the request normally after selecting
only one of the attribute instances, depending on implementation.
Which attribute is selected when there are duplicate attributes
depends on implementation. The IPP Printer MUST NOT use the values
from more than one such duplicate attribute instance.
Each attribute definition includes the attribute's name followed by
the name of its attribute syntax(es) in parentheses. In addition,
each 'integer' attribute can be followed by the allowed range in
parentheses, (m:n), for values of that attribute. Each 'text' or
'name' attribute can be followed by the maximum size in octets in
parentheses, (size), for values of that attribute. For more details
on attribute syntax notation, see the descriptions of these attribute
syntaxes in Section 5.1.
Note: Document data included in the operation is not strictly an
attribute, but it is treated as a special attribute group for
ordering purposes. The only operations defined in this document that
support supplying the Document data within an operation request are
Print-Job and Send-Document. There are no operations defined in this
document whose responses include Document data.
Some operations are REQUIRED for IPP objects to support; the others
are OPTIONAL (see Section 6.2.2). Therefore, before using an
OPTIONAL operation, a Client SHOULD first use the REQUIRED
Get-Printer-Attributes operation to query the Printer's
"operations-supported" attribute in order to determine which OPTIONAL
operations are actually supported. The Client SHOULD NOT use an
OPTIONAL operation that is not supported. 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
(see Appendix B.1.5.2). An IPP object is non-conformant if it does
not support a REQUIRED operation.
4.1.4. Character Set and Natural Language Operation Attributes
Some Job and Printer attributes have values that are text strings and
names intended for human understanding rather than machine
understanding (see the 'text' and 'name' attribute syntax
descriptions in Section 5.1). The following sections describe two
special operation attributes called "attributes-charset" and
"attributes-natural-language" whose values are used when interpreting
other attributes using the 'text' and 'name' attribute syntaxes. For
Job Creation operations, the IPP Printer implementation also saves
these two attributes with the new Job object as Job Status
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 of the IPP message.
The "attributes-charset" attribute MUST be the first attribute in the
group, and the "attributes-natural-language" attribute MUST be the
second attribute in the group.
For the sake of brevity in this document, these operation attribute
descriptions are not repeated with every operation request and
response but instead have a reference back to this section.
188.8.131.52. Request Operation Attributes
The Client MUST supply and the Printer object MUST support the
following REQUIRED operation attributes in every IPP operation
This operation attribute identifies the charset (coded character
set and encoding method) used by any 'text' and 'name' attributes
that the Client is supplying in this request. It also identifies
the charset that the Printer object MUST use (if supported) for
all 'text' and 'name' attributes and status messages that the
Printer object returns in the response to this request. See
Sections 5.1.2 and 5.1.3 for the definitions of the 'text' and
'name' attribute syntaxes.
All Clients and IPP objects MUST support the 'utf-8' charset
[RFC3629] and MAY support additional charsets, provided that they
are registered with IANA [RFC2978] [IANA-CS]. If the Printer
object does not support the Client-supplied charset value, the
Printer object MUST reject the request, set the
"attributes-charset" to 'utf-8' in the response, and return the
'client-error-charset-not-supported' status-code and any 'text' or
'name' attributes using the 'utf-8' charset. The Printer MAY
return any attributes in the Unsupported Attributes group (see
Sections 4.1.7 and 184.108.40.206). The Printer object MUST indicate the
charset(s) supported as the values of the "charset-supported"
Printer attribute (see Section 5.4.18), so that the Client can
query to determine which charset(s) is supported.
Note to Client implementors: Since IPP objects are only required
to support the 'utf-8' charset, in order to maximize
interoperability with multiple IPP object implementations, a
Client SHOULD supply 'utf-8' in the "attributes-charset" operation
attribute, even though the Client is only passing and able to
present a simpler charset, such as US-ASCII [RFC20] or ISO-8859-1
[ISO8859-1]. Then the Client will have to filter out, perform
charset conversion on, or replace those characters that are
returned in the response that it cannot present to its user. On
the other hand, if both the Client and the IPP objects also
support a charset in common besides 'utf-8', the Client can use
that charset in order to avoid charset conversion or data loss.
See the 'charset' attribute syntax description in Section 5.1.8
for the syntax and semantic interpretation of the values of this
attribute and for example values.
This operation attribute identifies the natural language [RFC5646]
used by any 'text' and 'name' attributes that the Client is
supplying in this request. This attribute also identifies the
natural language that the Printer object SHOULD use for all 'text'
and 'name' attributes and status messages that the Printer object
returns in the response to this request. See the
'naturalLanguage' attribute syntax description in Section 5.1.9
for the syntax and semantic interpretation of the values of this
attribute and for example values.
There are no REQUIRED natural languages required for the Printer
object to support. However, the Printer's
"generated-natural-language-supported" attribute identifies the
natural languages supported by the Printer object and any
contained Jobs for all text strings generated by the IPP object.
A Client MAY query this attribute to determine which natural
language(s) is supported for generated messages.
For any of the attributes for which the Printer object generates
text, i.e., for the "job-state-message", "printer-state-message",
and status messages (see Section 4.1.6), the Printer object MUST
be able to generate these text strings in any of its supported
natural languages. If the Client requests a natural language that
is not supported, the Printer object MUST return these generated
messages in the Printer's configured natural language as specified
by the Printer's "natural-language-configured" attribute (see
For other 'text' and 'name' attributes supplied by the Client,
authentication system, Operator, Administrator, or manufacturer
(i.e., for "job-originating-user-name", "printer-name" (name),
"printer-location" (text), "printer-info" (text), and
"printer-make-and-model" (text)), the Printer object is only
required to support the configured natural language of the Printer
identified by the Printer's "natural-language-configured"
attribute, though support of additional natural languages for
these attributes is permitted.
For any 'text' or 'name' attribute in the request that is in a
different natural language than the value supplied in the
"attributes-natural-language" operation attribute, the Client MUST
use the Natural Language Override mechanism (see Sections 220.127.116.11
and 18.104.22.168) for each such attribute value supplied. The Client
MAY use the Natural Language Override mechanism redundantly, i.e.,
use it even when the value is in the same natural language as the
value supplied in the "attributes-natural-language" operation
attribute of the request.
The IPP object MUST accept any natural language and any Natural
Language Override, whether the IPP object supports that natural
language or not (and independent of the value of the
"ipp-attribute-fidelity" operation attribute). That is, the IPP
object accepts all Client-supplied values no matter what the
values are in the Printer's "generated-natural-language-supported"
attribute. That attribute,
"generated-natural-language-supported", only applies to generated
messages, not Client-supplied messages. The IPP object MUST
remember that natural language for all Client-supplied attributes,
and when returning those attributes in response to a query, the
IPP object MUST indicate that natural language.
Each value whose attribute syntax type is 'text' or 'name' (see
Sections 5.1.2 and 5.1.3) has an Associated Natural Language.
This document does not specify how this association is stored in a
Printer or Job object. When such a value is encoded in a request
or response, the natural language is either implicit or explicit:
* In the implicit case, the value contains only the text/name
value, and the language is specified by the
"attributes-natural-language" operation attribute in the
request or response (see Sections 22.214.171.124 and 126.96.36.199).
* In the explicit case (also known as the Natural Language
Override case), the value contains both the language and the
text/name value (see Sections 188.8.131.52 and 184.108.40.206).
For example, the "job-name" attribute MAY be supplied by the
Client in a Job Creation request. The text value for this
attribute will be in the natural language identified by the
"attribute-natural-language" attribute, or if different, as
identified by the Natural Language Override mechanism. If
supplied, the IPP object will use the value of the "job-name"
attribute to populate the Job's "job-name" attribute. Whenever
any Client queries the Job's "job-name" attribute, the IPP object
returns the attribute as stored and uses the Natural Language
Override mechanism to specify the natural language, if it is
different from that reported in the "attributes-natural-language"
operation attribute of the response. The IPP object MAY use the
Natural Language Override mechanism redundantly, i.e., use it even
when the value is in the same natural language as the value
supplied in the "attributes-natural-language" operation attribute
of the response.
An IPP object MUST NOT reject a request based on a supplied
natural language in an "attributes-natural-language" operation
attribute or in any attribute that uses the Natural Language
Note: Supplying 'text' or 'name' attributes with an incompatible
combination of natural language and charset can cause undesired
behavior. For example, suppose a Printer supports charsets
'utf-8', 'iso-8859-1', and 'iso-8859-7'. Suppose also that it
supports natural languages 'en' (English), 'fr' (French), and 'el'
(Greek). Although the Printer supports the charset 'iso-8859-1'
and natural language 'el', it probably does not support the
combination of Greek text strings using the 'iso-8859-1' charset.
The Printer handles this apparent incompatibility differently,
depending on the context in which it occurs:
* In a Job Creation request: If the Client supplies a 'text' or
'name' attribute (for example, the "job-name" operation
attribute) that uses an apparently incompatible combination, it
is a Client choice that does not affect the Printer or its
correct operation. Therefore, the Printer simply accepts the
Client-supplied value, stores it with the Job, and responds
back with the same combination whenever the Client (or any
Client) queries for that attribute.
* In a query-type operation, like Get-Printer-Attributes: If the
Client requests an apparently incompatible combination, the
Printer responds (as described in Section 220.127.116.11) using the
Printer's configured natural language rather than the natural
language requested by the Client.
In either case, the Printer does not reject the request because of
the apparent incompatibility. The potential incompatible
combination of charset and natural language can occur either at
the global operation level or at the Natural Language Override
attribute-by-attribute level. In addition, since the response
always includes explicit charset and natural language information,
there is never any question or ambiguity in how the Client
interprets the response.
18.104.22.168. Response Operation Attributes
The Printer MUST supply and the Client MUST support the following
REQUIRED operation attributes in every IPP/1.1 operation response:
This operation attribute identifies the charset used by any 'text'
and 'name' attributes that the Printer object is returning in this
response. The value in this response MUST be the same value as
the "attributes-charset" operation attribute supplied by the
Client in the request. If this is not possible (i.e., the charset
requested is not supported), the request would have been rejected.
See "attributes-charset" described in Section 22.214.171.124 above.
If the Printer object supports more than just the 'utf-8' charset,
the Printer object MUST be able to perform code conversion between
each of the charsets supported on a "highest fidelity possible"
basis in order to return the 'text' and 'name' attributes in the
charset requested by the Client. However, some information loss
can occur during the charset conversion, depending on the charsets
involved. For example, depending on implementation, the Printer
object can convert from a UTF-8 'a' to a US-ASCII 'a' (with no
loss of information); from an ISO Latin 1 CAPITAL LETTER A WITH
ACUTE ACCENT to US-ASCII 'A' (losing the accent); or from a UTF-8
Japanese Kanji character to some ISO Latin 1 error character
indication such as '?', a decimal code equivalent, or the absence
of a character.
Whether an implementation that supports more than one charset
stores the data in the charset supplied by the Client or performs
code conversion to one of the other supported charsets depends on
implementation. The strategy should try to minimize loss of
information during code conversion. On each response, such an
implementation converts from its internal charset to that
This operation attribute identifies the natural language used by
any 'text' and 'name' attributes that the IPP object is returning
in this response. Unlike the "attributes-charset" operation
attribute, the IPP object MAY return the natural language of the
Job object or the Printer's configured natural language as
identified by the Printer's "natural-language-configured"
attribute, rather than the natural language supplied by the
Client. For any 'text' or 'name' attribute or status message in
the response that is in a different natural language than the
value returned in the "attributes-natural-language" operation
attribute, the IPP object MUST use the Natural Language Override
mechanism (see Sections 126.96.36.199 and 188.8.131.52) on each attribute
value returned. The IPP object MAY use the Natural Language
Override mechanism redundantly, i.e., use it even when the value
is in the same natural language as the value supplied in the
"attributes-natural-language" operation attribute of the response.
4.1.5. Operation Targets
All IPP operations are directed at IPP objects. For Printer
operations, the operation is always directed at a Printer object
using one of its URIs, i.e., one of the values in the Printer's
"printer-uri-supported" attribute. Even if the Printer object
supports more than one URI, the Client supplies only one URI as the
target of the operation. The Client identifies the target object by
supplying the correct URI in the "printer-uri" operation attribute.
For Job operations, the operation is directed at either:
o The Printer object that created the Job object using the Printer
object's URI and the Job's numeric identifier (Job ID). Since the
Printer object that created the Job object generated the Job ID,
it MUST be able to correctly associate the Client-supplied Job ID
with the correct Job object. The Client supplies the Printer's
URI in the "printer-uri" operation attribute and the Job ID in the
"job-id" operation attribute.
o The Job object itself using the Job's URI. In this case, the
Client identifies the target object by supplying the correct URI
in the "job-uri" (uri) operation attribute (Section 5.3.2).
Clients SHOULD send the "printer-uri" and "job-id" operation
attributes in Job operations.
If the operation is directed at the Job object directly using the
Job's URI, the Client MUST NOT include the redundant "job-id"
The operation target attributes are REQUIRED operation attributes
that are included in every operation request. Like the charset and
natural language attributes (see Section 4.1.4), the operation target
attributes are specially ordered operation attributes. In all cases,
the operation target attributes immediately follow the
"attributes-charset" and "attributes-natural-language" attributes
within the Operation Attributes group; however, the specific ordering
rules are as follows:
o In the case where there is only one operation target attribute
(i.e., either only the "printer-uri" attribute or only the
"job-uri" attribute), that attribute MUST be the third attribute
in the Operation Attributes group.
o In the case where Job operations use two operation target
attributes (i.e., the "printer-uri" and "job-id" attributes), the
"printer-uri" attribute MUST be the third attribute and the
"job-id" attribute MUST be the fourth attribute.
In all cases, the target URIs contained within the body of IPP
operation requests and responses MUST be in absolute format rather
than relative format (a relative URL identifies a resource with the
scope of the HTTP server, but does not include scheme, host,
The following rules apply to the use of port numbers in URIs that
identify IPP objects:
1. If the URI scheme allows the port number to be explicitly
included in the URI string, and a port number is specified within
the URI, then that port number MUST be used by the Client to
contact the IPP object.
2. If the URI scheme allows the port number to be explicitly
included in the URI string, and a port number is not specified
within the URI, then the default port number implied by that URI
scheme MUST be used by the Client to contact the IPP object.
3. If the URI scheme does not allow an explicit port number to be
specified within the URI, then the default port number implied by
that URI MUST be used by the Client to contact the IPP object.
Note: "Internet Printing Protocol/1.1: IPP URL Scheme" [RFC3510] and
"Internet Printing Protocol (IPP) over HTTPS Transport Binding and
the 'ipps' URI Scheme" [RFC7472] define the mapping of IPP onto HTTP
and HTTPS, respectively, and define and register a default port
4.1.6. Operation Response Status-Code Values and Status Messages
Every operation response includes a REQUIRED "status-code" parameter,
SHOULD include the "status-message" operation attribute, and MAY
include the "detailed-status-message" operation attribute. The
Print-URI and Send-URI response MAY also include the
"document-access-error" operation attribute.
184.108.40.206. "status-code" (type2 enum)
The REQUIRED "status-code" parameter provides information on the
processing of a request.
The status-code is intended for use by automata. A Client
implementation of IPP SHOULD convert status-code values into any
localized message that has semantic meaning to the End User.
The "status-code" value is a numeric value that has semantic meaning.
The "status-code" syntax is similar to a "type2 enum" (see
Section 5.1 ("Attribute Syntaxes")), except that values can range
only from 0x0000 to 0x7fff. Appendix B describes and assigns the
status-code values, and suggests a corresponding status message for
each status-code for use by the Client when the user's natural
language is English.
If the Printer performs an operation with no errors and it encounters
no problems, it MUST return the status-code 'successful-ok' in the
response. See Appendix B.
If the Client supplies unsupported values for the following
parameters or operation attributes, the Printer object MUST reject
the operation, MAY return the unsupported attribute value in the
Unsupported Attributes group, and MUST return the indicated
| Parameter/Attribute | Status-Code |
| version-number | server-error-version-not-supported |
| operation-id | server-error-operation-not-supported |
| attributes-charset | client-error-charset-not-supported |
| compression | client-error-compression-not-supported |
| document-format | client-error-document-format-not-supported |
| document-uri | client-error-uri-scheme-not-supported, |
| | client-error-document-access-error |
Table 1: Status-Code Values for All Requests
If the Client supplies unsupported values for other attributes, or
unsupported attributes, the Printer returns the status-code defined
in Section 4.1.7 ("Unsupported Attributes").
220.127.116.11. "status-message" (text(255))
The RECOMMENDED "status-message" operation attribute provides a short
textual description of the status of the operation. The
"status-message" attribute's syntax is "text(255)", so the maximum
length is 255 octets (see Section 5.1.2). The status message is
intended for the human End User. If a response does include a
"status-message" attribute, an IPP Client can examine or display the
messages in some implementation-specific manner. The
"status-message" attribute is especially useful for a later version
of a Printer to return as supplemental information for the human
user, to accompany a status-code that an earlier version of a Client
might not understand.
If the Printer supports the "status-message" operation attribute, it
MUST be able to generate this message in any of the natural languages
identified by the Printer's "generated-natural-language-supported"
attribute and MUST honor any supported value for the
"attributes-natural-language" operation attribute (Section 18.104.22.168)
of the Client request. Appendix B suggests the text for the status
message returned by the Printer for use with the English natural
As described in Section 22.214.171.124, for any returned 'text' attribute,
if there is a choice for generating this message, the Printer uses
the natural language indicated by the value of
"attributes-natural-language" in the Client request, if supported;
otherwise, the Printer uses the value in the Printer's own
If the Printer supports the "status-message" operation attribute, it
SHOULD use the REQUIRED 'utf-8' charset to return a status message
for the following error status-code values (see Appendix B):
'server-error-version-not-supported'. In this case, it MUST set the
value of the "attributes-charset" operation attribute to 'utf-8' in
the error response.
126.96.36.199. "detailed-status-message" (text(MAX))
The OPTIONAL "detailed-status-message" operation attribute provides
additional more-detailed technical and implementation-specific
information about the operation for Administrators or other
experienced technical people. The "detailed-status-message"
attribute's syntax is "text(MAX)", so the maximum length is
1023 octets (see Section 5.1.2). If the Printer supports the
"detailed-status-message" operation attribute, the Printer SHOULD
localize the message, unless such localization would obscure the
technical meaning of the message. Clients MUST NOT attempt to parse
the value of this attribute. See the "document-access-error"
operation attribute (Section 188.8.131.52) for additional errors that a
program can process.
184.108.40.206. "document-access-error" (text(MAX))
This OPTIONAL operation attribute provides additional information
about any Document access errors encountered by the Printer before it
returned a response to the Print-URI (Section 4.2.2) or Send-URI
(Section 4.3.2) operation. For errors in the protocol identified by
the URI scheme in the "document-uri" operation attribute, such as
'http:' or 'ftp:', the error code is returned in parentheses,
followed by the URI. For example:
Most Internet protocols use decimal error codes (unlike IPP), so the
ASCII error code representation is in decimal.
4.1.7. Unsupported Attributes
The Unsupported Attributes group contains attributes that are not
supported by the operation. This group is primarily for the Job
Creation operations, but all operations can return this group.
A Printer MUST include an Unsupported Attributes group in a response
if the status-code is one of the following:
If the status-code is one of the four specified in the preceding
paragraph, the Unsupported Attributes group MUST contain all of those
attributes and only those attributes that are:
a. an operation or Job Template attribute supplied in the request,
b. unsupported by the Printer. See below for details on the three
categories of "unsupported" attributes.
If the status-code is one of those in Table 1 in Section 220.127.116.11, the
OPTIONAL Unsupported Attributes group contains the unsupported
parameter or attribute indicated in that table.
If the Printer is not returning any unsupported attributes in the
response, the Printer SHOULD omit the Unsupported Attributes group
rather than sending an empty group. However, a Client MUST be able
to accept an empty group.
Unsupported attributes fall into three categories:
1. The Printer does not support the supplied attribute (no matter
what the attribute syntax or value).
2. The Printer does support the attribute, but it does not support
some or all of the particular attribute syntaxes or values
supplied by the Client, i.e., the Printer does not have those
attribute syntaxes or values in its corresponding "xxx-supported"
3. The Printer does support the attributes and values supplied, but
the particular values are in conflict with one another, because
they violate a constraint, such as not being able to staple
In the case of an unsupported attribute name, the Printer returns the
Client-supplied attribute with a substituted value of 'unsupported'.
This value's syntax type is "out-of-band", and its encoding is
defined by special rules for "out-of-band" values in the Encoding and
Transport document [RFC8010]. Its value indicates no support for the
attribute itself -- see the beginning of Section 5.1 in this
In the case of a supported attribute with one or more unsupported
attribute syntaxes or values, the Printer simply returns the
Client-supplied attribute with the unsupported attribute syntaxes or
values as supplied by the Client. This indicates support for the
attribute but no support for that particular attribute syntax or
value. If the Client supplies a multi-valued attribute with more
than one value and the Printer supports the attribute but only
supports a subset of the Client-supplied attribute syntaxes or
values, the Printer MUST return only those attribute syntaxes or
values that are unsupported.
In the case of two (or more) supported attribute values that are in
conflict with one another (although each is supported independently,
the values conflict when requested together within the same Job), the
Printer MUST return all the values that it ignores or substitutes to
resolve the conflict but not any of the values that it is still
using. The choice for exactly how to resolve the conflict is
implementation dependent. See Section 18.104.22.168 and Appendix C. See
the Implementor's Guides [RFC3196] [PWG5100.19] for examples.
Each operation request and response carries with it a
"version-number" parameter. Each value of the "version-number"
parameter is in the form "X.Y" where X is the major version number
and Y is the minor version number. By including a version number in
the Client request, it allows the Client to identify which version of
IPP it is interested in using, i.e., the version whose conformance
requirements the Client can depend upon the Printer to meet.
If the IPP object does not support that major version number supplied
by the Client, i.e., the "major version number" portion of the
"version-number" parameter does not match any of the values of the
Printer's "ipp-versions-supported" attribute (see Section 5.4.14),
the object MUST respond with a status-code of
'server-error-version-not-supported' along with the closest version
number that is supported (see Appendix B.1.5.4). If the major
version number is supported but the minor version number is not, the
IPP object SHOULD accept the request and attempt to perform it (or
reject the request if the operation is not supported); otherwise, it
rejects the request and returns the
'server-error-version-not-supported' status-code. In all cases, the
IPP object MUST return the "version-number" value that it supports
that is closest to the version number supplied by the Client in the
There is no version negotiation per se. However, if a Client has
received a 'server-error-version-not-supported' status-code from an
IPP object, the Client SHOULD try again with a different version
number. A Client MAY also determine the versions supported either
from a directory that conforms to Appendix D or by querying the
Printer's "ipp-versions-supported" attribute (see Section 5.4.14) to
determine which versions are supported.
An IPP/1.1 object implementation MUST support version '1.1', i.e.,
meet the conformance requirements for IPP/1.1 as specified in this
document and [RFC8010]. IPP implementations SHOULD accept any
request with the major version '1' or '2', or reject the request if
the operation is not supported.
There is only one notion of "version number" that covers both IPP
Model and IPP protocol changes. Changes to the major version number
of the Model and Semantics document can indicate structural or
syntactic changes that make it impossible for older versions of IPP
Clients and Printers to correctly parse and correctly process the new
or changed attributes, operations, and responses. If the major
version number changes, the minor version number is set to zero. As
an example, adding the REQUIRED "ipp-attribute-fidelity" attribute to
version '1.1' (if it had not been part of version '1.0') would have
required a change to the major version number, since an IPP/1.0
Printer would not have processed a request with the correct semantics
that contained the "ipp-attribute-fidelity" attribute that it did not
know about. Items that might affect the changing of the major
version number include any changes to the Model and Semantics
document (this document) or the Encoding and Transport document
[RFC8010] itself, such as:
o reordering of ordered attributes or attribute sets
o changes to the syntax of existing attributes
o adding REQUIRED (for an IPP object to support) Operation
o adding values to existing REQUIRED operation attributes
o adding REQUIRED operations
Changes to the minor version number indicate the addition of new
features, attributes, and attribute values that might not be
understood by all IPP objects but that can be ignored if not
understood. Items that might affect the changing of the minor
version number include any changes to the model objects and
attributes but not the encoding and transport rules [RFC8010] (except
adding attribute syntaxes). Examples of such changes are:
o grouping all extensions not included in a previous version into a
o adding new attribute values
o adding new object attributes
o adding OPTIONAL (for an IPP object to support) operation
attributes (i.e., those attributes that an IPP object can ignore
without confusing Clients)
o adding OPTIONAL (for an IPP object to support) Operation
Attributes groups (i.e., those attributes that an IPP object can
ignore without confusing Clients)
o adding new attribute syntaxes
o adding OPTIONAL operations
o changing Job attributes or Printer attributes from OPTIONAL to
REQUIRED or vice versa
o adding OPTIONAL attribute syntaxes to an existing attribute
The encoding [RFC8010] of the "version-number" parameter MUST NOT
change over any version number (either major or minor). This rule
guarantees that all future versions will be backwards compatible with
all previous versions (at least for checking the "version-number"
parameter). In addition, any protocol elements (attributes, error
codes, tags, etc.) that are not carried forward from one version to
the next are DEPRECATED so that they can never be reused with new
Implementations that support a certain version SHOULD support all
previous Standards Track versions. As each new version is defined
(through the release of a new IPP specification document), that
version will specify which previous versions MUST and which versions
SHOULD be supported in compliant implementations.
4.1.9. Job Creation Operations
In order to "submit a Print Job" and create a new Job, a Client
issues a Job Creation request. A Job Creation request is any one of
the following three operation requests:
o The Print-Job Request: A Client that wants to submit a Print Job
with only a single Document can use the Print-Job operation. The
operation allows for the Client to "push" the Document data to the
Printer by including the Document data in the request itself.
Note that Clients SHOULD instead use the Create-Job and
Send-Document requests, if supported by the Printer, since they
allow for Job monitoring and control during submission of the
o The Print-URI Request: A Client that wants to submit a Print Job
with only a single Document (where the Printer "pulls" the
Document data instead of the Client "pushing" the data to the
Printer) uses the Print-URI operation. In this case, the Client
includes in the request only a URI reference to the Document data
(not the Document data itself).
o The Create-Job Request: A Client that wants to submit a Print Job
with zero or more Documents uses the Create-Job operation. This
operation is followed by an arbitrary number of Send-Document
and/or Send-URI operations, each creating another Document for the
newly created Job. The Send-Document operation includes the
Document data in the request (the Client "pushes" the Document
data to the Printer), and the Send-URI operation includes only a
URI reference to the Document data in the request (the Printer
"pulls" the Document data from the referenced location). The last
Send-Document or Send-URI request for a given Job includes a
"last-document" operation attribute set to 'true' indicating that
this is the last request.
Throughout this document, the term "Job Creation request" is used to
refer to any of these three operation requests.
A Create-Job operation followed by only one Send-Document operation
is semantically equivalent to a Print-Job operation; however, the
Client SHOULD use the Create-Job and Send-Document operations (when
supported) for all Jobs with a single Document to allow for reliable
Job control and monitoring. Print-Job is a REQUIRED operation (all
implementations MUST support it), whereas Create-Job is a RECOMMENDED
operation and hence some implementations might not support it.
Job submission time is the point in time when a Client issues a Job
Creation request. The initial state of every Job is the 'pending',
'pending-held', or 'processing' state (see Section 5.3.7). When the
Printer begins processing the Print Job, the Job's state moves to
'processing'. This is known as Job processing time.
At Job submission time and at the time a Validate-Job operation is
received, the Printer MUST do the following:
1. Process the Client-supplied attributes and either accept or
reject the request
2. Validate the syntax of and support for the scheme of any
At Job submission time, the Printer MUST validate whether the
supplied attributes, attribute syntaxes, and values are supported by
matching them with the Printer's corresponding "xxx-supported"
attributes. See Section 4.1.7 for details. See the Implementor's
Guides [RFC3196] [PWG5100.19] for guidance on processing Job Creation
At Job submission time, the Printer MAY perform the validation checks
reserved for Job processing time, such as:
1. Validating the format of the Document data
2. Validating the actual contents of any Client-supplied URI
(resolve the reference and follow the link to the Document data)
At Job submission time, these additional Job processing time
validation checks are essentially useless, since they require
actually parsing and interpreting the Document data, are not
guaranteed to be 100% accurate, and MUST be done, yet again, at Job
processing time. Also, in the case of a URI, checking for
availability at Job submission time does not guarantee availability
at Job processing time. In addition, at Job processing time, the
Printer might discover any of the following conditions that were not
detectable at Job submission time:
o runtime errors in the Document data,
o nested Document data that is in an unsupported format,
o the URI reference is no longer valid (i.e., the server hosting the
Document might be down), or
o any other Job processing error.
At Job submission time, a Printer, especially a non-spooling Printer,
MAY accept Jobs for which it does not have enough space. In such a
situation, a Printer MAY stop reading data from a Client for an
indefinite period of time. A Client MUST be prepared for a write
operation to block for an indefinite period of time (see Section 6.1
("Client Conformance Requirements")).
When a Printer has too little space for starting a new Job, it MAY
reject a new Job Creation request. In this case, a Printer MUST
return a response (in reply to the rejected request) with a
status-code of 'server-error-busy' (see Appendix B.1.5.8), and it MAY
close the connection before receiving all bytes of the operation. A
Printer SHOULD indicate that it is temporarily unable to accept Jobs
by setting the 'spool-space-full' value in its
"printer-state-reasons" attribute and removing the value when it can
accept another Job (see Section 5.4.12).
When receiving a 'server-error-busy' status-code in an operation
response, a Client MUST be prepared for the Printer to close the
connection before the Client has sent all of the data (especially for
the Print-Job operation). A Client MUST be prepared to keep
submitting a Job Creation request until the Printer accepts the Job
At Job processing time, since the Printer has already responded with
a successful status-code in the response to the Job Creation request,
if the Printer detects an error, the Printer is unable to inform the
End User of the error with an operation status-code. In this case,
the Printer, depending on the error, can set the Job's "job-state",
"job-state-reasons", and/or "job-state-message" attributes to the
appropriate value(s) so that later queries can report the correct Job
Note: Asynchronous notification of events is defined in "Internet
Printing Protocol (IPP): Event Notifications and Subscriptions"