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 request. 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, and 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 "operation-id" value. 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. 4.1.3. Attributes 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 attributes. 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 request: "attributes-charset" (charset): 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. "attributes-natural-language" (naturalLanguage): 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 Section 5.4.19).
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 Override. 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: "attributes-charset" (charset): 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 requested.
"attributes-natural-language" (naturalLanguage): 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" operation attribute. 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, or port). 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 number. 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 status-code: +---------------------+---------------------------------------------+ | 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 language. 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 "natural-language-configured" attribute. 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): 'client-error-bad-request', 'client-error-charset-not-supported', 'server-error-internal-error', 'server-error-operation-not-supported', and '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: (404) http://www.example.com/filename.pdf
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: 'successful-ok-ignored-or-substituted-attributes', 'successful-ok-conflicting-attributes', 'client-error-attributes-or-values-not-supported', or 'client-error-conflicting-attributes'. 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, and 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" attribute.
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 transparencies. 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 document. 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. 4.1.8. Versions 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 request. 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 Attributes groups
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 new version 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 semantics.
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 Document data. 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 Client-supplied URI 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 requests. 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 Creation request. 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 status. Note: Asynchronous notification of events is defined in "Internet Printing Protocol (IPP): Event Notifications and Subscriptions" [RFC3995].