Ira,
Thanks for reminding us of this past work. It may be a good start to defining a reduced management model. But the need for flexibility is made very clear by the fact that both the operations and management information contain many things that my application has no interest in, and nothing that is critical to my application.
That is, what is essential to remote monitoring and metering (and the MIB objects that we are presently using) are usage figures (prtMarkerLifeCount), the prtAlerts Table, and the HR Device Printer status and printer detected error objects. Unfortunately, currently these objects are inconsistently implemented. And there appears to be no agreement on how to count or distinguish sheets printed in color from monochrome. prtMarkerSuppliesLevel would also be useful, but it is even more inconsistently implemented. Basically, this is one of the scenarios where the remote monitor is not setting up the machine, is not controlling jobs. He just needs to know usage for billing, warnings when the device will need consumables replacement (other than media) and alerts when there is a pending or actual failure.
Bill Wagner
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Wednesday, June 04, 2003 10:34 AM
To: McDonald, Ira; Wagner,William; wbmm at pwg.org
Subject: RE: WBMM> Comments on Harry's WSDL
Hi,
Extracted from the PDF (see below), here are the Device operations
that were proposed for IPP extensions back in late 1999.
Cheers,
- Ira McDonald
High North Inc
------------------------------------------------------------------------
9. Definition of the Set 3 Device operations
All Device operations are directed at Printer objects. A client MUST
always supply the "printer-uri" operation attribute in order to identify
the correct target of the operation. These descriptions assume all of
the common semantics of IPP/1.1 Model and Semantics document [ipp-mod]
section 3.1.
The Set 3 Device operations are summarized in the following table:
Operation Name / Brief Description
----------------------------------
* Disable-Device - Prevents the output device from accepting jobs with
any job submission protocol.
* Enable-Device - Allows the output device to accept jobs from any job
submission protocol.
* Pause-Device-Now - Stops the output device from marking media as soon
as possible on the page or sheet.
* Pause-Device-After-Current-Copy - Stops the output device from marking
media after the current copy has been stacked.
* Pause-Device-After-Current-Job - Stops the output device from marking
media after the current job has been stacked.
* Resume-Device - Continues the output device from the last Pause Device
operation.
* Deactivate-Device - Puts the output device into a read-only
deactivated state.
* Activate-Device - Restores the output device to normal activity.
* Purge-Device - Removes all traces of jobs in the output device.
* Reset-Device - Resets the hardware state of the output device and
re-initializes the output device software.
* Power-Off-Device - Powers off the output device.
-----Original Message-----
From: McDonald, Ira [mailto:imcdonald at sharplabs.com]
Sent: Tuesday, June 03, 2003 9:15 PM
To: 'Wagner,William'; wbmm at pwg.org
Subject: RE: WBMM> Comments on Harry's WSDL
Hi folks,
Back in 1999, Carl Kugler (IBM), Harry Lewis (IBM), and Tom Hastings
(Xerox) collaborated to write a first draft of IPP Device Operations
(30 pages, 122 KB) at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_OPS/ipp-ops-set3-991208.pdf
Defined in this spec in Table 1 (see first one-page PDF attachment)
is a set of Device admin operations that correspond closely to the
equivalent IPP Printer (i.e., Service) operations in IPP/1.1. Also
defined in Table 3 (see second one-page PDF attachment) is a brief
description of each Device admin operation (e.g., 'Reset-Device'
and 'Power-Off-Device').
Tom Hastings and I also wrote an analysis of possible attributes for a
minimal IPP Device object. We reviewed 192 IPP Printer or Printer MIB
candidate attributes and we proposed 23 REQUIRED and 10 OPTIONAL
Device object attributes. This white paper (7 pages, 48 KB) is at:
ftp://ftp.pwg.org/pub/pwg/ipp/new_DEV/ipp-device-object-attributes.pdf
That is, the process of winnowing the 176 attributes in the Printer MIB
into the essential ones for Device Admin has already been done once.
Please take a look at the two small attachments (and short specs, if
possible).
Cheers,
- Ira McDonald
High North Inc
-----Original Message-----
From: Wagner,William [mailto:WWagner at NetSilicon.com]
Sent: Tuesday, June 03, 2003 4:20 PM
To: wbmm at pwg.org
Subject: WBMM> Comments on Harry's WSDL
The following are some basic comments/questions relative to the WSDL that
Harry posted last week . He will not be able to join us tomorrow, but in the
interests of getting some thought going on this, I trust he will not mind if
we discuss this in his absence.
Also, I have posted some basic definitions and descriptions on the FTP site
at ftp://ftp.pwg.org/pub/pwg/wbmm/white/definitions1.pdf. I would be
interested in comments.
Many thanks.
Bill Wagner
Operations:
The following operations were proposed by Harry in his WSDL. I have
indicated some questions and some additions.
GetAttributes
SetAttributes
ExecuteCommand (Reset, OpPanelMessage, Off-line, LockOpPanel, DownloadCode)
GetAll
Register
Unregister
Questions:
1. Is the term "Attributes" the most desirable term for the management items
defined in the Management Model? (I shall use "attribute" in the following
as a tentative label)
2. Why are things like Reset, OpPanelMessage, Off-line, LockOpPanel, which
previously were handled as management items, now in a special execute
command message? Even Download code could be handled by two items (URL and
time)
3. We have agreed (I think) that for the data to be presented in the form it
is to be consumed, the management data can be modeled (structured) in
different ways (since it will be consumed in different ways). Would then the
attribute names in the attribute list possibly identify a group as well as a
specific attribute? Would then the attribute names define also the modeling?
4. If the attribute name indicates the model, and GetAll includes no
arguments, I am concerned about what the response would be.
5. Understanding that MIBs appear to be in disfavor just now, the MIB OID
structure does provide a effective way to tag attributes in a way that ,
although not secure, is concise and does not flaunt enterprise information.
Furthermore, requesting attributes with a given OID prefix can request a
table, a subgroup or an entire group, although following the MIB structure.
The new management model is intended to provide more flexibility, not
limited by the rigid MIB structure. It is not clear to me how is this would
be provided, at least with this limited message set.
6. Register Request includes as arguments: Listener, Condition and Interval.
a. Although the meaning of this is subject to interpretation, I can conclude
that this one message includes all that I had originally intended for WBMM;
periodic reporting on identified parameters and asynchronous reporting of
alerts, subject to conditions and moderation. I think that this message is
severely overloaded. Perhaps separate alert and report notifications? Still,
these would be some heavy messages.
b. We had defined WBMM as a Management Interface communicating with a
single management server, not as encompassing a general notification
capability. The inclusion of a "listener" argument suggests an expansion
into the complexity of general notification, which was not in the use
examples. Is it regarded as a necessary addition?
c. Condition, by my understanding can be quite complex, including
moderation. This is identified as a string. Any notion of the format?
7. From the message identifications (listed below), I need some explanation
of the "Async" requests. The arguments include "attribute name" instead of
"attribute list", and "listener"
GetAttributesResponse
GetAttributesRequest
SetAttributesRequest
SetAttributesResponse
GetAttributesAsyncRequest
GetAttributesAsyncResponse
SetAttributesAsyncRequest
SetAttributesAsyncResponse
ExecuteRequest
ExecuteResponse
ExecuteAsyncRequest
ExecuteAsyncResponse
GetAllRequest
GetAllResponse
RegisterRequest
RegisterResponse
UnRegisterRequest
UnRegisterResponse
William A. Wagner (Bill Wagner)
Director of Technology
Imaging Division
NETsilicon, Inc.
781-398-4588