However, it occurred to me that there is a far simpler approach:
1. Specify that a Printer object MAY contain a Device object, but only one.
2. The new operations on the Device object:
Set-Device-Attributes
Reset-Device
Restart-Device
Non-Process-Run-Out (add-Device?)
Shutdown-Device
Get-Device-Attributes
Pause-Device
Resume-Device
Space-Current-Job (Ok to rename Space-Device and remove job-id?)
have the same "printer-uri" as the target as the Printer object. Its the
new operation codes that indicate that the operation is on the Device
object, not the Printer object.
3. If you have fan-out and want to support the Device object, you need to
support the subordinate Printer objects since they each contain a Device
object.
4. IPP/1.1 had the "output-device-assigned (name)" Job attribute. So the
IPP/1.1 had the beginnings of the Device object and the name of the new
Device object is what goes in the Job's "output-device-assigned (name)" Job
attribute.
ISSUE: How do we represent the name of the Device object?
Does the Device object need a separate REQUIRED "device-name (name(127))
attribute or could the current REQUIRED "printer-name (name(127))" suffice
as both the user friendly name of the Printer and the user friendly name of
the Device (lump of metal), since there is a one-to-one relationship between
the Printer object and the Device object? I suggest that it will simpler
and less confusing to only have the "printer-name" as the user-friendly name
for both objects.
On the other hand, we had agreed in IPP/1.1 NOT to model fan-in. However,
with the introduction of the Device object, could more than one Printer
object represent the same Device object? In other words, does the
introduction of the Device object allow us to model fan-in? If so, then the
Printer object would be "associated with" a Device object, rather than
"contain a" Device object. If so, there is a many-to-one relationship
between Printer objects and Device objects. If so, then we would need the
"device-name (name(127))" attribute for the Device object.
Comments?
Tom
-----Original Message-----
From: Hastings, Tom N [mailto:hastings@cp10.es.xerox.com]
Sent: Monday, November 01, 1999 16:00
To: ipp
Subject: IPP> OPS - Set2 divided into Set2 Printer operations and Set3
Device o perations specs
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