At the IPP telecon we reached the following agreements which I'll put into
an updated Set2 spec today for the L.A. meeting, 12/15/99:
1. We'll decide on final names for the Set2 and Set3 operations next week in
L.A. after we understand and agree to the semantics for each operation.
2. Instead of Quiesce-Printer, Restart-Printer, Quiesce-Device, and
Restart-Device, we will use the working names: Deactivate-Printer,
Activate-Printer, Deactivate-Device, and Activate-Device. These should be
more easily translatable to non-English and more easily understood by
non-English speakers. These operations allow the Printer to be queried and
the Printer and Device to be Activated. They don't initialize the software,
so they aren't used to recover when the software gets confused. They are
used to just make the Printer or Device by read-only and not do anything.
They MUST be implemented in pairs.
3. Reset-Device does reinitialize the software as well as resetting the
hardware. It has the same semantics as the Printer MIB reset.
4. Restart-Printer also re-initializes the software, so that if the software
processes/threads have become corrupted, the Restart-Printer straightens it
out.
5. Some people want a Shutdown-Printer which cannot be brought back to life.
Instead, the operation uses a Restart-Printer to start up a new
instantiation of the Printer object (with the same URL).
6. Power-Off Device cannot be brought back with any IPP operation. If the
IPP Printer is embedded in the output device, then Power-Off also affects
the IPP Printer. However, if the IPP Printer is hosted, then it is
unaffected by the Power-Off Device operation. This is one case where the
semantics of the operations would appear to depend on the configuration.
However, Power-Off does first write the state of the software to persistent
storage, so that when the device is started (by means outside the protocol),
the jobs are not lost.
7. Instead of Pause-Printer "when" = 'after-current-job',
'after-all-current-jobs'
and Pause-Device "when" = 'now', 'after-current-copy' have four distinct
operations that can be implemented or not and queries for support:
Pause-Printer-After-Current-Job = what Pause-Printer in IPP/1.1 is
Pause-Printer-After-All-Current-Jobs
Pause-Device-Now
Pause-Device-After-Current-Copy
ISSUE: However, Pause-Printer is already published in IPP/1.1 with the
following general implementation-dependent options:
This OPTIONAL operation allows a client to stop the Printer object
from scheduling jobs on all its devices. Depending on implementation, the
Pause-Printer operation MAY also stop the Printer from processing the
current job or jobs. Any job that is currently being printed is either
stopped as soon as the implementation permits or is completed, depending on
implementation. The Printer object MUST still accept create operations to
create new jobs, but MUST prevent any jobs from entering the 'processing'
state.
The IPP Printer stops the current job(s) on its device(s) that were
in the 'processing' or 'processing-stopped' states as soon as the
implementation permits. If the implementation will take appreciable time to
stop, the IPP Printer adds the 'moving-to-paused' value to the Printer
object's "printer-state-reasons" attribute (see section 4.4.12). When the
device(s) have all stopped, the IPP Printer transitions the Printer object
to the 'stopped' state, removes the 'moving-to-paused' value, if present,
and adds the 'paused' value to the Printer object's "printer-state-reasons"
attribute.
So are we changing the IPP/1.1 Pause-Printer definition by nailing down what
had been implementation-dependent options? Or are we adding two additional
Pause-Printer operations?
So we have the following operations with the following working names. The
actual names will be selected in L.A. after the semantics are agreed:
Printer operation Corresponding Device operation
----------------- ------------------------------
Pause-Printer-After-Current-Job Pause-Device-Now
Pause-Printer-After-All-Current-Jobs Pause-Device-After-Current-Copy
Resume-Printer Resume-Device
Purge-Jobs Purge-Device
Get-Printer-Attribute no
Set-Printer-Attributes no
Disable-Printer Disable-Device
Enable-Printer Enable-Device
Deactivate-Printer Deactivate-Device
Activate-Printer Activate-Device
Restart-Printer Reset-Device -- these 2 lines aren't
pairs
Shutdown-Printer Power-Off-Device
6. Printer operations MUST NOT be forwarded
Job operations MUST be forwarded to affect the intended job wherever it
is
Device operations MUST NOT be forwarded when there is fan-out of any kind
(output-device fan-out or Printer object fan-out)
Device operations MUST be forwarded if there is only one subordinate
Printer (the chained case), so that there is no difference to an operator
client whether the first Printer is using IPP or some other protocol to
control the downstream device (singular).
7. There will not be any roll-up of fan-out device state or Printer object
state, and state-reasons, except the "printer-state" 'stopped' and the
'stopped-partly' printer-state-reasons.
Therefore, we don't need the 'device-xxx-failed' set of values. If a Device
operation fails, then the 'moving-to-xxx' state reason is removed and that
indicates the failure.
We probably need the two values for the following Device operations,
(including the new or renamed ones suggested above):
device-moving-to-disabled, devices-disabled
device-moving-to-enabled, *
device-moving-to-purged, devices-purged
device-moving-to-quiescent, devices-quiescent
device-moving-to-restarted, *
device-moving-to-reset, *
device-moving-to-powered-off, devices-powered-off
Send comments to the DL.
Thanks,
Tom