tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 8011

 
 
 

Internet Printing Protocol/1.1: Model and Semantics

Part 12 of 12, p. 200 to 221
Prev Section

 


prevText      Top      ToC       Page 200 
Appendix B.  Status-Code Values and Suggested Status-Code Messages

   This section defines status-code enum keywords and values that are
   used to provide semantic information on the results of an operation
   request.  Each operation response MUST include a status-code.  The
   response MAY also contain a status message that provides a short
   textual description of the status.  The status-code is intended for
   use by automata, and the status message is intended for the human
   End User.

   The prefix of the status keyword defines the class of response as
   follows:

   "informational" - Request received, continuing process

   "successful" - The action was successfully received, understood, and
   accepted

   "redirection" - Further action is taken in order to complete the
   request

   "client-error" - The request contains bad syntax or cannot be
   fulfilled

   "server-error" - The IPP object failed to fulfill an apparently valid
   request

   As with type2 enums, IPP status-code values are extensible.
   Regardless of whether all status-code values are recognized, IPP
   Clients MUST understand the class of any status-code, as indicated by
   the prefix, and treat any unrecognized response as being equivalent
   to the first status-code of that class, with the exception that an
   unrecognized response MUST NOT be cached.  For example, if an
   unrecognized status-code of 'client-error-xxx-yyy' is received by the
   Client, it can safely assume that there was something wrong with its
   request and treat the response as if it had received a
   'client-error-bad-request' status-code.  The name of the enum is the
   suggested status message for US English.

   See [PWG5100.19] for guidelines on presenting status messages to
   End Users.

Top      Up      ToC       Page 201 
   The status-code values range from 0x0000 to 0x7fff.  The value ranges
   for each status-code class are as follows:

   "successful" - 0x0000 to 0x00ff

   "informational" - 0x0100 to 0x01ff

   "redirection" - 0x0300 to 0x03ff

   "client-error" - 0x0400 to 0x04ff

   "server-error" - 0x0500 to 0x05ff

   The top half (128 values) of each range (0x0n80 to 0x0nff, for n = 0
   to 5) is reserved for vendor use within each status-code class.
   Values 0x0600 to 0x7fff are reserved for future assignment by
   Standards Track documents and MUST NOT be used.

B.1.  Status-Code Values

   Each status-code is described below.  Appendix B.2 contains a table
   that indicates which status-code values apply to which operations.
   The Implementor's Guides [RFC3196] [PWG5100.19] provide guidance for
   processing IPP attributes for all operations, including status-code
   values.

B.1.1.  Informational

   This class of status-code values indicates a provisional response and
   is to be used for informational purposes only.

   There are no values defined in this document for this class of
   status-code values.

B.1.2.  Successful Status-Code Values

   This class of status-code values indicates that the Client's request
   was successfully received, understood, and accepted.

B.1.2.1.  successful-ok (0x0000)

   The request has succeeded, and no request attributes were substituted
   or ignored.  In the case of a response to a Job Creation request, the
   'successful-ok' status-code indicates that the request was
   successfully received and validated, and that the Job object has been
   created; it does not indicate that the Job has been processed.  The
   transition of the Job object into the 'completed' state is the only
   indicator that the Job has been printed.

Top      Up      ToC       Page 202 
B.1.2.2.  successful-ok-ignored-or-substituted-attributes (0x0001)

   The request has succeeded, but some supplied (1) attributes were
   ignored or (2) unsupported values were substituted with supported
   values or were ignored in order to perform the operation without
   rejecting it.  Unsupported attributes, attribute syntaxes, or values
   MUST be returned in the Unsupported Attributes group of the response
   for all operations.  There is an exception to this rule for the query
   operations Get-Printer-Attributes, Get-Jobs, and Get-Job-Attributes
   for the "requested-attributes" operation attribute only.  When the
   supplied values of the "requested-attributes" operation attribute are
   requesting attributes that are not supported, the IPP object SHOULD
   return the "requested-attributes" operation attribute in the
   Unsupported Attributes group of the response (with the unsupported
   values only).  See Sections 4.1.7 and 4.2.1.2.

B.1.2.3.  successful-ok-conflicting-attributes (0x0002)

   The request has succeeded, but some supplied attribute values
   conflicted with the values of other supplied attributes.  Either
   (1) these conflicting values were substituted with (supported) values
   or (2) the attributes were removed in order to process the Job
   without rejecting it.  Attributes or values that conflict with other
   attributes and have been substituted or ignored MUST be returned in
   the Unsupported Attributes group of the response for all operations
   as supplied by the Client.  See Sections 4.1.7 and 4.2.1.2.

B.1.3.  Redirection Status-Code Values

   This class of status-code values indicates that further action needs
   to be taken to fulfill the request.

   There are no values defined in this document for this class of
   status-code values.

B.1.4.  Client Error Status-Code Values

   This class of status-code values is intended for cases in which the
   Client seems to have erred.  The IPP object SHOULD return a message
   containing an explanation of the error situation and whether it is a
   temporary or permanent condition.

Top      Up      ToC       Page 203 
B.1.4.1.  client-error-bad-request (0x0400)

   The request could not be understood by the IPP object due to
   malformed syntax (such as the value of a fixed-length attribute whose
   length does not match the prescribed length for that attribute -- see
   the Implementor's Guides [RFC3196] [PWG5100.19]).  The IPP
   application SHOULD NOT repeat the request without modifications.

B.1.4.2.  client-error-forbidden (0x0401)

   The IPP object understood the request but is refusing to fulfill it.
   Additional authentication information or authorization credentials
   will not help, and the request SHOULD NOT be repeated.  This
   status-code is commonly used when the IPP object does not wish to
   reveal exactly why the request has been refused or when no other
   response is applicable.

B.1.4.3.  client-error-not-authenticated (0x0402)

   The request requires user authentication.  The IPP Client can repeat
   the request with suitable authentication information.  If the request
   already included authentication information, then this status-code
   indicates that authorization has been refused for those credentials.
   If this response contains the same challenge as the prior response
   and the user agent has already attempted authentication at least
   once, then the response message can contain relevant diagnostic
   information.  This status-code reveals more information than
   'client-error-forbidden'.

B.1.4.4.  client-error-not-authorized (0x0403)

   The requester is not authorized to perform the request.  Additional
   authentication information or authorization credentials will not
   help, and the request SHOULD NOT be repeated.  This status-code is
   used when the IPP object wishes to reveal that the authentication
   information is understandable; however, the requester is explicitly
   not authorized to perform the request.  This status-code reveals more
   information than 'client-error-forbidden' and
   'client-error-not-authenticated'.

B.1.4.5.  client-error-not-possible (0x0404)

   This status-code is used when the request is for something that
   cannot happen.  For example, there might be a request to cancel a Job
   that has already been canceled or aborted by the system.  The IPP
   Client SHOULD NOT repeat the request.

Top      Up      ToC       Page 204 
B.1.4.6.  client-error-timeout (0x0405)

   The Client did not produce a request within the time that the IPP
   object was prepared to wait.  For example, a Client issued a
   Create-Job operation and then, after a long period of time, issued a
   Send-Document operation; this error status-code was returned in
   response to the Send-Document request (see Section 4.3.1).  The IPP
   object might have been forced to clean up resources that had been
   held for the waiting additional Documents.  The IPP object was forced
   to close the Job, since the Client took too long.  The Client
   SHOULD NOT repeat the request without modifications.

B.1.4.7.  client-error-not-found (0x0406)

   The IPP object has not found anything matching the request URI.  No
   indication is given of whether the condition is temporary or
   permanent.  For example, a Client with an old reference to a Job
   (a URI) tries to cancel the Job; however, in the meantime the Job
   might have been completed and all record of it at the Printer has
   been deleted.  This status-code, 'client-error-not-found', is
   returned indicating that the referenced Job cannot be found.  This
   error status-code is also used when a Client supplies a URI as a
   reference to the Document data in either a Print-URI or Send-URI
   operation but the Document cannot be found.

   In practice, an IPP application should avoid a "not found" situation
   by first querying and presenting a list of valid Printer URIs and Job
   URIs to the End User.

B.1.4.8.  client-error-gone (0x0407)

   The requested object is no longer available, and no forwarding
   address is known.  This condition should be considered permanent.
   Clients with link-editing capabilities should delete references to
   the request URI after user approval.  If the IPP object does not know
   or has no facility to determine whether or not the condition is
   permanent, the status-code 'client-error-not-found' should be used
   instead.

   This response is primarily intended to assist the task of maintenance
   by notifying the recipient that the resource is intentionally
   unavailable and that the IPP object Administrator desires that remote
   links to that resource be removed.  It is not necessary to mark all
   permanently unavailable resources as "gone" or to keep the mark for
   any length of time -- that is left to the discretion of the IPP
   object Administrator and/or Printer implementation.

Top      Up      ToC       Page 205 
B.1.4.9.  client-error-request-entity-too-large (0x0408)

   The IPP object is refusing to process a request because the request
   entity is larger than the IPP object is willing or able to process.
   An IPP Printer returns this status-code when it limits the size of
   Print Jobs and it receives a Print Job that exceeds that limit or
   when the attributes are so many that their encoding causes the
   request entity to exceed IPP object capacity.

B.1.4.10.  client-error-request-value-too-long (0x0409)

   The IPP object is refusing to service the request because one or more
   of the Client-supplied attributes have a variable-length value that
   is longer than the maximum length specified for that attribute.  The
   IPP object might not have sufficient resources (memory, buffers,
   etc.) to process (even temporarily), interpret, and/or ignore a value
   larger than the maximum length.  Another use of this error code is
   when the IPP object supports the processing of a large value that is
   less than the maximum length, but during the processing of the
   request as a whole, the object can pass the value onto some other
   system component that is not able to accept the large value.  For
   more details, see the Implementor's Guides [RFC3196] [PWG5100.19].

   Note: For attribute values that are URIs, this rare condition is only
   likely to occur when a Client has improperly submitted a request with
   long query information (e.g., an IPP application allows an End User
   to enter an invalid URI), when the Client has descended into a URI
   "black hole" of redirection (e.g., a redirected URI prefix that
   points to a suffix of itself), or when the IPP object is under attack
   by a Client attempting to exploit security holes present in some IPP
   objects using fixed-length buffers for reading or manipulating the
   request URI.

B.1.4.11.  client-error-document-format-not-supported (0x040a)

   The IPP object is refusing to service the request because the
   Document data is in a format, as specified in the "document-format"
   operation attribute, that is not supported by the Printer.  This
   error is returned independent of the Client-supplied
   "ipp-attribute-fidelity" attribute.  The Printer MUST return this
   status-code, even if there are other Job Template attributes that are
   not supported as well, since this error is a bigger problem than with
   Job Template attributes.  See Sections 4.1.6.1, 4.1.7, and 4.2.1.1.

Top      Up      ToC       Page 206 
B.1.4.12.  client-error-attributes-or-values-not-supported (0x040b)

   In a Job Creation request, if the Printer does not support one or
   more attributes, attribute syntaxes, or attribute values supplied in
   the request and the Client supplied the "ipp-attribute-fidelity"
   operation attribute with the 'true' value, the Printer MUST return
   this status-code.  The Printer MUST also return in the Unsupported
   Attributes group all the attributes and/or values supplied by the
   Client that are not supported.  See Section 4.1.7.  Examples would be
   if the request indicates 'iso-a4' media but that media type is not
   supported by the Printer, or if the Client supplies a Job Template
   attribute and the attribute itself is not even supported by the
   Printer.  If the "ipp-attribute-fidelity" attribute is 'false', the
   Printer MUST ignore or substitute values for unsupported Job Template
   attributes and values rather than reject the request and return this
   status-code.

   For any operation where a Client requests attributes (such as a
   Get-Jobs, Get-Printer-Attributes, or Get-Job-Attributes operation),
   if the IPP object does not support one or more of the requested
   attributes, the IPP object simply ignores the unsupported requested
   attributes and processes the request as if they had not been
   supplied, rather than returning this status-code.  In this case,
   the IPP object MUST return the
   'successful-ok-ignored-or-substituted-attributes' status-code and
   SHOULD return the unsupported attributes as values of the
   "requested-attributes" operation attribute in the Unsupported
   Attributes group (see Appendix B.1.2.2).

B.1.4.13.  client-error-uri-scheme-not-supported (0x040c)

   The scheme of the Client-supplied URI in a Print-URI or a Send-URI
   operation is not supported.  See Sections 4.1.6.1 and 4.1.7.

B.1.4.14.  client-error-charset-not-supported (0x040d)

   For any operation, if the IPP Printer does not support the charset
   supplied by the Client in the "attributes-charset" operation
   attribute, the Printer MUST reject the operation and return this
   status-code, and any 'text' or 'name' attributes using the 'utf-8'
   charset (Section 4.1.4.1).  See Sections 4.1.6.1 and 4.1.7.

Top      Up      ToC       Page 207 
B.1.4.15.  client-error-conflicting-attributes (0x040e)

   The request is rejected because some attribute values conflicted with
   the values of other attributes that this document does not permit to
   be substituted or ignored.  The Printer MUST also return in the
   Unsupported Attributes group the conflicting attributes supplied by
   the Client.  See Sections 4.1.7 and 4.2.1.2.

B.1.4.16.  client-error-compression-not-supported (0x040f)

   The IPP object is refusing to service the request because the
   Document data, as specified in the "compression" operation attribute,
   is compressed in a way that is not supported by the Printer.  This
   error is returned independent of the Client-supplied
   "ipp-attribute-fidelity" attribute.  The Printer MUST return this
   status-code, even if there are other Job Template attributes that are
   not supported as well, since this error is a bigger problem than with
   Job Template attributes.  See Sections 4.1.6.1, 4.1.7, and 4.2.1.1.

B.1.4.17.  client-error-compression-error (0x0410)

   The IPP object is refusing to service the request because the
   Document data cannot be decompressed when using the algorithm
   specified by the "compression" operation attribute.  This error is
   returned independent of the Client-supplied "ipp-attribute-fidelity"
   attribute.  The Printer MUST return this status-code, even if there
   are Job Template attributes that are not supported as well, since
   this error is a bigger problem than with Job Template attributes.
   See Sections 4.1.7 and 4.2.1.1.

B.1.4.18.  client-error-document-format-error (0x0411)

   The IPP object is refusing to service the request because the Printer
   encountered an error in the Document data while interpreting it.
   This error is returned independent of the Client-supplied
   "ipp-attribute-fidelity" attribute.  The Printer MUST return this
   status-code, even if there are Job Template attributes that are not
   supported as well, since this error is a bigger problem than with Job
   Template attributes.  See Sections 4.1.7 and 4.2.1.1.

B.1.4.19.  client-error-document-access-error (0x0412)

   The IPP object is refusing to service the Print-URI or Send-URI
   request because the Printer encountered an access error while
   attempting to validate the accessibility of, or access to, the
   Document data specified in the "document-uri" operation attribute.
   The Printer MAY also return a specific Document access error code
   using the "document-access-error" operation attribute (see

Top      Up      ToC       Page 208 
   Section 4.1.6.4).  This error is returned independent of the
   Client-supplied "ipp-attribute-fidelity" attribute.  The Printer MUST
   return this status-code, even if there are Job Template attributes
   that are not supported as well, since this error is a bigger problem
   than with Job Template attributes.  See Sections 4.1.6.1 and 4.1.7.

B.1.5.  Server Error Status-Code Values

   This class of status-code values indicates cases in which the IPP
   object is aware that it has erred or is incapable of performing the
   request.  The IPP object SHOULD include a message containing an
   explanation of the error situation, and whether it is a temporary or
   permanent condition.

B.1.5.1.  server-error-internal-error (0x0500)

   The IPP object encountered an unexpected condition that prevented it
   from fulfilling the request.  This error status-code differs from
   'server-error-temporary-error' in that it implies a more permanent
   type of internal error.  It also differs from
   'server-error-device-error' in that it implies an unexpected
   condition (unlike a paper-jam or out-of-toner problem, which is
   undesirable but expected).  This error status-code indicates that
   intervention by a knowledgeable human is probably required.

B.1.5.2.  server-error-operation-not-supported (0x0501)

   The IPP object does not support the functionality required to fulfill
   the request.  This is the appropriate response when the IPP object
   does not recognize an operation or is not capable of supporting it.
   See Sections 4.1.6.1 and 4.1.7.

B.1.5.3.  server-error-service-unavailable (0x0502)

   The IPP object is currently unable to handle the request due to
   temporary overloading or due to maintenance of the IPP object.  The
   implication is that this is a temporary condition that will be
   alleviated after some delay.  If known, the length of the delay can
   be indicated in the message.  If no delay is given, the IPP
   application should handle the response as it would for a
   'server-error-temporary-error' response.  If the condition is more
   permanent, the 'client-error-gone' or 'client-error-not-found' error
   status-code could be used.

Top      Up      ToC       Page 209 
B.1.5.4.  server-error-version-not-supported (0x0503)

   The IPP object does not support or refuses to support the IPP version
   that was supplied as the value of the "version-number" operation
   parameter in the request.  The IPP object is indicating that it is
   unable or unwilling to complete the request using the same major and
   minor version number as supplied in the request, other than with this
   error message.  The error response SHOULD contain a "status-message"
   attribute (see Section 4.1.6.2) describing why that version is not
   supported and what other versions are supported by that IPP object.
   See Sections 4.1.6.1, 4.1.7, and 4.1.8.

   The error response MUST identify in the "version-number" operation
   parameter the closest version number that the IPP object does
   support.  For example, if a Client supplies version '1.0' and an
   IPP/1.1 object supports version '1.0', then it responds with
   version '1.0' in all responses to such a request.  If the IPP/1.1
   object does not support version '1.0', then it should accept the
   request and respond with version '1.1' or can reject the request and
   respond with this error code and version '1.1'.  If a Client supplies
   version '1.2', the IPP/1.1 object should accept the request and
   return version '1.1' or can reject the request and respond with this
   error code and version '1.1'.  See Sections 4.1.8 and 5.3.14.

B.1.5.5.  server-error-device-error (0x0504)

   A Printer error, such as a paper jam, occurs while the IPP object
   processes a Print or send operation.  The response contains the true
   Job status (the values of the "job-state" and "job-state-reasons"
   attributes).  Additional information can be returned in the OPTIONAL
   "job-state-message" attribute value or in the OPTIONAL status message
   that describes the error in more detail.  This error status-code is
   only returned in situations where the Printer is unable to accept the
   Job Creation request because of such a device error.  For example, if
   the Printer is unable to spool and can only accept one Job at a time,
   the reason it might reject a Job Creation request is that the Printer
   currently has a paper jam.  In many cases, however, where the Printer
   can accept the request even though the Printer has some error
   condition, the 'successful-ok' status-code will be returned.  In such
   a case, the Client would look at the returned Job object attributes
   or later query the Printer to determine its state and state reasons.

Top      Up      ToC       Page 210 
B.1.5.6.  server-error-temporary-error (0x0505)

   A temporary error such as a buffer-full write error, a memory
   overflow (i.e., the Document data exceeds the memory of the Printer),
   or a disk-full condition, occurs while the IPP Printer processes an
   operation.  The Client MAY try the unmodified request again at some
   later point in time with an expectation that the temporary internal
   error condition has been cleared.  Alternatively, as an
   implementation option, a Printer MAY delay the response until the
   temporary condition is cleared so that no error is returned.

B.1.5.7.  server-error-not-accepting-jobs (0x0506)

   This is a temporary error indicating that the Printer is not
   currently accepting Jobs because the Administrator has set the value
   of the Printer's "printer-is-accepting-jobs" attribute to 'false' (by
   means outside the scope of this IPP/1.1 document).

B.1.5.8.  server-error-busy (0x0507)

   This is a temporary error indicating that the Printer is too busy
   processing Jobs and/or other requests.  The Client SHOULD try the
   unmodified request again at some later point in time with an
   expectation that the temporary busy condition will have been cleared.

B.1.5.9.  server-error-job-canceled (0x0508)

   This is an error indicating that the Job has been canceled by an
   Operator or the system while the Client was transmitting the data to
   the IPP Printer.  If a "job-id" attribute and a "job-uri" attribute
   had been created, then they are returned in the Print-Job,
   Send-Document, or Send-URI response as usual; otherwise, no "job-id"
   and "job-uri" attributes are returned in the response.

B.1.5.10.  server-error-multiple-document-jobs-not-supported (0x0509)

   The IPP object does not support multiple Documents per Job, and a
   Client attempted to supply Document data with a second Send-Document
   or Send-URI operation.

Top      Up      ToC       Page 211 
B.2.  Status-Code Values for IPP Operations

   PJ = Print-Job, PU = Print-URI, CJ = Create-Job, SD = Send-Document,
   SU = Send-URI, V = Validate-Job, GA = Get-Job-Attributes and
   Get-Printer-Attributes, GJ = Get-Jobs, C = Cancel-Job

                                                  IPP Operations
   IPP Status Keyword                       PJ PU CJ SD SU V GA GJ C
   ------------------                       -- -- -- -- -- - -- -- -
   successful-ok                            x  x  x  x  x  x x  x  x
   successful-ok-ignored-or-substituted-    x  x  x  x  x  x x  x  x
        attributes
   successful-ok-conflicting-attributes     x  x  x  x  x  x x  x  x
   client-error-bad-request                 x  x  x  x  x  x x  x  x
   client-error-forbidden                   x  x  x  x  x  x x  x  x
   client-error-not-authenticated           x  x  x  x  x  x x  x  x
   client-error-not-authorized              x  x  x  x  x  x x  x  x
   client-error-not-possible                x  x  x  x  x  x x  x  x
   client-error-timeout                              x  x
   client-error-not-found                   x  x  x  x  x  x x  x  x
   client-error-gone                        x  x  x  x  x  x x  x  x
   client-error-request-entity-too-large    x  x  x  x  x  x x  x  x
   client-error-request-value-too-long      x  x  x  x  x  x x  x  x
   client-error-document-format-not-        x  x     x  x  x x
        supported
   client-error-attributes-or-values-not-   x  x  x  x  x  x x  x  x
        supported
   client-error-uri-scheme-not-supported       x        x
   client-error-charset-not-supported       x  x  x  x  x  x x  x  x
   client-error-conflicting-attributes      x  x  x  x  x  x x  x  x
   client-error-compression-not-supported   x  x     x  x  x
   client-error-compression-error           x  x     x  x
   client-error-document-format-error       x  x     x  x
   client-error-document-access-error          x        x
   server-error-internal-error              x  x  x  x  x  x x  x  x
   server-error-operation-not-supported        x  x  x  x
   server-error-service-unavailable         x  x  x  x  x  x x  x  x
   server-error-version-not-supported       x  x  x  x  x  x x  x  x
   server-error-device-error                x  x  x  x  x
   server-error-temporary-error             x  x  x  x  x
   server-error-not-accepting-jobs          x  x  x        x
   server-error-busy                        x  x  x  x  x  x x  x  x
   server-error-job-canceled                x        x  x
   server-error-multiple-document-jobs-              x  x
          not-supported

Top      Up      ToC       Page 212 
   HJ = Hold-Job, RJ = Release-Job, RS = Restart-Job,
   PP = Pause-Printer, RP = Resume-Printer, PJ = Purge-Jobs

                                            IPP Operations (cont.)
   IPP Status Keyword                       HJ RJ RS PP RP PJ
   ------------------                       -- -- -- -- -- --
   successful-ok                            x  x  x  x  x  x
   successful-ok-ignored-or-substituted-    x  x  x  x  x  x
        attributes
   successful-ok-conflicting-attributes     x  x  x  x  x  x
   client-error-bad-request                 x  x  x  x  x  x
   client-error-forbidden                   x  x  x  x  x  x
   client-error-not-authenticated           x  x  x  x  x  x
   client-error-not-authorized              x  x  x  x  x  x
   client-error-not-possible                x  x  x  x  x  x
   client-error-timeout
   client-error-not-found                   x  x  x  x  x  x
   client-error-gone                        x  x  x  x  x  x
   client-error-request-entity-too-large    x  x  x  x  x  x
   client-error-request-value-too-long      x  x  x  x  x  x
   client-error-document-format-not-
        supported
   client-error-attributes-or-values-not-   x  x  x  x  x  x
        supported
   client-error-uri-scheme-not-supported
   client-error-charset-not-supported       x  x  x  x  x  x
   client-error-conflicting-attributes      x  x  x  x  x  x
   client-error-compression-not-supported
   client-error-compression-error
   client-error-document-format-error
   client-error-document-access-error
   server-error-internal-error              x  x  x  x  x  x
   server-error-operation-not-supported     x  x  x  x  x  x
   server-error-service-unavailable         x  x  x  x  x  x
   server-error-version-not-supported       x  x  x  x  x  x
   server-error-device-error
   server-error-temporary-error             x  x  x  x  x  x
   server-error-not-accepting-jobs
   server-error-busy                        x  x  x  x  x  x
   server-error-job-canceled
   server-error-multiple-document-jobs-
          not-supported

Top      Up      ToC       Page 213 
Appendix C.  Processing IPP Attributes

   When submitting a Print Job to a Printer, the IPP Model allows a
   Client to supply operation and Job Template attributes along with the
   Document data.  These Job Template attributes in the Job Creation
   request affect the rendering, production, and finishing of the
   Documents in the Job.  Similar types of instructions can also be
   contained in the Document data itself.  In addition, the Printer has
   a set of attributes that describe what rendering and finishing
   processes are supported by that Printer.  This model, which allows
   for flexibility and power, also introduces the potential that
   Client-supplied attributes can conflict with either:

   o  what the implementation is capable of realizing (i.e., what the
      Printer supports), or

   o  the instructions embedded within the Document data itself.

   The following sections describe how these two types of conflicts are
   handled in the IPP Model.

C.1.  Fidelity

   If there is a conflict between what the Client requests and what a
   Printer supports, the Client can request one of two possible
   conflict-handling mechanisms:

   1)  either reject the Job, since the Job cannot be processed exactly
       as specified, or

   2)  allow the Printer to make any changes necessary to proceed with
       processing the Job the best it can.

   In the first case, the Client is indicating the following to the
   Printer: "Print the Job exactly as specified with no exceptions, and
   if that can't be done, don't even bother printing the Job at all."
   In the second case, the Client is indicating the following to the
   Printer: "It is more important to make sure the Job is printed rather
   than be processed exactly as specified; just make sure the Job is
   printed even if some Client-supplied attributes need to be changed or
   ignored."

   The IPP Model accounts for this situation by introducing an
   "ipp-attribute-fidelity" attribute.

Top      Up      ToC       Page 214 
   In a Job Creation request, "ipp-attribute-fidelity" is a boolean
   operation attribute that MAY be supplied by the Client.  The value
   'true' indicates that total fidelity to Client-supplied Job Template
   attributes and values is required.  The Client is requesting that the
   Job be printed exactly as specified, and if that is not possible,
   then the Job MUST be rejected rather than processed incorrectly.  The
   value 'false' indicates that a reasonable attempt to print the Job is
   acceptable.  If a Printer does not support some of the
   Client-supplied Job Template attributes or values, the Printer MUST
   ignore or replace them with supported values.  The Printer can choose
   to substitute the default value associated with that attribute or use
   some other supported value that is similar to the unsupported
   requested value.  For example, if a Client supplies a "media" value
   of 'na_letter_8.5x11in', the Printer can choose to substitute
   'iso_a4_210x297mm' rather than a default value of
   'na_personal_3.625x6.5in'.  If the Client does not supply the
   "ipp-attribute-fidelity" attribute, the Printer assumes a value of
   'false'.

   Each Printer implementation MUST support both types of "fidelity"
   printing (that is, whether the Client supplies a value of 'true' or
   'false'):

   o  If the Client supplies 'false' or does not supply the attribute,
      the Printer MUST always accept the request by ignoring unsupported
      Job Template attributes and by substituting unsupported values of
      supported Job Template attributes with supported values.

   o  If the Client supplies 'true', the Printer MUST reject the request
      if the Client supplies unsupported Job Template attributes.

   Since a Client can always query a Printer to find out exactly what is
   and is not supported, "ipp-attribute-fidelity" set to 'false' is
   useful when:

   1)  The End User uses a command line interface to request attributes
       that might not be supported.

   2)  In a GUI context, if the End User expects the Job might be moved
       to another Printer and prefers a suboptimal result to nothing
       at all.

   3)  The End User just wants something reasonable in lieu of nothing
       at all.

Top      Up      ToC       Page 215 
C.2.  Page Description Language (PDL) Override

   If there is a conflict between the value of an IPP Job Template
   attribute and a corresponding instruction in the Document data, the
   value of the IPP attribute SHOULD take precedence over the Document
   instruction.  Consider the case where a previously formatted file of
   Document data is sent to an IPP Printer.  In this case, if the Client
   supplies any attributes at Job submission time, the Client desires
   that those attributes override the embedded instructions.  Consider
   the case where a previously formatted Document has embedded in it
   commands to load 'iso-a4' media.  However, the Document is passed to
   an End User that only has access to a Printer with 'na-letter' media
   loaded.  That End User most likely wants to submit that Document to
   an IPP Printer with the "media" Job Template attribute set to
   'na-letter'.  Attributes supplied at Job submission time should take
   precedence over the embedded PDL instructions.  However, until
   companies that supply Document data interpreters allow a way for
   external IPP attributes to take precedence over embedded Job
   production instructions, a Printer might not be able to support the
   semantics that IPP attributes override the embedded instructions.

   The IPP Model accounts for this situation by introducing a
   "pdl-override-supported" attribute that describes the Printer's
   capabilities to override instructions embedded in the PDL data
   stream.  The value of the "pdl-override-supported" attribute is
   configured by means outside the scope of this IPP/1.1 document.

   This REQUIRED Printer attribute takes on the following values:

   o  'attempted': This value indicates that the Printer attempts to
      make the IPP attribute values take precedence over embedded
      instructions in the Document data; however, there is no guarantee.

   o  'not-attempted': This value indicates that the Printer makes no
      attempt to make the IPP attribute values take precedence over
      embedded instructions in the Document data.

   At Job processing time, an implementation that supports the value of
   'attempted' might do one of several different actions:

   1)  Generate an Output-Device-specific command sequence to realize
       the feature represented by the IPP attribute value.

   2)  Parse the Document data itself and replace the conflicting
       embedded instruction with a new embedded instruction that matches
       the intent of the IPP attribute value.

Top      Up      ToC       Page 216 
   3)  Indicate to the Printer that external supplied attributes take
       precedence over embedded instructions and then pass the external
       IPP attribute values to the Document data interpreter.

   4)  Anything else that allows for the semantics that IPP attributes
       override embedded Document data instructions.

   Since 'attempted' does not offer any type of guarantee, even though a
   given Printer might not do a very "good" job of attempting to ensure
   that IPP attributes take a higher precedence over instructions
   embedded in the Document data, it would still be a conforming
   implementation.

   At Job processing time, an implementation that supports the value of
   'not-attempted' might do one of the following actions:

   1)  Simply prepend the Document data with the PDL instruction that
       corresponds to the Client-supplied PDL attribute, such that if
       the Document data also has the same PDL instruction it will
       override what the Printer prepended.  In other words, this
       implementation is using the same implementation semantics for the
       Client-supplied IPP attributes as for the Printer defaults.

   2)  Parse the Document data and replace the conflicting embedded
       instruction with a new embedded instruction that approximates,
       but does not match, the semantic intent of the IPP attribute
       value.

   Note: The "ipp-attribute-fidelity" attribute applies to the Printer's
   ability to either accept or reject other unsupported Job Template
   attributes.  In other words, if "ipp-attribute-fidelity" is set to
   'true', a Job is accepted if and only if the Client-supplied Job
   Template attributes and values are supported by the Printer.  Whether
   these attributes actually affect the processing of the Job when the
   Document data contains embedded instructions depends on the ability
   of the Printer to override the instructions embedded in the Document
   data with the semantics of the IPP attributes.  If the Document data
   attributes can be overridden ("pdl-override-supported" set to
   'attempted'), the Printer makes an attempt to use the IPP attributes
   when processing the Job.  If the Document data attributes cannot be
   overridden ("pdl-override-supported" set to 'not-attempted'), the
   Printer makes no attempt to override the embedded Document data
   instructions with the IPP attributes when processing the Job, and
   hence, the IPP attributes can fail to affect the Job processing and
   output when the corresponding instruction is embedded in the
   Document data.

Top      Up      ToC       Page 217 
C.3.  Using Job Template Attributes during Document Processing

   The Printer uses some of the Job's Job Template attributes during the
   processing of the Document data associated with that Job.  These
   include, but are not limited to, "orientation-requested",
   "number-up", "sides", "media", and "copies".  The processing of each
   Document in a Job object MUST follow the steps below.  These steps
   are intended only to identify when and how attributes are to be used
   in processing Document data; any alternative steps that accomplish
   the same effect can be used to implement this specification document.

   1.  Using the Client-supplied "document-format" attribute or some
       form of Document format detection algorithm (if the value of
       "document-format" is not specific enough), determine whether the
       Document data has already been formatted for printing.  If the
       Document data has been formatted, then go to step 2.  Otherwise,
       the Document data MUST be formatted.  The formatting detection
       algorithm is implementation defined and is not specified by this
       document.  The formatting of the Document data uses the
       "orientation-requested" attribute to determine how the formatted
       print data should be placed on an Input Page; see Section 5.2.10
       for details.

   2.  The Document data is a set of Input Pages in a known media type.
       The "page-ranges" attribute is used to select, as specified in
       Section 5.2.7, a sub-sequence of the pages in the print-stream
       that are to be processed and imaged.

   3.  The input for this step is a sequence of Input Pages.  This step
       is controlled by the "number-up" attribute.  If the value of
       "number-up" is N, then during the processing of the Input Pages
       each N Input Pages are positioned, as specified in Section 5.2.9,
       to create a single Impression.  If a given Document does not have
       N more Input Pages, then the completion of the Impression is
       controlled by the "multiple-document-handling" attribute as
       described in Section 5.2.4; when the value of this attribute is
       'single-document' or 'single-document-new-sheet', the Input Pages
       of Document data from subsequent Documents are used to complete
       the Impression.

   The size (scaling), position (translation), and rotation of the Input
   Pages on the Impression are implementation defined.  Note that during
   this process the Input Pages can be rendered to a form suitable for
   placing on the Impression; this rendering is controlled by the values
   of the "printer-resolution" and "print-quality" attributes as
   described in Sections 5.2.12 and 5.2.13.  In the case where N = 1,
   the Impression is nearly the same as the Input Page; the differences

Top      Up      ToC       Page 218 
   would only be in the size, position, and rotation of the Input Page
   and/or any decoration, such as a frame for the page, that is added by
   the implementation.

   1.  The collection of Impressions is placed, in sequence, onto sides
       of the Media Sheets.  This placement is controlled by the "sides"
       attribute and the orientation of the Input Page, as described in
       Section 5.2.8.  The orientation of the Input Pages affects the
       orientation of the Impression; for example, if "number-up" equals
       2, then, typically, two portrait Input Pages become one landscape
       Impression.  Note that the placement of Impressions onto Media
       Sheets is also controlled by the "multiple-document-handling"
       attribute as described in Section 5.2.4.

   2.  The "copies" and "multiple-document-handling" attributes are used
       to determine how many copies of each Media Sheet are printed and
       in what order.  See Sections 5.2.4 and 5.2.5 for details.

   3.  When the correct number of copies are created, the Media Sheets
       are finished according to the values of the "finishings"
       attribute as described in Section 5.2.6.  Note that sometimes
       finishing processes can require manual intervention to perform
       the finishing processes on the copies, especially uncollated
       copies.  This document allows any or all of the processing steps
       to be performed automatically or manually, at the discretion of
       the Printer.

Appendix D.  Generic Directory Schema

   This section defines a generic schema for an entry in a directory
   service.  Implementations of this schema are defined by "Lightweight
   Directory Access Protocol (LDAP): Schema for Printer Services"
   [RFC7612] and "IPP Everywhere" [PWG5100.14].  A directory service is
   a means by which service users can locate service providers.  In IPP
   environments, this means that IPP Printers can be registered (either
   automatically or with the help of an Administrator) as entries of
   type Printer in the directory using an implementation-specific
   mechanism such as entry attributes, entry type fields, specific
   branches, etc.  Directory Clients can search or browse for entries of
   type Printer.  Clients use the directory service to find entries
   based on naming, organizational contexts, or filtered searches on
   attribute values of entries.  For example, a Client can find all
   Printers in the "Local Department" context.  Authentication and
   authorization are also often part of a directory service so that an
   Administrator can place limits on End Users so that they are only
   allowed to find entries to which they have certain access rights.
   IPP itself does not require any specific directory service protocol
   or provider.

Top      Up      ToC       Page 219 
   Note: Some directory implementations allow for the notion of
   "aliasing".  That is, one directory entry object can appear as
   multiple directory entry objects with different names for each
   object.  In each case, each alias refers to the same directory entry
   object, which refers to a single IPP Printer.

   The generic schema is a subset of IPP Printer Job Template and
   Printer Description attributes (Sections 5.2 and 5.4).  These
   attributes are identified as either RECOMMENDED or OPTIONAL for the
   directory entry itself.  This conformance labeling is NOT the same
   conformance labeling applied to the attributes of IPP Printer
   objects.  The conformance labeling in this appendix is intended to
   apply to directory templates and to IPP Printer implementations that
   subscribe by adding one or more entries to a directory.  RECOMMENDED
   attributes SHOULD be associated with each directory entry.  OPTIONAL
   attributes MAY be associated with the directory entry (if known or
   supported).  In addition, all directory entry attributes SHOULD
   reflect the current attribute values for the corresponding Printer.

   As much as possible, the names of attributes in directory schema and
   entries SHOULD be the same as the IPP Printer attribute names as
   shown.

   In order to bridge between the directory service and the IPP Printer,
   one of the RECOMMENDED directory entry attributes is the Printer's
   "printer-uri-supported" attribute.  The directory Client queries the
   "printer-uri-supported" attribute (or its equivalent) in the
   directory entry, and then the IPP Client addresses the IPP Printer
   using one of its URIs.  The "uri-security-supported" attribute
   identifies the protocol (if any) used to secure a channel.

   The attributes in Table 23 define the generic schema for directory
   entries of type Printer.

   +------------------------------------+-------------+----------------+
   | Attribute                          | Conformance | Section        |
   +------------------------------------+-------------+----------------+
   | charset-supported                  | OPTIONAL    | Section 5.4.18 |
   +------------------------------------+-------------+----------------+
   | color-supported                    | RECOMMENDED | Section 5.4.26 |
   +------------------------------------+-------------+----------------+
   | compression-supported              | RECOMMENDED | Section 5.4.32 |
   +------------------------------------+-------------+----------------+
   | document-format-supported          | RECOMMENDED | Section 5.4.22 |
   +------------------------------------+-------------+----------------+
   | finishings-supported               | OPTIONAL    | Section 5.2.6  |

Top      Up      ToC       Page 220 
   +------------------------------------+-------------+----------------+
   | generated-natural-language-        | OPTIONAL    | Section 5.4.20 |
   | supported                          |             |                |
   +------------------------------------+-------------+----------------+
   | ipp-versions-supported             | RECOMMENDED | Section 5.4.14 |
   +------------------------------------+-------------+----------------+
   | media-supported                    | RECOMMENDED | Section 5.2.11 |
   +------------------------------------+-------------+----------------+
   | multiple-document-jobs-supported   | OPTIONAL    | Section 5.4.16 |
   +------------------------------------+-------------+----------------+
   | number-up-supported                | OPTIONAL    | Section 5.2.9  |
   +------------------------------------+-------------+----------------+
   | pages-per-minute-color             | OPTIONAL    | Section 5.4.37 |
   +------------------------------------+-------------+----------------+
   | pages-per-minute                   | OPTIONAL    | Section 5.4.36 |
   +------------------------------------+-------------+----------------+
   | print-quality-supported            | OPTIONAL    | Section 5.2.13 |
   +------------------------------------+-------------+----------------+
   | printer-info                       | OPTIONAL    | Section 5.4.6  |
   +------------------------------------+-------------+----------------+
   | printer-location                   | RECOMMENDED | Section 5.4.5  |
   +------------------------------------+-------------+----------------+
   | printer-make-and-model             | RECOMMENDED | Section 5.4.9  |
   +------------------------------------+-------------+----------------+
   | printer-more-info                  | OPTIONAL    | Section 5.4.7  |
   +------------------------------------+-------------+----------------+
   | printer-name                       | RECOMMENDED | Section 5.4.4  |
   +------------------------------------+-------------+----------------+
   | printer-resolution-supported       | OPTIONAL    | Section 5.2.12 |
   +------------------------------------+-------------+----------------+
   | printer-uri-supported              | RECOMMENDED | Section 5.4.1  |
   +------------------------------------+-------------+----------------+
   | sides-supported                    | RECOMMENDED | Section 5.2.8  |
   +------------------------------------+-------------+----------------+
   | uri-authentication-supported       | RECOMMENDED | Section 5.4.2  |
   +------------------------------------+-------------+----------------+
   | uri-security-supported             | RECOMMENDED | Section 5.4.3  |
   +------------------------------------+-------------+----------------+

                 Table 23: Attributes in Directory Entries

Top      Up      ToC       Page 221 
Acknowledgements

   The authors would like to acknowledge the following individuals for
   their contributions to the original IPP/1.1 specifications:

   Roger deBry, Tom Hastings (original RFC 2911 editor), Robert Herriot,
   Scott A. Isaacson, Kirk Ocke, Patrick Powell, and Peter Zehler

Authors' Addresses

   Michael Sweet
   Apple Inc.
   1 Infinite Loop
   MS 111-HOMC
   Cupertino, CA  95014
   United States of America

   Email: msweet@apple.com


   Ira McDonald
   High North, Inc.
   PO Box 221
   Grand Marais, MI  49839
   United States of America

   Phone: +1 906-494-2434
   Email: blueroofmusic@gmail.com