(see [RFC2911], section 4.2.1), the Printer sets the job’s "job-
priority" to the highest value supported (so that the job will print
before any of the other pending jobs). The Printer returns the
target job immediately after the current job(s) in a Get-Jobs
response (see [RFC2911], section 3.2.6) for the ’not-completed’ jobs.
When the current job is completed, canceled, suspended (see section
4.3.1), or aborted, the target of this operation is processed next.
If a client issues this request (again) before the target of the
operation of the original request started processing, the target of
this new request is processed first.
IPP is specified not to require queues for job scheduling, as there
are other implementation techniques for scheduling multiple jobs,
such as re-evaluating a criteria function for each job on a
scheduling cycle. However, if an implementation does implement
queues for jobs, then the Promote-Job operation puts the specified
job at the front of the queue. A subsequent Promote-Job operation
prior to the processing of the first job puts that specified job at
the front of the queue, so that it is "in front" of the previously
promoted job.
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 Promote-Job Request and Promote-Job Response have the same
attribute groups and attributes as does the Cancel-Job operation (see
[RFC2911], section 3.3.3), including the new "job-message-from-
operator" operation attribute (see section 6).
4.4.2. Schedule-Job-After Operation
This OPTIONAL operation allows a client to request that the Printer
schedule the target job so that it will be processed immediately
after the specified predecessor job, all other scheduling factors
being equal. This operation is specially 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
preceding job completes. The preceding job can be in the target
’pending’, ’processing’, or ’processing-stopped’ state. If the
target job is not in the ’pending’ state, or if the predecessor job
is not in the ’pending’, ’processing’, or ’processing-stopped’ state,
the Printer MUST reject the request, and it returns the ’client-
error-not-possible’ status code, as the job cannot have its position
changed.
If the Printer implements the "job-priority" Job Template attribute
(see [RFC2911], section 4.2.1), the Printer sets the job’s "job-
priority" to that of the predecessor job (so that the job will print
after the predecessor job). The Printer returns the target job
immediately after the predecessor in a Get-Jobs response (see
[RFC2911], section 3.2.6) for the ’not-completed’ jobs.
When the predecessor job completes processing or is canceled or
aborted while processing, the target of this operation is processed
next.
If the client does not supply a predecessor job, this operation has
the same semantics as Promote-Job (see section 4.4).
IPP is specified not to require queues for job scheduling, as there
are other implementation techniques for scheduling multiple jobs,
such as re-evaluating a criteria function for each job on a
scheduling cycle. However, if an implementation does implement
queues for jobs, then the Schedule-Job-After operation puts the
specified job immediately after the specified job in the queue. A
subsequent Schedule-Job-After operation specifying the same job will
cause its target job to be placed after that job, even though it is
between the first target job and the specified job. For example,
suppose the job queue consisted of jobs A, B, C, D, and E, in that
order. A Schedule-Job-After with job E as the target and B as the
specified job would result in the following queue: A, B, E, C, D. A
subsequent Schedule-Job-After with Job D as the target and B as the
specified job would result in the following queue: A, B, D, E, C.
In other words, the link between the two jobs in a Schedule-Job-After
operation is not retained; i.e., there is no attribute on either job
that points to the other job as a result of this 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 Schedule-Job-After Request have the same attribute groups and
attributes as does the Cancel-Job operation (see [RFC2911], section
3.3.3), plus the new "job-message-from-operator" operation attribute
(see section 6). In addition, the following operation attribute is
defined:
"predecessor-job-id":
The client OPTIONALLY supplies this attribute. The Printer MUST
support it, if it supports this operation. This attribute
specifies the job after which the target job is to be processed.
If the client omits this attribute, the Printer MUST process the
target job next, i.e., after the current job, if there is one.
The Schedule-Job-After Response has the same attribute groups,
attributes, and status codes as does the Cancel-Job operation (see
[RFC2911], section 3.3.3). The following status codes have
particular meaning for this operation:
’client-error-not-possible’ - The target job was not in the ’pending’
state, or the predecessor job was not in the ’pending’, ’processing’,
or ’processing-stopped’ state.
’client-error-not-found’ - Either the target job or the predecessor
job was not found.
5. Additional Status Codes
This section defines new status codes used by the operations defined
in this document.
5.1. ’server-error-printer-is-deactivated’ (0x050A)
The Printer has been deactivated by the Deactivate-Printer operation
and is only accepting the Activate-Printer (see section 3.5.1), Get-
Job-Attributes, Get-Jobs, Get-Printer-Attributes, and any other Get-
Xxxx operations. An operator can perform the Activate-Printer
operation to allow the Printer to accept other operations.
6. Use of Operation Attributes That Are Messages from the Operator
This section summarizes the usage of the "printer-message-from-
operator" and "job-message-from-operator" operation attributes
[RFC3380] that set the corresponding Printer and Job Description
attributes (see [RFC2911] for the definition of these). These
operation attributes are defined for most of the Printer and Job
operations that operators are likely to perform, respectively, so
that operators can indicate the reasons for their actions.
Table 5 shows the operation attributes defined for use with the
Printer Operations.
Table 5. Operation Attribute Support for Printer Operations
Operation Attribute A B
---------------------------------------------
attributes-charset REQ REQ
attributes-natural-language REQ REQ
printer-uri REQ REQ
requesting-user-name REQ REQ
printer-message-from-operator Note OPT
Legend:
A: Get-Printer-Attributes, Set-Printer-Attributes
B: All other Printer administrative operations, including, but
not limited to, Pause-Printer, Pause-Printer-After-Current-
Job, Resume-Printer, Hold-New-Jobs, Release-Held-New-Jobs,
Purge-Jobs, Enable-Print, Disable-Printer, Restart-
Printer, Shutdown-Printer, and Startup-Printer.
REQ: REQUIRED for a Printer to support.
OPT: OPTIONAL for a Printer to support; the Printer ignores the
attribute if it is not supported.
Note: According to [RFC3380], the Client MUST NOT supply the
"printer-message-from-operator" operation attribute in a
Get-Printer-Attributes or Set-Printer-Attributes operation;
the Printer MUST ignore this operation attribute in these
two operations. Instead, when it is used by an
operator, the client MUST supply the
"printer-message-from-operator" as (one of the) explicit
attributes being set on the Printer object with the
Set-Printer-Attributes operation.
Table 6 shows the operation attributes defined for use with the Job
operations.
Table 6. Operation Attribute Support for Job Operations
Operation Attribute A B C F
---------------------------------------------------------
attributes-charset REQ REQ REQ REQ
attributes-natural-language REQ REQ REQ REQ
printer-uri REQ REQ REQ REQ
job-uri REQ REQ REQ
job-id REQ REQ REQ REQ
requesting-user-name REQ REQ REQ REQ
job-message-from-operator OPT OPT OPT Note
message** OPT OPT OPT n/a
job-hold-until n/a n/a OPT* n/a
Legend:
A: Cancel-Job, Resume-Job, Restart-Job, Promote-Job, Schedule-Job-
After
B: Cancel-Current-Job, Suspend-Current-Job
C: Hold-Job, Release-Job, Reprocess-Job
F: Get-Job-Attributes, Set-Job-Attributes
REQ; REQUIRED for a Printer to support.
OPT: OPTIONAL for a Printer to support; the Printer ignores the
attribute if it is supplied, but not supported.
n/a: not applicable for use with the operation; the Printer ignores
the attribute.
Note: According to [RFC3380], the Client MUST NOT supply the "job-
message-from-operator" operation attribute in a Get-Job-
Attributes or Set-Job-Attributes operation; the Printer MUST
ignore this operation attribute in these two operations.
Instead, when used by an operator, the client MUST supply the
"job-message-from-operator" as (one of the) explicit attributes
being set on the Job object with the Set-Job-Attributes
operation.
*: The Printer MUST support the "job-hold-until" operation
attribute if it supports the "job-hold-until" Job Template
attribute. For the Reprocess-Job operation, the client can
hold the job and then modify the job before releasing it to
be processed.
**: In [RFC2911], the "message" operation attribute is defined to
contain a message to the operator, but [RFC2911] does not
define a Job Description attribute to store the message.
7. New Printer Description Attributes
The following new Printer Description attributes are needed to
support the new operations defined in this document and the concepts
of Printer Fan-Out (see section 10).
7.1. subordinate-printers-supported (1setOf uri)
This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (see section 10) and contains the URIs of the
immediate Subordinate Printer object(s) associated with this Printer
object. Each Non-Leaf Printer object MUST support this Printer
Description attribute. A Leaf Printer object either does not support
the "subordinate-printers-supported" attribute or does so with the
’no-value’ out-of-band value (see [RFC2911], section 4.1), depending
on the implementation.
The precise format of the Subordinate Printer URIs is implementation
dependent (see section 10.4).
If the Printer object does not have an associated Output Device, the
Printer MAY automatically copy the value of the Subordinate Printer
object’s "printer-name" attribute to the Job object’s "output-
device-assigned" attribute (see [RFC2911], section 4.3.13). The
"output-device-assigned" Job attribute identifies the Output Device
to which the Printer object has assigned a job; for example, when a
single Printer object is supporting Device Fan-Out or Printer Fan-
Out.
7.2. parent-printers-supported (1setOf uri)
This Printer attribute is REQUIRED if an implementation supports
Subordinate Printers (see section 10) and contains the URI of the
Non-Leaf printer object(s) for which this Printer object is the
immediate Subordinate; i.e., this Printer’s immediate "parent" or
"parents". Each Subordinate Printer object MUST support this Printer
Description attribute. A Printer that has no parents either does not
support the "parent-printers-supported" attribute or does so with the
’no-value’ out-of-band value (see [RFC2911], section 4.1), depending
on the implementation.
8. Additional Values for the "printer-state-reasons" Printer
Description Attribute
This section defines additional values for the "printer-state-
reasons" Printer Description attribute.
8.1. ’hold-new-jobs’ Value
’hold-new-jobs’: The operator has issued the Hold-New-Jobs operation
(see section 3.3.1) or other means, but the output-device(s) are
taking an appreciable time to stop. Later, when all output has
stopped, the "printer-state" becomes ’stopped’, and the ’paused’
value replaces the ’moving-to-paused’ value in the "printer-
state-reasons" attribute. This value MUST be supported if the
Hold-New-Jobs operation is supported and the implementation takes
significant time to pause a device in certain circumstances.
8.2. ’deactivated’ Value
’deactivated’: A client has issued a Deactivate-Printer operation
for the Printer object (see section 3.4.1), and the Printer is in
the process of becoming deactivated or has become deactivated.
The Printer MUST 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), and then return the
’server-error-service-unavailable’ status code.
9. Additional Values for the "job-state-reasons" Job Description
Attribute
This section defines additional values for the "job-state-reasons"
Job Description attribute.
9.1. ’job-suspended’ Value
’job-suspended’: While job processing has been suspended by the
Suspend-Current-Job operation, other jobs can be processed on the
Printer. The Job can be resumed with the Resume-Job operation,
which removes this value.
10. Use of the Printer Object to Represent IPP Printer Fan-Out and IPP
Printer Fan-In
This section defines how the Printer object MAY be used to represent
IPP Printer Fan-Out and IPP Printer Fan-In. In Fan-Out, an IPP
Printer is used to represent other IPP Printer objects. In Fan-In,
several IPP Printer objects are used to represent another IPP Printer
object.
10.1. IPP Printer Fan-Out
The IPP/1.1 Model and Semantics introduces the semantic concept of an
IPP Printer object that represents more than one Output Device (see
[RFC2911], section 2.1). This concept is called "Output Device Fan-
Out". However, with Fan-Out there was no way to represent the
individual states of the Output Devices or to perform operations on a
specific Output Device. This document generalizes the semantics of
the Printer object to represent Subordinate Fan-Out Output Devices
such as IPP Printer objects. This concept is called "Printer object
Fan-Out". A Printer object that has a Subordinate Printer object is
called a Non-Leaf Printer object. Thus, a Non-Leaf Printer object
supports one or more Subordinate Printer objects in order to
represent Printer object Fan-Out. A Printer object that does not
have any Subordinate Printer objects is called a Leaf Printer object.
Each Non-Leaf Printer object submits jobs to its immediate
Subordinate Printers and otherwise controls the Subordinate Printers
by using IPP or other protocols. Whether pending jobs are kept in
the Non-Leaf Printer until a Subordinate Printer can accept them or
are kept in the Subordinate Printers depends on implementation and/or
configuration policy. Furthermore, a Subordinate Printer object MAY,
in turn, have Subordinate Printer objects. Thus a Printer object can
be both a Non-Leaf Printer and a Subordinate Printer.
A Subordinate Printer object MUST be a conforming Printer object, so
it MUST support all of the REQUIRED [RFC2911] operations and
attributes. However, with access control, the Subordinate Printer
MAY be configured so that end-user clients are not permitted to
perform any operations (or just Get-Printer-Attributes) while one or
more Non-Leaf Printer object(s) are permitted to perform any
operation.
10.2. IPP Printer Fan-In
The IPP/1.1 Model and Semantics did not preclude the semantic concept
of multiple IPP Printer objects that represent a single Output Device
(see [RFC2911], section 2.1). However, there was no way for the
client to determine whether there was a Fan-In configuration; nor was
there a way to perform operations on the Subordinate device. This
specification generalizes the semantics of the Printer object to
allow several Non-Leaf IPP Printer objects to represent a single
Subordinate Printer object. Thus a Non-Leaf Printer object MAY share
a Subordinate Printer object with one or more other Non-Leaf Printer
objects in order to represent IPP Printer Fan-In.
As with Fan-Out (see section 10.1), when a Printer object is a Non-
Leaf Printer, it MUST NOT have an associated Output Device. As with
Fan-Out, a Leaf Printer object has one or more associated Output
Devices. As with Fan-Out, the Non-Leaf Printer objects submit jobs
to their Subordinate Printer objects and otherwise control the
Subordinate Printer. As with Fan-Out, whether pending jobs are kept
in the Non-Leaf Printers until the Subordinate Printer can accept
them or are kept in the Subordinate Printer depends on the
implementation and/or configuration policy.
10.3. Printer Object Attributes Used to Represent Printer Fan-Out and
Printer Fan-In
The following Printer Description attributes are defined to represent
the relationship between Printer object(s) and their Subordinate
Printer object(s):
1. "subordinate-printers-supported" (1setOf uri) - Contains the
URI of the immediate Subordinate Printer object(s).
2. "parent-printers-supported (1setOf uri) - Contains the URI of
the Non-Leaf printer object(s) for which this Printer object is
the immediate Subordinate; i.e., this Printer’s immediate
"parent" or "parents".
10.4. Subordinate Printer URI
Each Subordinate Printer object has a URI used as the target of each
operation on the Subordinate Printer. The means to configure URIs
for Subordinate Printer objects is implementation-dependent, as are
all URIs. However, there are two distinct approaches:
a. When the implementation seeks to make sure that no operation on
a Subordinate Printer object "sneaks by" the parent Printer
object (or that no Subordinate Printer is fronting for a device
that is not networked), the host part of the URI specifies the
host of the parent Printer. Then the parent Printer object can
easily reflect the state of the Subordinate Printer objects in
the parent’s Printer object state and state reasons as the
operation passes "through" the parent Printer object.
b. When the Subordinate Printer is networked and the
implementation allows operations to go directly to the
Subordinate Printer (with proper access control) without
knowledge of the parent Printer object, the host part of the
URI is different from the host part of the parent Printer
object. In this a case, the parent Printer object MAY keep its
"printer-state" and "printer-state-reasons" up to date, either
by polling the Subordinate Printer object or by subscribing to
events with the Subordinate Printer object (see [RFC3995] for
means to subscribe to event notification when the Subordinate
Printer object supports IPP notification). Alternatively, the
parent Printer MAY wait until its "printer-state" and
"printer-state-reasons" attributes are queried and then query
all its Subordinate Printers in order to return the correct
values.
10.5. Printer Object Attributes Used to Represent Output Device Fan-Out
Only Leaf IPP Printer objects are allowed to have one or more
associated Output Devices. Each Leaf Printer object MAY support the
"output-devices-supported" (1setOf name(127)) to indicate the user-
friendly name(s) of the Output Device(s) that the Leaf Printer object
represents. It is RECOMMENDED that each Leaf Printer object have
only one associated Output Device, so that the individual Output
Devices can be represented completely and controlled completely by
clients. In other words, the Leaf Printer’s "output-devices-
supported" attribute SHOULD have only one value.
Non-Leaf Printer MUST NOT have associated Output Devices. However, a
Non-Leaf Printer SHOULD support an "output-devices-supported" (1setOf
name(127)) Printer Description attribute that contains all the values
of its immediate Subordinate Printers. As these Subordinate Printers
MAY be Leaf or Non-Leaf, the same rules apply to them. Thus any
Non-Leaf Printer SHOULD have an "output-devices-supported" (1setOf
name(127)) attribute that contains all the values of the Output
Devices associated with Leaf Printers of its complete sub-tree.
When a configuration of Printers and Output Devices is added, moved,
or changed, there can be moments when the tree structure is not
consistent; i.e., times when a Non-Leaf Printer’s "subordinate-
printers-supported" does not agree with the Subordinate Printer’s
"parent-printers-supported". Therefore, the operator SHOULD first
Deactivate all Printers being configured in this way, update all
pointer attributes, and then reactivate them. A useful client tool
would validate a tree structure before Activating the Printers
involved.
10.6. Figures to Show All Possible Configurations
Figures 1, 2, and 3 are taken from [RFC2911] to show the
configurations possible with IPP/1.0 and IPP/1.1 where all Printer
objects are Leaf Printer objects. The remaining figures show
additional configurations using Non-Leaf and Leaf Printer objects.
Legend:
----> indicates a network protocol with the direction of its requests
##### indicates a Printer object that is either
embedded in an Output Device, or
hosted in a server.
The Printer object might or might not be capable
of queuing/spooling.
any indicates any network protocol or direct
connect, including IPP.
Output Device
+---------------+
| ########### |
O +--------+ | # (Leaf) # |
/|\ | client |------------IPP-----------------># Printer # |
/ \ +--------+ | # Object # |
| ########### |
+---------------+