Regarding xxx-supported, I agree with you Tom. But I strongly believe, and
I think we've discussed this before, that we should then add xxx-ready for
more attributes than just the media attribute. xxx-ready would then have
the behavior described below for the fanning-out printer object.
Mike
| -----Original Message-----
| From: Hastings, Tom N [mailto:hastings at cp10.es.xerox.com]
| Sent: Thursday, December 09, 1999 6:23 PM
| To: Shepherd, Michael; ipp
| Subject: RE: IPP> OPS - Agreements on Set2 from 12/8/99 telecon -
| comments ?
||| 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
| |
| |
|