4.3.  Job Operations

   All Job operations are directed at Jobs.  A Client MUST always supply
   some means of identifying the Job object in order to identify the
   correct target of the operation.  That Job identification SHOULD be
   the combination of a Printer URI with a Job ID but MAY be the
   (single) Job URI.  The IPP implementation MUST support both forms of
   identification for every Job.

4.3.1.  Send-Document Operation

   This RECOMMENDED operation allows a Client to add a Document to a Job
   that was created using the Create-Job operation.  In the Create-Job
   response, the Printer returns the Job's URI (the "job-uri" attribute)
   and the Job's 32-bit identifier (the "job-id" attribute).  For each
   new Document that the Client desires to add, the Client uses a
   Send-Document operation.  Each Send-Document request contains the
   entire stream of Document data for one Document.

   If the Printer supports this operation but does not support multiple
   Documents per Job, the Printer MUST reject subsequent Send-Document
   operations supplied with data and return the
   'server-error-multiple-document-jobs-not-supported' status-code.
   However, the Printer MUST accept the first Document with a 'true' or
   'false' value for the "last-document" operation attribute (see
   below), so that Clients MAY always submit one Document Job with a
   'false' value for "last-document" in the first Send-Document and a
   'true' value for "last-document" in the second Send-Document (with
   no data).

   Since the Create-Job and the send operations (Send-Document or
   Send-URI operations) that follow could occur over an arbitrarily long
   period of time for a particular Job, a Client MUST send another send
   operation within a minimum time interval, as defined by the IPP
   Printer, after the receipt of the previous request for the Job.  If a
   Printer supports the Create-Job and Send-Document operations, the
   Printer MUST support the "multiple-operation-time-out" attribute (see
   Section 5.4.31).  This attribute indicates the minimum number of
   seconds the Printer will wait for the next send operation before
   taking some recovery action.

   A Printer MUST recover from an errant Client that does not supply a
   send operation, sometime after the minimum time interval specified by
   the Printer's "multiple-operation-time-out" attribute.  Such recovery
   MAY include any of the following actions or other recovery actions:

   1.  Assume that the Job is an invalid Job, start the process of
       changing the Job state to 'aborted', add the 'aborted-by-system'
       value to the Job's "job-state-reasons" attribute (see
       Section 5.3.8), and clean up all resources associated with the
       Job.  In this case, if another send operation is finally
       received, the Printer responds with a 'client-error-not-possible'
       or 'client-error-not-found' status-code, depending on whether the
       Job is still around when the send operation finally arrives.

   2.  Assume that the last send operation received was in fact the last
       Document (as if the "last-document" flag had been set to 'true'),
       close the Job, and proceed to process it (i.e., move the Job's
       state to 'pending').

   3.  Assume that the last send operation received was in fact the last
       Document and close the Job, but move it to the 'pending-held'
       state and add the 'submission-interrupted' value to the Job's
       "job-state-reasons" attribute (see Section 5.3.8).  This action
       allows the user or an Operator to determine whether to continue
       processing the Job by moving it back to the 'pending' state using
       the Release-Job operation (see Section 4.3.6) or to cancel the
       Job using the Cancel-Job operation (see Section 4.3.3).

   Each implementation is free to decide the "best" action to take,
   depending on the following: local policy, whether any Documents have
   been added, whether the implementation spools Jobs or not, and/or any
   other piece of information available to it.  If the choice is to
   abort the Job, it is possible that the Job has already been processed
   to the point that some Media Sheet pages have been printed.

   Access Rights: The authenticated user (see Section 9.3) performing
   this operation must be either the Job owner (as determined in the
   Create-Job operation) or an Operator or Administrator of the Printer
   (see Sections 1 and 9.5).  Otherwise, the Printer MUST reject the
   operation and return 'client-error-forbidden',
   'client-error-not-authenticated', or 'client-error-not-authorized'
   as appropriate.

4.3.1.1.  Send-Document Request

   The following attribute sets are part of the Send-Document request:

   Group 1: Operation Attributes

      Natural Language and Character Set:

         The "attributes-charset" and "attributes-natural-language"
         attributes as described in Section 4.1.4.1.

      Target:

         Either the "printer-uri" (uri) plus "job-id" (integer(1:MAX)),
         or the "job-uri" (uri) operation attribute(s), which define the
         target for this operation as described in Section 4.1.5.

      Requesting User Name:

         The "requesting-user-name" (name(MAX)) attribute SHOULD be
         supplied by the Client as described in Section 9.3.

      "document-name" (name(MAX)):

         The Client MAY supply and the Printer MUST support this
         attribute.  It contains the Client-supplied Document name.  The
         Document name MAY be different than the Job name and is not
         guaranteed to be unique across multiple Documents in the same
         Job.  Typically, the Client software automatically supplies the
         Document name on behalf of the End User by using a file name or
         an application-generated name.  See the description of the
         "document-name" operation attribute in the Print-Job request
         (Section 4.2.1.1) for more information about this attribute.

      "compression" (type2 keyword):

         See the description of "compression" for the Print-Job
         operation in Section 4.2.1.1.

      "document-format" (mimeMediaType):

         See the description of "document-format" for the Print-Job
         operation in Section 4.2.1.1.

      "document-natural-language" (naturalLanguage):

         The Client MAY supply and the Printer MAY support this
         attribute.  It specifies the natural language of the Document
         content for those Document formats that require a specification
         of the natural language in order to properly image the
         Document.

      "last-document" (boolean):

         The Client MUST supply and the Printer MUST support this
         attribute.  It is a boolean flag that is set to 'true' if this
         is the last Document for the Job; otherwise, it is set to
         'false'.

   Group 2: Document Data

      The Client MUST supply the Document data if the "last-document"
      flag is set to 'false'.  However, since a Client might not know
      that the previous Document sent with a Send-Document (or Send-URI)
      operation was the last Document (i.e., the "last-document"
      attribute was set to 'false'), it is legal to send a Send-Document
      request with no Document data where the "last-document" flag is
      set to 'true'.  Such a request MUST NOT increment the value of the
      Job's "number-of-documents" attribute, since no real Document was
      added to the Job.  It is not an error for a Client to submit a Job
      with no actual Document data, i.e., only a single Create-Job and
      Send-Document request with a "last-document" operation attribute
      set to 'true' with no Document data.

4.3.1.2.  Send-Document Response

   The following sets of attributes are part of the Send-Document
   response:

   Group 1: Operation Attributes

      Natural Language and Character Set:

         The "attributes-charset" and "attributes-natural-language"
         attributes as described in Section 4.1.4.2.

      Status Message:

         In addition to the REQUIRED status-code returned in every
         response, the response MAY include a "status-message"
         (text(255)) and/or a "detailed-status-message" (text(MAX))
         operation attribute as described in Appendix B and
         Section 4.1.6.

   Group 2: Unsupported Attributes

      See Section 4.1.7 for details on returning unsupported attributes.

   Group 3: Job Object Attributes

      This is the same set of attributes as those described in the
      Print-Job response (see Section 4.2.1.2).

4.3.2.  Send-URI Operation

   This RECOMMENDED operation is identical to the Send-Document
   operation (see Section 4.3.1), except that a Client MUST supply a URI
   reference ("document-uri" operation attribute) rather than the
   Document data itself.  If a Printer supports this operation, Clients
   can use both Send-URI and Send-Document operations to add new
   Documents to an existing Job.  However, if a Client needs to indicate
   that the previous Send-URI or Send-Document was the last Document,
   the Client MUST use the Send-Document operation with no Document data
   and the "last-document" flag set to 'true' (rather than using a
   Send-URI operation with no "document-uri" operation attribute).

   If a Printer supports this operation, it MUST also support the
   Print-URI operation (see Section 4.2.2).

   The Printer MUST validate the syntax and URI scheme of the supplied
   URI before returning a response, just as in the Print-URI operation.
   The Printer MAY validate the accessibility of the Document as part of
   the operation, or subsequently (see Section 4.2.2).

4.3.3.  Cancel-Job Operation

   This REQUIRED operation allows a Client to cancel a Print Job from
   the time the Job is created up to the time it is completed, canceled,
   or aborted.  Since a Job might already be printing by the time a
   Cancel-Job is received, some Media Sheet pages might be printed
   before the Job is actually terminated.

   The Printer MUST accept or reject the request based on the Job's
   current state and transition the Job to the indicated new state as
   shown in Table 4.

   Access Rights: The authenticated user (see Section 9.3) performing
   this operation must be either the Job owner or an Operator or
   Administrator of the Printer (see Sections 1 and 9.5).  Otherwise,
   the Printer MUST reject the operation and return
   'client-error-forbidden', 'client-error-not-authenticated', or
   'client-error-not-authorized' as appropriate.

   +-------------------+--------------------+--------------------------+
   | Current "job-     | New "job-state"    | Printer's response       |
   | state"            |                    | status-code and action:  |
   +-------------------+--------------------+--------------------------+
   | 'pending'         | 'canceled'         | 'successful-ok'          |
   +-------------------+--------------------+--------------------------+
   | 'pending-held'    | 'canceled'         | 'successful-ok'          |
   +-------------------+--------------------+--------------------------+
   | 'processing'      | 'canceled'         | 'successful-ok'          |
   +-------------------+--------------------+--------------------------+
   | 'processing'      | 'processing'       | 'successful-ok' (note 1) |
   +-------------------+--------------------+--------------------------+
   | 'processing'      | 'processing'       | 'client-error-not-       |
   |                   |                    | possible' (note 2)       |
   +-------------------+--------------------+--------------------------+
   | 'processing-      | 'canceled'         | 'successful-ok'          |
   | stopped'          |                    |                          |
   +-------------------+--------------------+--------------------------+
   | 'processing-      | 'processing-       | 'successful-ok' (note 1) |
   | stopped'          | stopped'           |                          |
   +-------------------+--------------------+--------------------------+
   | 'processing-      | 'processing-       | 'client-error-not-       |
   | stopped'          | stopped'           | possible' (note 2)       |
   +-------------------+--------------------+--------------------------+
   | 'completed'       | 'completed'        | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'canceled'        | 'canceled'         | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'aborted'         | 'aborted'          | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+

                   Table 4: Cancel-Job State Transitions

   Note 1: If the implementation requires some measurable time to cancel
   the Job in the 'processing' or 'processing-stopped' Job state, the
   Printer MUST add the 'processing-to-stop-point' value to the Job's
   "job-state-reasons" attribute and then transition the Job to the
   'canceled' state when the processing ceases (see Section 5.3.8).

   Note 2: If the Job already has the 'processing-to-stop-point' value
   in its "job-state-reasons" attribute, then the Printer MUST reject a
   Cancel-Job operation.

4.3.3.1.  Cancel-Job Request

   The following groups of attributes are part of the Cancel-Job
   request:

   Group 1: Operation Attributes

      Natural Language and Character Set:

         The "attributes-charset" and "attributes-natural-language"
         attributes as described in Section 4.1.4.1.

      Target:

         Either the "printer-uri" (uri) plus "job-id" (integer(1:MAX)),
         or the "job-uri" (uri) operation attribute(s), which define the
         target for this operation as described in Section 4.1.5.

      Requesting User Name:

         The "requesting-user-name" (name(MAX)) attribute SHOULD be
         supplied by the Client as described in Section 9.3.

      "message" (text(127)):

         The Client MAY supply and the Printer MAY support this
         attribute.  It is a message to the Operator.  This "message"
         attribute is not the same as the "job-message-from-operator"
         attribute.  That attribute is used to report a message from the
         Operator to the End User that queries that attribute.  This
         "message" operation attribute is used to send a message from
         the Client to the Operator along with the operation request.
         How or where to display this message to the Operator (if
         at all) is an implementation decision.

4.3.3.2.  Cancel-Job Response

   The following sets of attributes are part of the Cancel-Job response:

   Group 1: Operation Attributes

      Natural Language and Character Set:

         The "attributes-charset" and "attributes-natural-language"
         attributes as described in Section 4.1.4.2.

      Status Message:

         In addition to the REQUIRED status-code returned in every
         response, the response MAY include a "status-message"
         (text(255)) and/or a "detailed-status-message" (text(MAX))
         operation attribute as described in Appendix B and
         Section 4.1.6.

   Group 2: Unsupported Attributes

      See Section 4.1.7 for details on returning unsupported attributes.

      Once a successful response has been sent, the implementation
      guarantees that the Job will eventually end up in the 'canceled'
      state.  Between the time that the Cancel-Job operation is accepted
      and when the Job enters the 'canceled' job-state (see
      Section 5.3.7), the "job-state-reasons" attribute SHOULD contain
      the 'processing-to-stop-point' value, which indicates to later
      queries that although the Job might still be 'processing' it will
      eventually end up in the 'canceled' state, not the 'completed'
      state.

4.3.4.  Get-Job-Attributes Operation

   This REQUIRED operation allows a Client to request the values of
   attributes of a Job, and it is almost identical to the
   Get-Printer-Attributes operation (see Section 4.2.5).  The only
   differences are that the operation is directed at a Job rather than a
   Printer, there is no "document-format" operation attribute used when
   querying a Job, and the returned attribute group is a set of Job
   attributes rather than a set of Printer attributes.

   For Jobs, the possible names of attribute groups are:

   o  'job-template': the subset of the Job Template attributes that
      apply to a Job (the first column of Table 8 in Section 5.2) that
      the implementation supports for Jobs.

   o  'job-description': the subset of the Job Description and Status
      attributes specified in Section 5.3 that the implementation
      supports for Jobs.

   o  'all': the special group 'all' that includes all attributes that
      the implementation supports for Jobs.

   Since a Client MAY request specific attributes or named groups, there
   is a potential for some overlap.  For example, if a Client requests
   'job-name' and 'job-description', the Client is actually requesting
   the "job-name" attribute once by naming it explicitly, and once by
   inclusion in the 'job-description' group.  In such cases, the Printer
   returns the attribute only once in the response even if it is
   requested multiple times.  The Client SHOULD NOT request the same
   attribute in multiple ways.

   Jobs MUST support all group names and MUST return all supported
   attributes belonging to the group.

4.3.4.1.  Get-Job-Attributes Request

   The following groups of attributes are part of the Get-Job-Attributes
   request when the request is directed at a Job:

   Group 1: Operation Attributes

      Natural Language and Character Set:

         The "attributes-charset" and "attributes-natural-language"
         attributes as described in Section 4.1.4.1.

      Target:

         Either the "printer-uri" (uri) plus "job-id" (integer(1:MAX)),
         or the "job-uri" (uri) operation attribute(s), which define the
         target for this operation as described in Section 4.1.5.

      Requesting User Name:

         The "requesting-user-name" (name(MAX)) attribute SHOULD be
         supplied by the Client as described in Section 9.3.

      "requested-attributes" (1setOf keyword):

         The Client MAY supply and the Printer MUST support this
         attribute.  It is a set of attribute names and/or attribute
         group names in whose values the requester is interested.  If
         the Client omits this attribute, the Printer MUST respond as if
         this attribute had been supplied with a value of 'all'.

4.3.4.2.  Get-Job-Attributes Response

   The Printer returns the following sets of attributes as part of the
   Get-Job-Attributes response:

   Group 1: Operation Attributes

      Natural Language and Character Set:

         The "attributes-charset" and "attributes-natural-language"
         attributes as described in Section 4.1.4.2.
         "attributes-natural-language" MAY be the natural language of
         the Job, rather than the one requested.

      Status Message:

         In addition to the REQUIRED status-code returned in every
         response, the response MAY include a "status-message"
         (text(255)) and/or a "detailed-status-message" (text(MAX))
         operation attribute as described in Appendix B and
         Section 4.1.6.

   Group 2: Unsupported Attributes

      See Section 4.1.7 for details on returning unsupported attributes.

      The response MAY contain the "requested-attributes" operation
      attribute with any supplied values (attribute keywords) that were
      requested by the Client but are not supported by the Printer.  If
      the Printer does return unsupported attributes referenced in the
      "requested-attributes" operation attribute and that attribute
      included group names, such as 'all', the unsupported attributes
      MUST NOT include attributes described in this document but not
      supported by the implementation.

   Group 3: Job Attributes

      This is the set of requested attributes and their current values.
      The Printer ignores (does not respond with) any requested
      attribute or value that is not supported or that is restricted by
      the security policy in force, including whether the requesting
      user is the user that submitted the Job (Job-originating user) or
      not (see Section 9).  However, the Printer MUST respond with the
      'unknown' value for any supported attribute (including all
      REQUIRED attributes) for which the Printer does not know the
      value, unless it would violate the security policy.  See the
      description of the "out-of-band" values in the beginning of
      Section 5.1.

4.3.5.  Hold-Job Operation

   This OPTIONAL operation allows a Client to hold a pending Job in the
   queue so that it is not eligible for scheduling.  If the Hold-Job
   operation is supported, then the Release-Job operation MUST be
   supported, and vice versa.  The OPTIONAL "job-hold-until" operation
   attribute allows a Client to specify whether to hold the Job
   indefinitely or until a specified time period, if supported.

   The Printer MUST accept or reject the request based on the Job's
   current state and transition the Job to the indicated new state as
   shown in Table 5.

   Note: In order to keep the Hold-Job operation simple, such a request
   is rejected when the Job is in the 'processing' or
   'processing-stopped' state.  If an operation is needed to hold Jobs
   while in either of these states, it will be added as an additional
   operation, rather than overloading the Hold-Job operation.  Then it
   is clear to Clients by querying the Printer's "operations-supported"
   (see Section 5.4.15) and the Job's "job-state" (see Section 5.3.7)
   attributes which operations are possible.

   Access Rights: The authenticated user (see Section 9.3) performing
   this operation must be either the Job owner or an Operator or
   Administrator of the Printer (see Sections 1 and 9.5).  Otherwise,
   the Printer MUST reject the operation and return
   'client-error-forbidden', 'client-error-not-authenticated', or
   'client-error-not-authorized' as appropriate.

   +-------------------+--------------------+--------------------------+
   | Current "job-     | New "job-state"    | Printer's response       |
   | state"            |                    | status-code and action:  |
   +-------------------+--------------------+--------------------------+
   | 'pending'         | 'pending-held'     | 'successful-ok' (note 1) |
   +-------------------+--------------------+--------------------------+
   | 'pending'         | 'pending'          | 'successful-ok' (note 2) |
   +-------------------+--------------------+--------------------------+
   | 'pending-held'    | 'pending-held'     | 'successful-ok' (note 1) |
   +-------------------+--------------------+--------------------------+
   | 'pending-held'    | 'pending'          | 'successful-ok' (note 2) |
   +-------------------+--------------------+--------------------------+
   | 'processing'      | 'processing'       | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'processing-      | 'processing-       | 'client-error-not-       |
   | stopped'          | stopped'           | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'completed'       | 'completed'        | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'canceled'        | 'canceled'         | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'aborted'         | 'aborted'          | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+

                    Table 5: Hold-Job State Transitions

   Note 1: If the implementation supports multiple reasons for a Job to
   be in the 'pending-held' state, the Printer MUST add the
   "job-hold-until-specified" value to the Job's "job-state-reasons"
   attribute.

   Note 2: If the Printer supports the "job-hold-until" operation
   attribute, but the specified time period has already started (or is
   the 'no-hold' value) and there are no other reasons to hold the Job,
   the Printer MUST make the Job be a candidate for processing
   immediately (see Section 5.2.2) by putting the Job in the 'pending'
   state.

4.3.5.1.  Hold-Job Request

   The groups and operation attributes are the same as those defined for
   a Cancel-Job request (see Section 4.3.3.1), with the addition of the
   following Group 1 operation attribute:

      "job-hold-until" (type2 keyword | name(MAX)):

      The Client MAY supply and the Printer MUST support this operation
      attribute in a Hold-Job request if it supports the
      "job-hold-until" Job Template attribute in Job Creation requests.
      See Section 5.2.2.  The Printer SHOULD support the
      "job-hold-until" Job Template attribute for use in Job Creation
      requests with at least the 'indefinite' value, if it supports the
      Hold-Job operation.  Otherwise, a Client cannot create a Job and
      hold it immediately (without picking some supported time period in
      the future).

      If supplied and supported as specified in the Printer's
      "job-hold-until-supported" attribute, the Printer copies the
      supplied operation attribute to the Job, replacing the Job's
      previous "job-hold-until" attribute, if present, and makes the Job
      a candidate for scheduling during the supplied named time period.

      If supplied but either the "job-hold-until" operation attribute
      itself or the value supplied is not supported, the Printer accepts
      the request, returns the unsupported attribute or value in the
      Unsupported Attributes group according to Section 4.1.7, returns
      the 'successful-ok-ignored-or-substituted-attributes' status-code,
      and holds the Job indefinitely until a Client performs a
      subsequent Release-Job operation.

      If (1) the Client supplies either a value that specifies a time
      period that has already started or the 'no-hold' value (meaning
      don't hold the Job) and (2) the Printer supports the
      "job-hold-until" operation attribute and there are no other
      reasons to hold the Job, the Printer MUST accept the operation and
      make the Job be a candidate for processing immediately (see
      Section 5.2.2).

      If the Client does not supply a "job-hold-until" operation
      attribute in the request, the Printer MUST populate the Job with a
      "job-hold-until" attribute with the 'indefinite' value (if the
      Printer supports the "job-hold-until" attribute) and hold the Job
      indefinitely, until a Client performs a Release-Job operation.

4.3.5.2.  Hold-Job Response

   The groups and attributes are the same as those defined for a
   Cancel-Job response (see Section 4.3.3.2).

4.3.6.  Release-Job Operation

   This OPTIONAL operation allows a Client to release a previously held
   Job so that it is again eligible for scheduling.  If the Hold-Job
   operation is supported, then the Release-Job operation MUST be
   supported, and vice versa.

   This operation removes the "job-hold-until" Job attribute, if
   present, from the Job that had been supplied in the Create-Job or
   most recent Hold-Job or Restart-Job operation and removes its effect
   on the Job.  The Printer MUST remove the "job-hold-until-specified"
   value from the Job's "job-state-reasons" attribute, if present.  See
   Section 5.3.8.

   The Printer MUST accept or reject the request based on the Job's
   current state and transition the Job to the indicated new state as
   shown in Table 6.

   Access Rights: The authenticated user (see Section 9.3) performing
   this operation must be either the Job owner or an Operator or
   Administrator of the Printer (see Sections 1 and 9.5).  Otherwise,
   the Printer MUST reject the operation and return
   'client-error-forbidden', 'client-error-not-authenticated', or
   'client-error-not-authorized' as appropriate.

   The Release-Job request and Release-Job response have the same
   attribute groups and attributes as the Cancel-Job operation (see
   Sections 4.3.3.1 and 4.3.3.2).

   +-------------------+--------------------+--------------------------+
   | Current "job-     | New "job-state"    | Printer's response       |
   | state"            |                    | status-code and action:  |
   +-------------------+--------------------+--------------------------+
   | 'pending'         | 'pending'          | 'successful-ok'.  No     |
   |                   |                    | effect on the Job.       |
   +-------------------+--------------------+--------------------------+
   | 'pending-held'    | 'pending-held'     | 'successful-ok' (note 1) |
   +-------------------+--------------------+--------------------------+
   | 'pending-held'    | 'pending'          | 'successful-ok'          |
   +-------------------+--------------------+--------------------------+
   | 'processing'      | 'processing'       | 'successful-ok'.  No     |
   |                   |                    | effect on the Job.       |
   +-------------------+--------------------+--------------------------+
   | 'processing-      | 'processing-       | 'successful-ok'.  No     |
   | stopped'          | stopped'           | effect on the Job.       |
   +-------------------+--------------------+--------------------------+
   | 'completed'       | 'completed'        | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'canceled'        | 'canceled'         | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'aborted'         | 'aborted'          | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+

                  Table 6: Release-Job State Transitions

   Note 1: If there are other reasons to keep the Job in the
   'pending-held' state, such as 'resources-are-not-ready', the Job
   remains in the 'pending-held' state.  Thus, the 'pending-held' state
   is not just for Jobs that have the "job-hold-until" attribute applied
   to them but is also used for any reason that will keep the Job from
   being a candidate for scheduling and processing, such as
   'resources-are-not-ready'.  See the "job-hold-until" attribute
   (Section 5.2.2).

4.3.7.  Restart-Job Operation

   This DEPRECATED operation allows a Client to restart a Job that is
   retained in the queue after processing has completed (see
   Section 5.3.7.2).

   Note: This operation SHOULD NOT be supported in new implementations,
   since it destroys Printer accounting information.  The Resubmit-Job
   operation [PWG5100.11] is the safe replacement for this operation and
   makes a copy of the Job, assigns a new "job-uri" and "job-id" to the
   copy, and resets the Job progress attributes in the new copy only.

   The Restart-Job operation moves the Job to the 'pending' or
   'pending-held' Job state and restarts at the beginning on the same
   Printer with the same attribute values.  If any of the Documents in
   the Job were passed by reference (Print-URI or Send-URI), the Printer
   MUST refetch the data, since the semantics of Restart-Job are to
   repeat all Job processing.  The Job Status attributes that accumulate
   Job progress, such as "job-impressions-completed",
   "job-media-sheets-completed", and "job-k-octets-processed", MUST be
   reset to 0 so that they give an accurate record of the Job from its
   restart point.  The Job MUST continue to use the same "job-uri" and
   "job-id" attribute values.

   The Printer MUST accept or reject the request based on the Job's
   current state and transition the Job to the indicated new state as
   shown in Table 7.

   Note: In order to prevent a user from inadvertently restarting a Job
   in the middle, the Restart-Job request is rejected when the Job is in
   the 'processing' or 'processing-stopped' state.  If in the future an
   operation is needed to hold or restart Jobs while in either of these
   states, it will be added as an additional operation, rather than
   overloading the Restart-Job operation, so that it is clear that the
   user intended that the current Job not be completed.

   Access Rights: The authenticated user (see Section 9.3) performing
   this operation must be either the Job owner or an Operator or
   Administrator of the Printer (see Sections 1 and 9.5).  Otherwise,
   the Printer MUST reject the operation and return
   'client-error-forbidden', 'client-error-not-authenticated', or
   'client-error-not-authorized' as appropriate.

   +-------------------+--------------------+--------------------------+
   | Current "job-     | New "job-state"    | Printer's response       |
   | state"            |                    | status-code and action:  |
   +-------------------+--------------------+--------------------------+
   | 'pending'         | 'pending'          | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'pending-held'    | 'pending-held'     | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'processing'      | 'processing'       | 'client-error-not-       |
   |                   |                    | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'processing-      | 'processing-       | 'client-error-not-       |
   | stopped'          | stopped'           | possible'                |
   +-------------------+--------------------+--------------------------+
   | 'completed'       | 'pending' or       | 'successful-ok' - Job is |
   |                   | 'pending-held'     | started over.            |
   +-------------------+--------------------+--------------------------+
   | 'completed'       | 'completed'        | 'client-error-not-       |
   |                   |                    | possible' - see Rule 1.  |
   +-------------------+--------------------+--------------------------+
   | 'canceled'        | 'pending' or       | 'successful-ok' - Job is |
   |                   | 'pending-held'     | started over.            |
   +-------------------+--------------------+--------------------------+
   | 'canceled'        | 'canceled'         | 'client-error-not-       |
   |                   |                    | possible' - see Rule 1.  |
   +-------------------+--------------------+--------------------------+
   | 'aborted'         | 'pending' or       | 'successful-ok' - Job is |
   |                   | 'pending-held'     | started over.            |
   +-------------------+--------------------+--------------------------+
   | 'aborted'         | 'aborted'          | 'client-error-not-       |
   |                   |                    | possible' - see Rule 1.  |
   +-------------------+--------------------+--------------------------+

                  Table 7: Restart-Job State Transitions

   Rule 1: If the Job Retention Period has expired for the Job in this
   state, then the Printer rejects the operation.  See Section 5.3.7.2.

4.3.7.1.  Restart-Job Request

   The groups and attributes are the same as those defined for a
   Cancel-Job request (see Section 4.3.3.1), with the addition of the
   following Group 1 operation attribute:

      "job-hold-until" (type2 keyword | name(MAX)):

      The Client MAY supply and the Printer MUST support this operation
      attribute in a Restart-Job request if it supports the
      "job-hold-until" Job Template attribute in Job Creation requests.
      See Section 5.2.2.

      If supplied and supported as specified in the Printer's
      "job-hold-until-supported" attribute, the Printer copies the
      supplied operation attribute to the Job, replacing the Job's
      previous "job-hold-until" attribute, if present, and makes the Job
      a candidate for scheduling during the supplied named time period.
      See Section 5.2.2.

      If supplied but the value is not supported, the Printer accepts
      the request, returns the unsupported attribute or value in the
      Unsupported Attributes group according to Section 4.1.7, returns
      the 'successful-ok-ignored-or-substituted-attributes' status-code,
      and holds the Job indefinitely until a Client performs a
      subsequent Release-Job operation.

      If supplied but the "job-hold-until" operation attribute itself is
      not supported, the Printer accepts the request, returns the
      unsupported attribute with the out-of-band 'unsupported' value in
      the Unsupported Attributes group according to Section 4.1.7,
      returns the 'successful-ok-ignored-or-substituted-attributes'
      status-code, and restarts the Job, i.e., ignores the
      "job-hold-until" attribute.

      If (1) the Client supplies either a value that specifies a time
      period that has already started or the 'no-hold' value (meaning
      don't hold the Job) and (2) the Printer supports the
      "job-hold-until" operation attribute and there are no other
      reasons to hold the Job, the Printer makes the Job a candidate for
      processing immediately (see Section 5.2.2).

      If the Client does not supply a "job-hold-until" operation
      attribute in the request, the Printer removes the "job-hold-until"
      attribute, if present, from the Job.  If there are no other
      reasons to hold the Job, the Restart-Job operation makes the Job a
      candidate for processing immediately (see Section 5.2.2).

4.3.7.2.  Restart-Job Response

   The groups and attributes are the same as those defined for a
   Cancel-Job response (see Section 4.3.3.2).