The IPP WG reviewed the Set2 specification that Harry and I both had
produced on Friday October 22.
I'll try to get out updated specifications, one for the Set2 Printer
operations and one for the Set3 Device operations for this Wednesday's
telecon. Meanwhile, here is the substance of the decisions for discussion
on the DL immediately and at the telecon:
We addressed the modeling of devices and fanout at great length and came to
the following conclusions:
1. It is better to more cleanly separate the concepts of a logical and
physical object by having to distinct objects: Printer object and Device
object, respectively, rather than overloading the Printer operations with
the "device-name" operation attribute to get the distinction. Then there
can be some different operations on each and some different attributes on
each.
2. Instead of using the "device-name" operation attribute as a way to both
specify fan-out devices and to direct operations to the "lump of metal", we
agreed to drop the idea of a "device-name" operation attribute altogether.
3. Instead, we agreed that for fan-out where the implementation chooses to
expose the devices, each fanned-out device would be represented as an IPP
Printer object whether that device spoke IPP or not and whether that device
was networked or not. Then a client can query the state of each subordinate
Printer object by specifying its target in each Get-Printer-Attributes
operation.
In order to help with terminology, such an IPP Printer object is defined to
be a "subordinate Printer". A new "subordinate-printers-supported (1setOf
uri)" Printer Description attribute will be added to make the fan-out
explicit for implementations that choose to expose the fan-out. A
conforming subordinate Printer does not need to support all of the REQUIRED
operations. For example a subordinate Printer NEED NOT support a Print-Job
operation, unless it is a networked printer that supports the IPP Protocol.
In such a case, the subordinate Printer MAY be configured so that its access
control list only permits the parent Printer to submit jobs to it.
A subordinate Printer can have subordinate Printers.
We also agreed that the degenerate case of a Printer having only a single
subordinate Printer would be disallowed.
The specification will not specify how to construct URIs for subordinate
Printer objects. However, there are two obvious approaches:
a. When the implementation wants to make sure that no operation on a
subordinate Printer as a target sneaks by the "parent" Printer object (or
the subordinate Printer is fronting for devices 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.
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.
4. For the case of controlling or querying the "lump of metal", we introduce
a new Device object whether the "lump of metal" spoke IPP or not and whether
the "lump of metal" was networked or not. The Device object will have its
own URI, operations and attributes. Operations will specify a distinct URI
to be used as the target in the operations defined for the Device object.
The host part of the device will have the same implementation alternatives
as the subordinate Printer in 2 above.
The Set2 operations will be divided between the Printer object and the
Device object as follows:
Printer object operations Device object operations
------------------------- ------------------------
Set-Printer-Attributes Set-Device-Attributes
Enable-Printer
Disable-Printer
Reset-Device
Restart-Printer Restart-Device
Non-Process-Run-Out (add-Device?)
Shutdown-Printer Shutdown-Device
The IPP/1.1 operations are divided as follows:
Printer object operations Device object operations
Get-Printer-Attribute Get-Device-Attributes
Pause-Printer Pause-Device
Resume-Printer Resume-Device
Purge-Jobs
Job operations with Printer object as target and "job-id" as OPTIONALLY
supplied:
Printer object operations Device object operations
------------------------- ------------------------
Space-Current-Job
(Ok to rename Space-Device and remove
job-id?)
The remaining Set2 Job operations remain as they were:
Job object operations
---------------------
Set-Job-Attributes
Reprocess-Job
Cancel-Current-Job (Client can supply "job-id" as a check for intended
job)
Pause-Current-Job (Client can supply "job-id" as a check for intended
job)
Resume-Job
Promote-Job
5. We will separate the Printer operations from the Device operations. The
Printer operations will remain Set2 operations and the Device operations
will become the Set3 operations.
6. The Device object can have Device Description attributes that relate to
the physical device such as input trays, output bins, and finishing
equipment. We briefly discussed that we would probably select a small
subset of the Printer MIB attributes that have really proven useful for the
Device object. However, which Device attributes we need is left for future
work.
7. We also agreed that since implementations will choose different Printer
attributes and Job attributes to allow to be settable, that we would keep
the "printer-settable-attributes" and "job-settable-attributes" as Printer
Description attributes. But since the Interpreter attributes are really
sub-classed Printer attributes, we don't need a
"interpreter-settable-attributes" Printer Description attribute.
Comments?
Tom