Mike,
See my replies.
Tom
-----Original Message-----
From: Shepherd, Michael [mailto:MShepherd at crt.xerox.com]
Sent: Thursday, December 09, 1999 11:39
To: Hastings, Tom N; ipp
Subject: RE: IPP> OPS - Agreements on Set2 from 12/8/99 telecon -
comments ?
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.
TH> I think we are agreeing to alternative 2, with the exception that the
'stopped-partly' will apply to the down stream Printers and/or devices, as
in IPP/1.0.
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?
TH> I don't think so. Consider a single Printer object with no downstream
anything. When I Disable that Printer so it won't accept any jobs, its
"xxx-supported" attribute will remain unchanged, right? So we don't need
any special rules for when there are downstream Printers or output devices,
ok? This even goes for the "operations-supported" attribute itself. When a
Printer is Disabled, we wouldn't expect that the Printer would remove the
'print-job' value from its "operations-supported" attribute, even though the
Printer will reject any Print-Job operations.
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
||