This mail message lists the changes, includes the new figures, and included
the remaining 17 issues for the Set2 spec.
Sorry for the short notice. I hope that we can cover some of this in the
IPP telecon tomorrow.
I've updated the Set2 operations paper from the 10/29/99 version that I had
posted after the Raleigh meeting:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991116.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991116.pdfftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991116-rev.docftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set2-991116-rev.pdf
Here are the changes:
14.1 Changes to the November 1, 1999 version to make the November 16,
1999 version
The following changes to the October 22, 1999 version to make the November
1, 1999 version as a result of the IPP WG meeting in Durham, 10/99:
1. Formally defined IPP Printer fan-out, IPP Printer fan-in, and output
device fan-out. Added figures to show IPP Printer fan-out and IPP Printer
fan-in.
2. Added "parent-printers-supported (1setOf uri) Printer Description
attribute to point back up the Printer hierarchy.
3. Added the requirements for forwarding operations that affect Jobs
and for not forwarding operations that affect Printers.
4. Added "original-requesting-user-name" (name(MAX)) to represent the
original end user, not the parent Printer's host.
5. Changed the default for "when" for the Pause-Printer operation from
'after-current-job' to 'now', since that is the behavior in IPP/1.1 where
the "when" operation attribute is not defined.
6. Allowed a non-leaf Printer to have only one subordinate Printer.
7. Changed most of the "parent" Printer terminology to "non-leaf"
Printer to contrast more clearly with "leaf" Printer objects. The term
"parent" is only used when talking about a subordinate's immediate parent
Printer object.
8. Added "original-requesting-user-name" (name (MAX)) to the list of
READ-ONLY Job Description attributes.
I've extracted the new sections about Printer fan-out and Printer fan-in and
included them here:
1 New objects and new relationships of existing objects
This section defines the new Interpreter object and the use of the IPP
Printer object to represent IPP Printer fan-out and IPP Printer fan-in.
1.1 Interpreter object
The Interpreter object models the document format interpreters that are
contained in the Printer object. The purpose of the Interpreter object is
to model those Printer attributes whose value depends on which interpreter
is being used to process the document. Depending on implementation, the
Printer object attributes whose values ("xxx-supported" and "xxx-default")
depend on the interpreter, i.e., on the "document-format" of the document
being processed, are considered to be Interpreter object attributes instead.
A Get-Printer-Attributes operation returns Printer and Interpreter
attributes as specified in the "requested-attributes" operation attribute
supplied by the client. Depending on the value of the "document-format"
attribute supplied by the client in the Get-Printer-Attributes request (or
the "document-format-default", if the client omits the "document-format"
attribute), selects the corresponding Interpreter object.
If an implementation does not make a distinction on the values of Printer
attributes by document format, say, for purposes of job validation (see
[ipp-mod] Get-Printer-Attributes), there is no need to implement or support
the Interpreter object. The Interpreter object is introduced to provide a
means to model an implementation in which some attributes do depend on the
document format. Those attributes are then sub-classed to be Interpreter
object attributes.
Note: the addition of the Interpreter object is completely compatible with
IPP/1.0 and IPP/1.1 (see the description of the "document-format" operation
attribute in [ipp-mod] section 3.2.5.1 Get-Printer-Attributes request). The
protocol and semantics are the same whether or not the Interpreter object is
used to distinguish attributes that depend on the "document-format".
Consequently, there is no "interpreters-supported" Printer Description
attribute. In order to determine which Interpreter objects there MAY be,
the client can request the values of the Printer's
"document-format-supported" attribute.
Note: The Interpreter object is really a sub-class of the Printer object,
rather than being a full fledged object in the sense that the Job and
Printer objects are. There are no operations defined solely for the
Interpreter object. The Get-Printer-Attributes and Set-Printer-Attributes
operations operate on the Interpreter object if the implementation has the
concept of an Interpreter object. However, if the IPP Printer
implementation does not contain Interpreter objects, the same Interpreter
object attributes are considered Printer object attributes, instead.
1.2 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. Fan-out is where an IPP Printer is
used to represent other IPP Printer objects. Fan-in is where several IPP
Printer objects are used to represent another IPP Printer object.
1.2.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 [ipp-mod]
section 2.1). This concept is called "output device fan-out". However,
there was no way to represent the individual states of the output devices or
to perform operations on a specific output device when there was fan-out.
This specification generalizes the semantics of the Printer object to
represent such "subordinate" fan-out output devices 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 MAY support 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.
1.2.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
[ipp-mod] section 2.1). However, there was no way for the client to
determine that 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 2.2), when a Printer object is a
non-leaf, it MUST NOT have an associated output device. As with fan-out, a
leaf Printer object has an associated output device(s). 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
implementation and/or configuration policy.
1.2.3 Printer object attributes used to represent Printer fan-out and
Printer fan-in
Each non-leaf Printer object submits jobs to its immediate subordinate
Printers and otherwise controls the subordinate Printers 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 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.
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). 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 [ipp-mod] section 4.1).
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". 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 [ipp-mod] section 4.1).
Each subordinate Printer object has a URI which is used as the target of
each operation on the subordinate Printer. The means for configuring URIs
for subordinate Printer objects is implementation-dependent as are all URIs.
However, there are two distinct approaches:
a. When the implementation wants to make sure that no
operation on a subordinate Printer object as a target "sneaks by" the parent
Printer object (or the 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 than the host part of the parent
Printer object. In such a case, the parent Printer object MUST 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 [ipp-not-spec] for means to do this when the
subordinate Printer object supports IPP notification).
1.2.4 Printer object attributes used to represent output device fan-out
When a Printer object is a non-leaf, it MUST NOT have an associated output
device. 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 Printer's
"output-devices-supported" attribute SHOULD have only one value.
1.2.5 Figures to show all possible configurations
Figure 1, Figure 2, and Figure 3 are taken from [ipp-mod] 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 that this document defines using non-leaf and leaf Printer
objects. Legend for all figures:
----> indicates a network protocol with the direction of its requests
##### indicates a Printer object which 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 # |
| ########### |
+---------------+
Figure 1 - embedded Printer object
########### output device
O +--------+ # (leaf) # +---------------+
/|\ | client |---IPP----># Printer #---any->| |
/ \ +--------+ # object # | |
########### +---------------+
Figure 2 - hosted Printer object
+---------------+
| |
+->| output device |
########### any/ | |
O +--------+ # (leaf) # / +---------------+
/|\ | client |---IPP----># Printer #--*
/ \ +--------+ # Object # \ +---------------+
########### any\ | |
+->| output device |
| |
+---------------+
Figure 3 - output device fan out
+------IPP--------------------->###########
/ +---># subord. #
/ / # Printer #
/ ########### any # object #
O +--------+ # non-leaf# / ###########
/|\ | client |---IPP----># Printer #--*
/ \ +--------+ # object # \
\ ########### any ###########
\ (non-leaf) \ # subord. #
\ +---># Printer #
+------IPP---------------------># object #
###########
The subordinate Printer can be a non-leaf Printer as in Figure 4 or Figure
5, or can be a leaf Printer as in Figure 1, Figure 2, or Figure 3.
Figure 4 - IPP Printer fan out
(non-leaf)
###########
# non-leaf#
+---># Printer #-+
/ # object # \
IPP ########### \ ###########
O +--------+ / +-IPP-># subord. #
/|\ | client |--+-----------IPP---------------># Printer #
/ \ +--------+ \ +-IPP-># object #
IPP ########### / ###########
\ # non-leaf# /
+---># Printer #-+
# object #
###########
(non-leaf)
The subordinate Printer can be a non-leaf Printer as in Figure 4 or Figure
5, or can be a leaf Printer as in Figure 1, Figure 2, or Figure 3.
Figure 5 - IPP Printer fan in
1.3 Forwarding requests
This section describes the forwarding Job and Printer requests to
subordinate Printer objects.
1.3.1 Forwarding requests that affect Printer objects
In both fan-out and fan-in, the non-leaf IPP Printer object MUST NOT forward
the Printer operations that affect Printer object to its subordinate Printer
objects. If a client wants to explicitly target a subordinate Printer, the
client must specify the URI of the subordinate Printer. Table 1 lists the
operations that affect Printer objects and the forwarding behavior that a
non-leaf Printer MUST exhibit to its immediate subordinate Printers:
Table 1 - Forwarding operations that affect Printer objects
Printer operation Non-leaf Printer action
Set2 Printer operations:
Set-Printer-Attributes MUST NOT forward to any of its subordinate
Printers
Enable-Printer MUST NOT forward to any of its subordinate Printers
Disable-Printer MUST NOT forward to any of its subordinate Printers
Restart-Printer MUST NOT forward to any of its subordinate Printers
Shutdown-Printer MUST NOT forward to any of its subordinate Printers
IPP/1.1 Printer operations:
Get-Printer-Attribute MUST NOT forward to any of its subordinate
Printers
Pause-Printer MUST NOT forward to any of its subordinate Printers
Resume-Printer MUST NOT forward to any of its subordinate Printers
ISSUE 01- Should the purpose of the corresponding device operations, such as
Pause-Device, Disable-Device, and Shutdown-Device (see [ipp-set3], to be
forwarded by Printer objects to their subordinate Printers down to the leaf
Printers objects in order to affect their corresponding output device?
Using device operations in this way would relieve the operator client from
having to work its way down the Printer object chain in order to affect an
output device of a leaf Printer object.
ISSUE 02 - If a Printer object MUST forward a device operation down to the
leaf Printer objects, would fanning out such forwarded device operations be
too drastic? If yes, then maybe the device operations would need an
operation attribute to say whether or not to allow fan-out of device
operations, with the default value being 'false'.
ISSUE 03 - Does the administrator need a Printer object attribute that says
whether or not this Printer object is to forward device operations when it
has more than one subordinate Printer object? The default would be 'false'.
1.3.2 Forwarding requests that affect Jobs
Unlike Printer operations that only affect Printer objects (see section
2.3.1, a non-leaf Printer object MUST forward operations that directly
affect jobs to the appropriate Job object(s) in one or more of its immediate
subordinate Printer objects. Such forwarding MAY be immediate or queued,
depending on the operation and the implementation. For example, a non-leaf
Printer object MAY queue/spool jobs, feeding a job at a time to its
subordinate Printer(s), or MAY forward jobs immediately to one of its
subordinate Printers. In either case, the non-leaf Printer object is
forwarding Job Creation operations to one of its subordinate Printers. Only
the time of forwarding of the Job Creation operations depends on whether the
policy is to queue/spool jobs in the non-leaf Printer or the subordinate
Printer.
When a non-leaf Printer object creates a Job object in its subordinate
Printer, whether that non-leaf Printer object keeps a fully formed Job
object or just keeps a mapping from the "job-ids" that it assigned to those
assigned by its subordinate Printer object is IMPLEMENTATION-DEPENDENT. In
either case, the non-leaf Printer MUST be able to accept and carry out
future Job operations that specify the "job-id" that the non-leaf Printer
assigned and returned to the job submitting client.
Table 2 lists the operations that directly affect jobs and the forwarding
behavior that a non-leaf Printer MUST exhibit to its subordinate Printers:
Table 2 - Forwarding operations that affect Jobs objects
Job operation Non-leaf Printer action
Set2 Job operations:
Set-Job-Attributes MUST forward to the appropriate Job in one
of its subordinate Printers
Reprocess-Job MUST forward to the appropriate Job in one of its
subordinate Printers
Cancel-Current-Job MUST forward to the appropriate Job in one
of its subordinate Printers
Pause-Current-Job MUST forward to the appropriate Job in one of its
subordinate Printers
Resume-Job MUST forward to the appropriate Job in one of its
subordinate Printers
Promote-Job MUST forward to the appropriate Job in one of its
subordinate Printers
IPP/1.1 Printer operations:
Print-Job MUST forward immediately or queue to the appropriate
subordinate Printer
Print-URI MUST forward immediately or queue to the appropriate
subordinate Printer
Validate-Job MUST forward to the appropriate subordinate Printer
Create-Job MUST forward immediately or queue to the appropriate
subordinate Printer
Get-Jobs MUST forward to all its subordinate Printers
Purge-Jobs MUST forward to all its subordinate Printers
IPP/1.1 Job operations:
Send-Document MUST forward immediately or queue to the appropriate
Job in one of its subordinate Printers
Send-URI MUST forward immediately or queue to the appropriate Job in
one of its subordinate Printers
Cancel-Job MUST forward to the appropriate Job in one of its
subordinate Printers
Get-Job-Attributes MUST forward to the appropriate Job in one
of its subordinate Printers, if the non-leaf Printer doesn't know the
complete status of the Job object
Hold-Job MUST forward to the appropriate Job in one of its
subordinate Printers
Release-Job MUST forward to the appropriate Job in one of its
subordinate Printers
Restart-Job MUST forward to the appropriate Job in one of its
subordinate Printers
ISSUE 04 : Do we want to define whether the response to the client for Job
operations can happen before the non-leaf Printer gets the response from its
subordinate Printer or MUST the non-leaf Printer wait until its gets the
response from its subordinate Printer?
The following Job Description attributes are defined to help represent Job
relationships for fan-out and forwarding of jobs:
1. "output-device-assigned" (name(127)) - from [ipp-mod]: This
attribute identifies the output device to which the Printer object has
assigned this job. If an output device implements an embedded Printer
object, the Printer object NEED NOT set this attribute. If a print server
implements a Printer object, the value MAY be empty (zero-length string) or
not returned until the Printer object assigns an output device to the job.
This attribute is particularly useful when a single Printer object supports
multiple devices (so called "fan-out").
2. "original-requesting-user-name" (name(MAX)) - operation attribute
containing the user name of the original user, i.e., corresponds to the
"requesting-user-name" operation attribute that the original client supplied
to the first Printer object.
Here are the 17 remaining issues:
ISSUE 01- Should the purpose of the corresponding device operations, such as
Pause-Device, Disable-Device, and Shutdown-Device (see [ipp-set3], to be
forwarded by Printer objects to their subordinate Printers down to the leaf
Printers objects in order to affect their corresponding output device?
Using device operations in this way would relieve the operator client from
having to work its way down the Printer object chain in order to affect an
output device of a leaf Printer object.
ISSUE 02 - If a Printer object MUST forward a device operation down to the
leaf Printer objects, would fanning out such forwarded device operations be
too drastic? If yes, then maybe the device operations would need an
operation attribute to say whether or not to allow fan-out of device
operations, with the default value being 'false'.
ISSUE 03 - Does the administrator need a Printer object attribute that says
whether or not this Printer object is to forward device operations when it
has more than one subordinate Printer object? The default would be 'false'.
ISSUE 04 : Do we want to define whether the response to the client for Job
operations can happen before the non-leaf Printer gets the response from its
subordinate Printer or MUST the non-leaf Printer wait until its gets the
response from its subordinate Printer?
ISSUE 05 - The "requesting-user-name" operation attribute is the parent
Printer's host, not the original requesting user, correct?)
ISSUE 06 - Presumably the "job-originating-user-name" remains as the
authenticated original user, not the parent Printer's authenticated host,
correct?
ISSUE 07 - Ok not to have a way to reset the values of the Printer object to
the factory settings, but only have a way to reset the factory default
settings for the Device object?
ISSUE 08: What state does the Printer comes back up on Restart-Printer and
how can the client control?
Possible alternatives:
a. Restart-Printer always brings the Printer up Disabled
("printer-is-accepting-jobs" = 'false') and Paused ("printer-state" =
'stopped', and "printer-state-reasons" = 'paused') which is the state that
Shutdown-Printer leaves the Printer in. Then the operator issues
Enable-Printer and Resume-Printer when want to restore normal operation.
The client can automatically issues these addition 2 operations depending on
GUI options. Advantages: This is the simplest to implement, allows new
states to be added without changing the Restart-Printer operation, and can
have the same GUI interface as b:
b. Add a REQUIRED operation attribute to Restart-Printer,
something like "printer-condition" with values: 'disabled-and-paused',
'enabled-and-paused', and 'enabled-and-idle'.
DENVER MEETING> There was significant confusion as to the meaning of
shutdown. If a shutdown operation halts communications to the printer a
restart is not possible. It was agreed to include restart attributes
'restart-to-standby' (requires a two step process), 'restart-fully', and
'restart-sync'.
ACTION ITEM (Harry Lewis): make a complete proposal and submit for
approval.
Issue 09: Why? This is backward, if you ask me (HRL).
Denver meeting> Consider "shutdown-attributes" similar to
Windows "shutdown". Like:
* Completely power off (walk to printer to bring it back up
* Power off but listen for "restart" - shutdown to standby
Denver meeting> Also consider restart attributes.
* Restart to Standby (disabled and paused) (two step bring up)
* Restart (fully).
* Restart sych
*
ISSUE 10 - Need to look at life cycle of the Printer versus
standby/power-down and the other operations that can be accepted. There can
be appreciable time between acceptance of this operation and when the final
state of the printer, either standby or powered down is reached. Is it ok
for non-submission operations to continue to be accepted during this time?
May need 'moving-to-shutdown'. What about 'moving-to-standby'?
TH> Add 'moving-to-shutdown' which the Shutdown-Printer sets
immediately (analogous to 'moving-to-paused'). Then the 'shutdown'
values means that the shutdown has completed (and is only meaningful to
a server implementation that hosts the Printer object). Thus the server
can still respond to a Get-Printer-Attributes operation after the
Printer is shutdown as stated in IPP/1.1.
HRL> Is this granularity really achievable enough of a wide enough
variety of environments to be reliable or, in reality, will this be
implementation dependent?
ISSUE 11 - Ok to remove the 'after-current-copy' value from
Shutdown-Printer?
ISSUE 12 - Ok to have removed the "shutdown-function" operation attribute
with values 'stand-by' vs. 'power-off' Shutdown-Printer on the grounds that
for the Printer object they have no meaning. Power-off is for the
Shutdown-Device operation.
ISSUE 13: Is the current job automatically restarted when the Printer is
restarted? Or does some client have to issue a Restart-Job operation?
ISSUE 14 - Since the semantics of Pause-Current-Job is different from
Pause-Printer, in that other jobs are processed, while this job is stopped,
should we have a different name for the verb, such as Suspend-Current-Job,
instead of Pause-Current-Job. Otherwise, users may be mistakenly think that
the printer is paused when the job is paused. If the name is changes, then
the 'job-paused' job state reason would also be changed to 'job-suspended'.
ISSUE 15 - Ok for Pause-Job to reject a request for a Job that is already
paused (like Cancel-Job), instead of accepting the request?
ISSUE 16 - Ok that the only values for the "when" operation attribute for
the Pause-Current-Job are 'now' and 'after-current-copy' with 'now' being
the default and REQUIRED?
ISSUE 17 - Ok to return an error (like Cancel-Job), rather than having
Resume-Job accept the request even if the Job is already resumed (i.e., not
paused)?