IPP> OPS - Agreements on Set2 from 12/8/99 telecon - comments ?

IPP> OPS - Agreements on Set2 from 12/8/99 telecon - comments ?

IPP> OPS - Agreements on Set2 from 12/8/99 telecon - comments ?

Shepherd, Michael MShepherd at crt.xerox.com
Fri Dec 10 08:36:40 EST 1999


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
| | 
| | 
| 



More information about the Ipp mailing list