Hi Tom and Harry, Tuesday (7 December 1999)
I generally agree with most of your clarications (below).
I'm concerned about one of them, the ambiguity between
'devices-disabled' (ALL devices are disabled) and the
failure case 'devices-disable-failure' (one or more devices
experienced a failure of 'Disable-Device'). In the failure
case, the state reasons would only indicate that 'disable'
failed for one or more devices (possibly ALL of them),
but would NOT indicate whether 'disable' succeeded for
one or more of the devices (possibly all but ONE of them).
The above ambiguities are the reason I favor saying that
ONLY leaf Printers (one-to-one associated with Devices)
may accept Device operations (these are NOT operations
suitable to the general end user, after all); and neither
Printer nor Device operations may be forwarded. Then
fan-out is disambiguated entirely, and the 'devices-xxx'
state reasons become 'device-xxx' state reasons in all
cases.
One minor nit:
'devices-quiescent-failed' should have been
'devices-quiesce-failed' (the verb, not the adjective)
(Also, at the beginning of your point (6) below you said
'devices-xxx-failure' but MEANT and used 'devices-xxx-failed)
Cheers,
- Ira McDonald (outside consultant at Sharp Labs America)
High North Inc
-----Original Message-----
From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
Sent: Tuesday, December 07, 1999 3:31 PM
To: ipp
Subject: IPP> OPS - Comments on Set2 and Set3 operations: IPP Printer
versus D evice object and operation semantics
Harry and I discussed the paper and have the following comments for the
telecon Wednesday, 12/8/99:
0. Clarify in the introduction that the purpose of this simplification is
so that the semantics of each of the Printer and Device operation have
simple
and consistent rules that are the same for all of the possible
configurations.
1. We think that there should also be a Quiesce-Device and Restart-Device
that goes with Quiesce-Printer and Restart-Printer.
2. We think that there isn't a need for Shutdown-Printer (since exiting the
process is really getting into the implementation too much which doesn't
seem very useful).
2a. The main difference between Quiesce-Device and Shutdown-Device is the
notion of powering off during Shutdown.
3. To avoid misleading interpretations of "Shutdown" based on the PC
paradigm, for example, lets call a spade a spade and rename Shutdown-Device
to Power-Off-Device.
4. Reset-Device needs to be added back. It has been in the operation
proposals before and was inadvertently dropped.
So the complete list of Printer and Device operations would become:
Printer operation Corresponding Device operation
----------------- ------------------------------
Pause-Printer Pause-Device
Resume-Printer Resume-Device
Purge-Jobs Purge-Device
Get-Printer-Attribute no
Set-Printer-Attributes no
Disable-Printer Disable-Device
Enable-Printer Enable-Device
Quiesce-Printer Quiesce-Device
Restart-Printer Restart-Device
no Reset-Device
no Power-Off-Device
5. We think that we need the "when" operation attribute back for the
Pause-Printer and Pause-Device operations only.
5a. Pause-Printer example: The printer may be configured with special media
and the operator may want to "cap" the queue, so to speak, allowing the
current set of jobs that can use the current media to print, but wants to
allow new jobs to be submitted (and placed on hold) which will ultimately
be printed after the operator reconfigures the media (twice).
So the Pause-Printer should be augmented with "when" values:
'after-current-job' and 'after-all-current-jobs'.
The latter causes all future jobs that are submitted to be put into the
'processing-held' state with the 'printer-paused' value added to the job's
"job-state-reasons" attribute. The Printer removes the value when the
operator performs the Resume-Printer operation.
5b. Pause-Device example: The operator may want to remove the current
stacked jobs from the output bin because it is close to filling up or it
is necessary to deliver a partial order.
So the Pause-Device should be augmented with "when" values:
'now' and 'after-current-copy'.
The 'now' value is as soon as the device can pause without losing
anything when the Resume-Device is issued.
Printers MUST support 'after-current-job' if they support the
Pause-Printer operation; 'after-all-current-jobs' is OPTIONAL.
Printers MUST support 'now' if they support the Pause-Device operation;
'after-current-copy' is OPTIONAL.
To help a client know which values are supported, add one "when-supported"
(1setOf type2 keyword) Printer Description attribute that suffices for both
operations, since the values are distinct.
6. Section 5 Forwarding Printer and Device operations
Problem: The client needs a way to know the state of Device operations
We agree that Printer operations MUST never be forwarded, and that Device
operations MAY be forwarded depending on implementation and/or
configuration. And we agree that an implementation that does forward
Device operations to down stream Printer objects or output devices
MUST NOT wait to respond to the Device request before sending or
receiving responses from the down stream devices. Therefore, there
is a period of uncertainty for the client as to when the actual Device
operation(s) will have been accepted and actually completed. But this
uncertainty is no different than if there is no forwarding and there is
only one output device. Some operations actually take time, such as
Pause-Device or Shutdown-Device. Also some of the operations may
actually not complete, either because of network connectivity problems
or other problems encountered while attempting to perform the operation.
Therefore, we suggest that we add 3 "printer-state-reasons" values for each
of the Device operations:
devices-moving-to-xxx one or more devices moving to xxx,
example: devices-moving-to-paused
devices-xxx all devices are in xxx,
example: devices-paused
devices-xxx-failure one or more devices failed to move to xxx,
example: devices-paused-failure
The Printer object that supports a Xxxx Device operation (whether it
forwards or not), MAY support these "printer-state-reasons" values to
indicate to the client what is happening. How the Printer object sets and
removes these values depends on implementation and MAY include polling the
down stream Printer(s) or output device(s), if any. With IPP notification,
the client could subscribe for Printer events that would send a
notification when the "printer-state-reasons" changed, so that the client
would know when the Device operation completed for all devices or failed
for at least one of them.
Of course the best state information is available when fan-out is supported
with subordinate Printers, as in configuration E, as opposed to D, in the
paper. However, these Printer state reasons are still needed whether there
is fan-out or not and whether there is forwarding of Device operations or
not.
We probably need the three values for the following Device operations,
(including the new or renamed ones suggested above):
devices-moving-to-disabled, devices-disabled, devices-disable-failed
devices-moving-to-enabled, *, devices-enable-failed
devices-moving-to-purged, devices-purged, devices-purge-failed
devices-moving-to-quiescent, devices-quiescent, devices-quiescent-failed
devices-moving-to-restarted, *, devices-restart-failed
devices-moving-to-reset, *, devices-restart-failed
devices-moving-to-powered-off, devices-powered-off,
devices-power-off-failed
The * indicate values that are not needed, since the absence of any
corresponding value is a sufficient indication of the condition.
We don't want state reasons to be present all the time under normal
operation, only under exception conditions.
7. Maybe better to call Printer C that feeds only Printer C1 a "chained
Printer" rather than a "cascaded Printer".
8. Section 11.2: Probably more consistent to change the name of
"device-submission-channel-type" to "job-submission-channel-type", because
it is a job attribute and its the "job submission" channel that we are
talking about.
Tom and Harry