WBMM> More about WBMM operations

WBMM> More about WBMM operations

McDonald, Ira imcdonald at sharplabs.com
Mon Aug 4 00:44:35 EDT 2003


Hi Harry,

1. I suggest that code download (or upload) be treating as 
Create-Resource (with code by reference for resource data)
and Get-Resource (for metadata) and Get-Resource-Data
(for code upload) for the Resource type 'Code' (either
binary executable or a script in some interpreter).

2. An extensibility mechanism - new types of Resources,
with some metadata and (usually) some content data and
standard Resource operations.

Note: ISO DPA sys admin defined the generic 'Control'
operation - my experience with DPA Control has not
been very encouraging (it's sort of roll-your-own RPC
and just as fragile as you would expect).

Cheers,
- Ira McDonald
  High North Inc


-----Original Message-----
From: Harry Lewis [mailto:harryl at us.ibm.com]
Sent: Wednesday, July 30, 2003 6:41 PM
To: McDonald, Ira
Cc: 'wbmm at pwg.org'
Subject: Re: WBMM> More about WBMM operations



Our early proposed WSDL had an "Execute" operation and I know this was
rejected as too generic.  I'm pleased where the set of operations has
evolved to and fully support the alignment with IPP Admin. Great idea!
However, we still feel we need 
1. A code download mechanism 
2. An extensibility mechanism 

Right now, we feel "Execute" would be a good choice to satisfy both. Open
for comment. 
---------------------------------------------- 
Harry Lewis 
Chairman - IEEE-ISTO Printer Working Group
http://www.pwg.org
IBM Printing Systems 
http://www.ibm.com/printers
303-924-5337
---------------------------------------------- 


"McDonald, Ira" <imcdonald at sharplabs.com> 
Sent by: owner-wbmm at pwg.org 
07/30/2003 12:02 PM To"'wbmm at pwg.org'" <wbmm at pwg.org> 
cc
SubjectWBMM> More about WBMM operations







Hi Bill,                                        Wednesday (30 July 2003)

Comments on operations set in the minutes from last week's WBMM meeting.

Cheers,
- Ira McDonald
 High North Inc

----------------------------------------


7. Other simplifications were apparent so that the current operations
  set is:


Disable - Prevents the addressed entity to from accepting jobs from any
job submission protocol.


Enable - Allows the addressed entity to accept jobs from any job
submission protocol.


Pause - Causes the entity to stop processing its primary product (e.g.,
a printing device from marking media, a scanning device from scanning
input copy).  There may be a need for an argument to address the "now",
"after current copy" and "after current job" variations.


Resume - undoes the last Pause.


Deactivate - entity accepts no more incoming jobs (the original
definition deactivate is unclear - further the distinction between
Disable and Deactivate is vague.)

<ira>
Deactivate is a compound operation to avoid a tricky race condition.  It
combines Disable and Pause in one atomic operation.  It's defined in IPP
Admin (draft-ietf-ipp-ops-set2-03.txt, July 2001) as follows:

3.4.1 Deactivate-Printer operation

  This OPTIONAL operation allows a client to stop the Printer object
  from starting to send IPP jobs to any of its Output Devices or
  Subordinate Printers (Pause-Printer-After-Current-Job) and stop the
  Printer object from accepting any, but query requests.  The Printer
  performs a Disable-Printer and a Pause-Printer-After-Current-Job
  operation immediately, including use of all of the "printer-state-
  reasons" if these two operations cannot be completed immediately.  In
  addition, the Printer MUST immediately reject all requests, except
  Activate-Printer, queries (Get-Printer-Attributes, Get-Job-
  Attributes, Get-Jobs, etc.), Send-Document, and Send-URI (so that
  partial job submission can be completed - see section 3.1.1) and
  return the 'server-error-service-unavailable' status code.
</ira>


Activate - undoes the last Deactivate


Purge - Removes all traces of jobs in the entity


Reset - Sets the state of the entity to the normalized condition
characterizing the state when the entity first comes up.

<ira>
IPP Admin defines the Restart and Startup operations:

3.5.1 Restart-Printer operation

  This OPTIONAL operation allows a client to restart a Printer object
  whose operation is in need of initialization because of incorrect or
  erratic behavior, i.e., perform the effect of a software re-boot.
  The implementation MUST attempt to save any information about Jobs
  and the Printer object before re-initializing.  However, this
  operation MAY have drastic consequences on the running system, so the
  client SHOULD first try the Deactivate-Printer operation to minimize
  the effect on the current state of the system.  The effects of
  previous Disable-Printer, Pause Printer, and Deactivate-Printer
  operations are lost.

3.5.3 Startup-Printer operation

  This OPTIONAL operation allows a client to startup an instance of a
  Printer object, provided that there isn't one already instantiated.
  The purpose of Startup-Printer is to allow a hosted implementation of
  the IPP Printer object (i.e., a Server that implements an IPP Printer
  on behalf of a networked or local Output Device) to be started after
  the host is available (by means outside this document).  See Restart-
  Printer (section 3.5.1) for the way to initialize the software or
  reset the Output Device(s) when the IPP Printer object has already
  been instantiated.

  The host MUST accept this operation only when the Printer object has
  not been instantiated.  If the Printer object already exists, the
  host must return the 'client-error-not-possible' status code.

  The result of this operation MUST be with the Printer object's
  "printer-state" set to 'idle', the state reasons removed from its
  "printer-state-reasons" attribute, and its "printer-is-accepting-
  jobs" attribute set to 'false'.  Then the operator can reconfigure
  the Printer before performing an Enable-Printer operation.  However,
  when a Printer is first powered up, it is RECOMMENDED that its
  "printer-is-accepting-jobs" attribute be set to 'true' in order to
  achieve easy "out of the box" operation.
</ira>


PowerOff - Causes entity to go into a power off or (or reduced power,
sleep) condition.

<ira>
IPP Admin and DPA (ISO 10175) define the Shutdown operation.

3.5.2 Shutdown-Printer Operation

  This OPTIONAL operation allows a client to shutdown a Printer, i.e.,
  stop processing jobs without losing any jobs and make the Printer
  object no longer available for any operations using the IPP protocol.
  There is no way to bring the instance of the Printer object back to
  being used, except for the Startup-Printer (see section 3.5.3) which
  starts up a new instance of the Printer object for hosted
  implementations.  The purpose of Shutdown-Printer is to shutdown the
  Printer for an extended period, not to reset the device(s) or modify
  a Printer attribute.  See Restart-Printer (section 3.5.1) and
  Startup-Printer (section 3.5.3) for the way to initialize the
  software.  See the Disable-Printer operation (section 3.1) for a way
  for the client to stop the Printer from accepting Job Creation
  requests without stopping processing or shutting down.
</ira>


GetAttributes - Solicits the values of the identified elements and all
included sub elements


SetAttributes - Sets the values of the identified elements and all
included sub elements


GetResource - Solicits the values of the identified structures or files.
(e.g., representing fonts, forms, executable code, schedules(?).  May be
indirect in that structure is delivered to defined address.


SetResource - Causes identified structures or files (e.g., representing
fonts, forms, executable code, schedules(?) to be loaded into entity.
May be indirect in that structure is obtained from defined address.

<ira>
The IPP Resource Object proposal (draft-ietf-ipp-get-resource-01.txt,
September 2000) defines the following REQUIRED operations:

* Get-Resource-Attributes
* Get-Resource-Data (corresponds to your current Get-Resource, I think)
* Get-Resources (get a list of Resource objects of a specified type)

The IPP Resource Object proposal also defines the following OPTIONAL
admin operations:

* Create-Resource (sets both attributes and data)
* Delete-Resource
* Refresh-Resource (refreshes local cache of referenced data)
* Renew-Resource (renews finite lease of Resource object)

By design, we did NOT define a Set-Resource-Attributes operation (much
harder to verify, due to attribute value constraints, than the simple
Create-Resource operation).
</ira>


Register - Set up for notification


Unregister- Discard setup for notification.



More information about the Wims mailing list