Tom,
Sorry I had to leave the telecon before it was over, but I had one point to
make regarding device state roll-up and the following agreement:
|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.
Since you're not going to roll-up the printer object state on fan-out, the
state attributes of the printer object won't accurately reflect the state of
the device(s)/other printer objects which it fans out to. I would suggest
either 1) introducing an 'unknown' printer-state-reason, or 2) defining the
state and state-reason attributes in the fan-out case to only be local to
the node printer object and clearly state to the user that the state doesn't
represent the leaf printers' states.
Also, one other point which comes to mind but I haven't heard discussed is
this... A Fanning-out Printer Object xxx-supported attribute is supposed to
represent all supported values of all leaf printers/devices, correct? If
one of these leaf devices is disabled, shouldn't the fanning-out printer
object's xxx-supported attribute be updated to reflect that these values are
not currently supported?
Thanks,
Mike
| -----Original Message-----
| From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
| Sent: Thursday, December 09, 1999 12:02 PM
| To: ipp
| Cc: Hastings, Tom
| Subject: IPP> OPS - Agreements on Set2 from 12/8/99 telecon -
| comments?
||| 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
||