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 4.2.1.1 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 4.2.1.2, 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.

4.1.4.1.  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 4.2.1.2).  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 5.1.2.2
      and 5.1.3.2) 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 5.1.2.1 and 5.1.3.1).

      *  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 5.1.2.2 and 5.1.3.2).

      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 4.1.4.2) 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.

4.1.4.2.  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 4.1.4.1 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 5.1.2.2 and 5.1.3.2) 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.

4.1.6.1.  "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").

4.1.6.2.  "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 4.1.4.1)

   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 4.1.4.1, 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.

4.1.6.3.  "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 4.1.6.4) for additional errors that a
   program can process.

4.1.6.4.  "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 4.1.6.1, 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 4.2.1.2 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].