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 ?

Hastings, Tom N hastings at cp10.es.xerox.com
Thu Dec 9 18:23:07 EST 1999


See my replies.


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


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.


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