IPP> OPS - Comments on Set2 and Set3 operations: IPP Printer versus D evice object and operation semantics

IPP> OPS - Comments on Set2 and Set3 operations: IPP Printer versus D evice object and operation semantics

IPP> OPS - Comments on Set2 and Set3 operations: IPP Printer versus D evice object and operation semantics

Hastings, Tom N hastings at cp10.es.xerox.com
Tue Dec 7 18:31:02 EST 1999


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





More information about the Ipp mailing list