to an Output Device, the
"printer-state" becomes
’stopped’, and the ’paused’
value replaces the ’moving-to-
paused’ value in the "printer-
state-reasons" attribute
’processing’ ’stopped’ ’paused’ REQUIRED: ’successful-ok’;
the IPP Printer wasn’t in the
middle of sending an IPP job
to an Output Device
’stopped’ ’stopped’ ’paused’ REQUIRED: ’successful-ok’
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Pause-Printer-After-Current-Job Request and Pause-Printer-After-
Current-Job Response have the same attribute groups and attributes as
does the Pause-Printer operation (see [RFC2911], sections 3.2.7.1 and
3.2.7.2), including the new "printer-message-from-operator" operation
attribute (see section 6).
3.3. Hold and Release New Jobs Operations
This section defines operations to condition the Printer to hold any
new jobs and to release them.
3.3.1. Hold-New-Jobs Operation
This OPTIONAL operation allows a client to condition the Printer to
complete the current ’pending’ and ’processing’ IPP Jobs but not to
start processing any subsequently created IPP Jobs. If the IPP
Printer is in the middle of sending an IPP job to an Output Device or
Subordinate Printer, the IPP Printer MUST complete sending that Job.
Furthermore, the IPP Printer MUST send all of the current ’pending’
IPP Jobs to the Output Device(s) or Subordinate IPP Printer
object(s). Any subsequently received Job Creation operations will
cause the IPP Printer to put the Job into the ’pending-held’ state,
with the ’job-held-on-create’ value being added to the job’s "job-
state-reasons" attribute. Thus all newly accepted jobs will be
automatically held by the Printer.
When the Printer completes all the ’pending’ and ’processing’ jobs,
it enters the ’idle’ state as usual. An operator monitoring Printer
state changes will know when the Printer has completed all current
jobs because the Printer enters the ’idle’ state.
This operation MUST NOT affect the acceptance of Job Creation
requests (see Disable-Printer Operation, section 3.1.1), except to
put the Jobs into the ’pending-held’ state, instead of the ’pending’
or ’processing’ state.
The IPP Printer MUST accept the request in any state, MUST NOT
transition the Printer to any other "printer-state", and MUST add the
’hold-new-jobs’ value to the Printer’s "printer-state-reasons"
attribute (whether the value was present or not).
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Hold-New-Jobs Request and Hold-New-Jobs Response have the same
attribute groups and attributes as does the Pause-Printer operation
(see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new
"printer-message-from-operator" operation attribute (see section 6).
3.3.2. Release-Held-New-Jobs Operation
This OPTIONAL operation allows a client to undo the effect of a
previous Hold-New-Jobs operation. In particular, the Printer
releases all the jobs that it held as a consequence of a Hold-New-
Jobs operations; i.e., while the ’hold-new-jobs’ value was present in
the Printer’s "printer-state-reasons" attribute. In addition, the
Printer MUST accept this request in any state, MUST NOT transition
the Printer to any other "printer-state", and MUST remove the ’hold-
new-jobs’ value from its "printer-state-reasons" attribute (whether
the value was present or not) so that the Printer no longer holds
newly created jobs.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Release-Held-New-Jobs Request and Release-Held-New-Jobs Response
have the same attribute groups and attributes as the Pause-Printer
operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
the new "printer-message-from-operator" operation attribute (see
section 6).
3.4. Deactivate and Activate Printer Operations
This section defines the OPTIONAL Deactivate-Printer and Activate-
Printer operations that stop and start the IPP Printer object from
accepting all requests except queries and performing work. If either
of these operations are supported, both MUST be supported.
These operations allow the operator to put the Printer into a dormant
read-only condition and to take it out of this condition.
3.4.1. Deactivate-Printer Operation
This OPTIONAL operation allows a client to stop the Printer object
from sending IPP jobs to any of its Output Devices or Subordinate
Printers (Pause-Printer-After-Current-Job) and to stop the Printer
object from accepting any requests but query requests. The Printer
performs a Disable-Printer and a Pause-Printer-After-Current-Job
operation immediately. If these two operations cannot be completed
immediately, it includes use of all of the "printer-state-reasons".
In addition, the Printer MUST immediately reject all requests, except
for Activate-Printer, queries (Get-Printer-Attributes, Get-Job-
Attributes, Get-Jobs, etc.), Send-Document, and Send-URI (so that
partial job submission can be completed, see section 3.1.1). The
Printer MUST then return the ’server-error-service-unavailable’
status code.
The IPP Printer MUST accept the request in any state. Immediately,
the Printer MUST set the ’deactivated’ value in its "printer-state-
reasons" attribute. Note: neither the Disable-Printer nor the
Pause-Printer-After-Current-Job set the ’deactivated’ value.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Deactivate-Printer Request and Deactivate-Printer Response have
the same attribute groups and attributes as does the Pause-Printer
operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
the new "printer-message-from-operator" operation attribute (see
section 6).
3.4.2. Activate-Printer Operation
This OPTIONAL operation allows a client to undo the effects of the
Deactivate-Printer; i.e., it allows the Printer object to start
sending IPP jobs to any of its Output Devices or Subordinate Printers
(Pause-Printer-After-Current-Job) and starts the Printer object from
accepting any requests. The Printer performs an Enable-Printer and a
Resume-Printer operation immediately. In addition, the Printer MUST
immediately start accepting all requests.
The IPP Printer MUST accept the request in any state. The Printer
MUST immediately remove the ’deactivated’ value from its "printer-
state-reasons" attribute (whether it is present or not).
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Activate-Printer Request and Activate-Printer Response have the
same attribute groups and attributes as the Pause-Printer operation
(see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including the new
"printer-message-from-operator" operation attribute (see section 6).
3.5. Restart-Printer, Shutdown-Printer, and Startup-Printer Operations
This section defines the OPTIONAL Restart-Printer, Shutdown-Printer,
and Startup-Printer operations that initialize, shutdown, and start
up the Printer object, respectively. Each of these operations is
OPTIONAL, and any combination MAY be supported.
3.5.1. Restart-Printer Operation
This OPTIONAL operation allows a client to restart a Printer object
whose operation is in need of initialization because of incorrect or
erratic behavior; i.e., perform the effect of a software re-boot.
The implementation MUST attempt to save any information about Jobs
and the Printer object before re-initializing. However, this
operation MAY have drastic consequences on the running system, so the
client SHOULD first try the Deactivate-Printer operation to minimize
the effect on the current state of the system. The effects of
previous Disable-Printer, Pause Printer, and Deactivate-Printer
operations are lost.
The IPP Printer MUST accept the request in any state. The Printer
object MUST initialize its Printer’s "printer-state" to ’idle’,
remove the state reasons from its "printer-state-reasons" attribute,
and change its "printer-is-accepting-jobs" attribute to ’true’.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Restart-Printer Request and Restart-Printer Response have the
same attribute groups and attributes as does the Pause-Printer
operation (see [RFC2911], sections 3.2.8.1 and 3.2.8.2), including
the new "printer-message-from-operator" operation attribute (see
section 6).
3.5.2. Shutdown-Printer Operation
This OPTIONAL operation allows a client to shutdown a Printer; i.e.,
to stop processing jobs without losing any jobs and to make the
Printer object unavailable for any operations using the IPP protocol.
There is no way to bring the instance of the Printer object back to
being used, except for the Startup-Printer (see section 3.5.3), which
starts up a new instance of the Printer object for hosted
implementations. The purpose of Shutdown-Printer is to shutdown the
Printer for an extended period, not to reset the device(s) or modify
a Printer attribute. See Restart-Printer (section 3.5.1) and
Startup-Printer (section 3.5.3) for the way to initialize the
software. See the Disable-Printer operation (section 3.1) for a way
for the client to stop the Printer from accepting Job Creation
requests without stopping processing or shutting down.
The Printer MUST add the ’shutdown’ value (see [RFC2911], section
4.4.11) immediately to its "printer-state-reasons" Printer
Description attribute. It then performs a Deactivate-Printer
operation (see section 3.4.1), which in turn performs Disable-Printer
and Pause-Printer-After-Current-Job operations).
Note: To shutdown the Printer after all the currently submitted jobs
have completed, the operator issues a Disable-Printer operation (see
section 3.1.1) and then waits until all the jobs have completed. The
Printer goes into the ’idle’ state before issuing the Shutdown-
Printer operation.
The Printer object MUST accept this operation in any state and
transition the Printer object through the "printer-states" and
"printer-state-reasons" defined for the Pause-Printer-After-Current-
Job operation until the activity is completed and the Printer object
disappears.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Shutdown-Printer Request and Shutdown-Printer Response have the
same attribute groups and attributes as does the Pause-Printer
operation (see [RFC2911], sections 3.2.7.1 and 3.2.7.2), including
the new "printer-message-from-operator" operation attribute (see
section 6).
3.5.3. Startup-Printer operation
This OPTIONAL operation allows a client to start up an instance of a
Printer object, provided that there isn’t one already initiated. The
purpose of Startup-Printer is to allow a hosted implementation of the
IPP Printer object (i.e., a Server that implements an IPP Printer on
behalf of a networked or local Output Device) to be started after the
host is available (by means outside this document). See section
3.5.1 for the way to initialize the software or reset the Output
Device(s) when the IPP Printer object has already been initiated.
The host MUST accept this operation only when the Printer object has
not been initiated. If the Printer object already exists, the host
must return the ’client-error-not-possible’ status code.
The result of this operation MUST be with the Printer object’s
"printer-state" set to ’idle’, the state reasons removed from its
"printer-state-reasons" attribute, and its "printer-is-accepting-
jobs" attribute set to ’false’. Then the operator can reconfigure
the Printer before performing an Enable-Printer operation. However,
when a Printer is first powered up, it is RECOMMENDED that its
"printer-is-accepting-jobs" attribute be set to ’true’ in order to
achieve easy "out of the box" operation.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Shutdown-Printer Request and Shutdown-Printer Response have the
same attribute groups and attributes as does the Pause-Printer
operation (see [RFC2911] sections 3.2.7.1 and 3.2.7.2), including the
new "printer-message-from-operator" operation attribute (see section
6).
4. Definition of the Job Operations
All Job operations are directed at Job objects. A client MUST always
supply some means to identify the Job object in order to select the
correct target of the operation. That job identification MAY either
be a single Job URI or a combination of a Printer URI and a Job ID.
The IPP object implementation MUST support both forms of
identification for every job.
The Job Operations defined in this document are summarized in Table
4.
Table 4. Job Operation Operation-Id Assignments
Operation Name Operation-Id Brief description
--------------------------------------------------------------------
Reprocess-Job 0x2C Creates a copy of a completed target
job with a new Job ID and processes it.
Cancel-Current- 0x2D Cancels the current job on the target
Job Printer or the specified job if it is
the current job.
Suspend- 0x2E Suspends the current processing job on
Current-Job the target Printer or the specified
job if it is the current job, allowing
other jobs to be processed instead.
Resume-Job 0x2F Resumes the suspended target job.
Promote-Job 0x30 Promotes the pending target job to be
next after the current job(s) complete.
Schedule-Job- 0x31 Schedules the target job immediately
After after the specified job, all other
scheduling factors being equal.
4.1. Reprocess-Job Operation
This OPTIONAL operation is a create job operation that allows a
client to re-process a copy of a job that had been retained in the
queue after processing was completed, canceled, or aborted (see
[RFC2911], section 4.3.7.2). This operation is the same as the
Restart-Job operation (see [RFC2911], section 3.3.7), except that the
Printer creates a new job that is a copy of the target job and the
target job is unchanged. New values are assigned to the "job-uri"
and "job-id" attributes. The new job’s Job Description attributes
that track job progress, such as "job-impressions-completed", "job-
media-sheets-completed", and "job-k-octets-processed", are
initialized to 0, as with any create job operation. The target job
moves to the Job History after a suitable period, independent of
whether one or more Reprocess-Job operations have been performed upon
it.
If the Set-Job-Attributes operation is supported, then the "job-
hold-until" operation attribute MUST be supported with at least the
’indefinite’ value, so that a client can modify the new job before it
is scheduled for processing by using the Set-Job-Attributes
operation. After modifying the job, the client can release the job
for processing by using the Release-Job operation specifying the
newly assigned "job-uri" or "job-id" for the new job.
4.2. Cancel-Current-Job Operation
This OPTIONAL operation allows a client to cancel the current job on
the target Printer or the specified job if it is the current job on
the Printer. See [RFC2911], section 3.3.3, for the semantics of
canceling a job. Since a Job might already be marking by the time a
Cancel-Current-Job is received, some media sheet pages might print
before the job is actually terminated.
If the client does not supply a "job-id" operation attribute, the
Printer MUST accept the request and cancel the current job if there
is a current job in the ’processing’ or ’processing-stopped’ state;
otherwise, it MUST reject the request and return the ’client-error-
not-possible’ status code. If more than one job is in the
’processing’ or ’processing-stopped’ state, the one that is marking
is canceled, and the others are unaffected.
Warning: On a shared printer, there is a race condition. Between
the time when a user issues this operation and the time of its
acceptance, the current job might change to a different job. If the
user or operator is authenticated to cancel the new job, the wrong
job is canceled. To prevent this race from canceling the wrong job,
the client MAY supply the "job-id" operation attribute, which is
checked against the current job’s job-id. If the job identified by
the "job-id" attribute is not the current job on the Printer (i.e.,
is not in the ’processing’ or ’processing-stopped’ state), the
Printer MUST reject this operation and return the ’client-error-not-
possible’ status code. Otherwise, the Printer cancels the specified
job.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must either be the job owner (as determined
in the Job Creation operation) or an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Cancel-Current-Job Request and Cancel-Current-Job Response have
the same attribute groups and attributes as does the Resume-Printer
operation (see [RFC2911], section 3.2.8), including the new "job-
message-from-operator" operation attribute (see section 6), with the
addition of the following Group 1 Operation attribute in the request:
"job-id" (integer(1:MAX)):
The client OPTIONALLY supplies this Operation attribute to verify
that the identified job is still the current job on the target
Printer object. The IPP object MUST support this operation
attribute if it supports this operation.
4.3. Suspend and Resume Job Operations
This section defines the Suspend-Current-Job and Resume-Job
operations. These operations allow an operator or user to suspend a
job while it is processing, allowing other jobs to be processed, and
to resume the suspended job at a later point without losing any of
the output.
If either of these operations is supported, both MUST be supported.
The Hold-Job and Release-Job operations ([RFC2911], section 3.3.5)
are for holding and releasing held jobs, not suspending and resuming
suspended jobs.
4.3.1. Suspend-Current-Job Operation
This OPTIONAL operation allows a client to stop the current job on
the target Printer or the specified job if it is the current job on
the Printer, to allow other jobs to be processed instead. The
Printer moves the current job or the target job to the ’processing-
stopped’ state and sets the ’job-suspended’ value (see section 9.1)
in the job’s "job-state-reasons" attribute and processes other jobs.
If the client does not supply a "job-id" operation attribute, the
Printer MUST accept the request and suspend the current job if there
is a current job in the ’processing’ or ’processing-stopped’ state.
Otherwise, it MUST reject the request and return the ’client-error-
not-possible’ status code. If more than one job is in the
’processing’ or ’processing-stopped’ state, all of them are
suspended.
Warning: On a shared printer, there is a race condition. Between
the time when a user issues this operation and the time of its
acceptance, the current job might change to a different job. If the
user or operator is authenticated to suspend the new job, the wrong
job is suspended. To prevent this race from pausing the wrong job,
the client MAY supply the "job-id" operation attribute, which is
checked against the current job’s job-id. If the job identified by
the "job-id" attribute is not the current job on the Printer (i.e.,
is not in the ’processing’ or ’processing-stopped’ state), the
Printer MUST reject this operation and return the ’client-error-not-
possible’ status code. Otherwise, the Printer suspends the specified
job and processed other jobs.
The Printer MUST reject a Suspend-Current-Job request (and return the
’client-error-not-possible’) for a job that has been suspended, i.e.,
for a job in the ’processing-stopped’ state, with the ’job-suspended’
value in its "job-state-reasons" attribute.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be either the job owner (as determined
in the Job Creation operation) or an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Suspend-Current-Job Request and Suspend-Current-Job Response have
the same attribute groups and attributes as does the Pause-Printer
operation (see [RFC2911], section 3.2.8 ), including the new "job-
message-from-operator" operation attribute (see section 6), with the
addition of the following Group 1 Operation attribute in the request:
"job-id" (integer(1:MAX)):
The client OPTIONALLY supplies this Operation attribute to verify
that the identified job is still the current job on the target
Printer object. The IPP object MUST support this operation
attribute if it supports this operation.
4.3.2. Resume-Job Operation
This OPTIONAL operation allows a client to resume the target job at
the point where it was suspended. The Printer moves the target job
to the ’pending’ state and removes the ’job-suspended’ value from the
job’s "job-state-reasons" attribute.
If the target job is not in the ’processing-stopped’ state, with the
’job-suspended’ value in the job’s "job-state-reasons" attribute, the
Printer MUST reject the request and return the ’client-error-not-
possible’ status code, since the job was not suspended.
Access Rights: The authenticated user (see [RFC2911], section 8.3)
performing this operation must be either the job owner (as determined
in the Job Creation operation) or an operator or administrator of the
Printer object (see [RFC2911], sections 1 and 8.5).
The Resume-Job Request and Resume-Job Response have the same
attribute groups and attributes as the Release-Job operation (see
[RFC2911], section 3.3.6), including the new "job-message-from-
operator" operation attribute (see section 6).
4.4. Job Scheduling Operations
This section defines jobs that allow an operator to control the
scheduling of jobs.
4.4.1. Promote-Job Operation
This OPTIONAL operation allows a client to make the pending target
job be processed next after the current job completes. This
operation is especially useful in a production printing environment
where the operator is involved in job scheduling.
If the target job is in the ’pending’ state, this operation does not
change the job’s state but causes the job to be processed after the
current job(s) complete. If the target job is not in the ’pending’
state, the Printer MUST reject the request and return the ’client-
error-not-possible’ status code.
If the Printer implements the "job-priority" Job Template attribute