I understand Nancy's frustration with the current situation, but we have
to view the situation in the right perspective. The management of
printers is just beginning a transitional period, and we really
shouldn't be disappointed that fully-formed solutions are not available
now or in the next few months.
The new CIM classes describing printers in accordance with the Printer
MIB and Semantic model are brand new. The ink is not yet dry on the
standards. The new MOFs have been published for only a few weeks. In
fact, the last half dozen amendments to the class definitions will be
published by DMTF in about a month.
Because the definitions are so new, it is not possible for a CIM-based
printer management application to exist that uses the new CIM classes.
Such an application would not be testable today, because there is no
source of CIM management data for printers.
This is kind of a chicken-egg situation, very similar to the one that
existed in the mid-1990s when the Printer MIB was just being published.
There were no printers emitting SNMP data in the standard form, and
there were certainly no applications available to consume such data.
When the first Printer MIB capable printers came out, there were no
general management applications to use that data. How could there be?
No data source; no data sink. Over the succeeding several years,
however, many new models of printer began to adopt the standard and,
when such data was available, applications appeared that used that data
for management. The egg and the chicken had to evolve at the same time.
Here we have a chance to begin a slightly faster transition. We don't
have to wait for a dozen printer vendors to release models that speak
the new management language. We can piggy-back on the near-universal
availability of Printer MIB data to make available the same management
information in the new CIM format. A proxy provider can take the SNMP
data from any printer and render it into the CIM form. (That's why I'm
trying to build a prototype.) Of course there are no current
applications that consume this data in this form yet. How could there
be? The old CIM printer classes were so impoverished of data that no
one, I believe, built management applications based on that model. But
when a new, richer model becomes available, maybe software will adapt to
it. Applications will maintain backwards compatibility for SNMP
printers for years, I assume, at the very least because the installed
base is so huge and so slowly replaced.
Regarding the use of WS-Management with another data model for MFDs, for
instance, one should note that WS-Man is just a protocol for
*transporting* management data. It does not itself define the
management data to be transported. In this respect it is no different
from any other web service protocol, or from SNMP. In the set of WS-Man
specs, there are two other specs that describe how CIM management data
instances are to be addressed and encoded when transported by WS-Man
(the "WS-Management CIM Binding" specification and the "WS-CIM Mapping
Specification"). To define such a binding is a substantial effort.
This topic obviously needs lots more discussion. Let's do what we can
on the calls, and set aside some time at the next f2f, too. I agree
completely with Bill that we need to have some conceptual diagrams that
make it easy for people to understand and explain what components go
where and do what functions.
Have a nice weekend.
rick
________________________________
From: owner-wims at pwg.org [mailto:owner-wims at pwg.org] On Behalf Of
nchen at okidata.com
Sent: Friday, July 11, 2008 16:16
To: William A Wagner
Cc: owner-wims at pwg.org; wims at pwg.org
Subject: Re: WIMS> Concall- 14 July 11AM NOTE PHONE CHANGE!
Bill,
Given the recent discussions and new information involving this project,
it is important to pause and make sure our original assumptions and
direction are still valid. In particular, I had assumed that Windows
provides a full WS-Management application. As a result, I agreed that
the PWG should develop a MIB-to-CIM provider so that this full
WS-Management application could manage CIM printers, since no SNMP path
was available. It seems this assumption is not valid for Windows, in
that Windows SMS2003 and perhaps the follow-on
SystemConfigurationresourceManager ( I am still investigating this) do
not provide support for WS-Management for printers (Note: it supports
WS-Management for Windows Hardware Platform, Mobile Devices). If
Windows does not have such a WS-Management application, and we want
printers being able "to be managed along with other network devices by
some extant general Web Services management capability ", then Oki
Data's position is not to provide CIM printer object at all, but rather
implement the PWG MFD semantic model's web services binding for future
full featured WS-Management applications including printers. As a
confirmation, we should ask Microsoft about their roadmap for SMS +
WS-Management + printers including the target ship date.
General WS-Management applications can take XML-schema, which can be
provided by any printer that implements PWG Print Service model in
XML-schema (a WSD-Printer for example). CIM conversion was assumed to
be a quick path into full Microsoft WS-Management applications, since a
conversion module exisits (WinRM). However, as Rick pointed out, WinRM
only provides a command line interface, not good enough as a
full-featured GUI-based printer management application using
WS-Management. Since there is no full-blown application (just command
line browser feature), the benefit of doing the CIM conversion is not
clear, and requires further discussion.
I believe many printer/device management applications such as
WebJetAdmin, Tivoli, CA, etc., are all migrating toward WS-Management of
web services. Some of these accept CIM objects, but the printer
management programs like webJetAdmin do not. Therefore, the printer
management specific programs will likely migrate directly from SNMP to
WS-Management while maintaining SNMP backwards compatibility. There is
no benefit, but rather extra overhead, in going through a CIM converter.
Do these application takes CIM objects only? It is important to ensure
the PWG MFD semantic model support the full capabilities such as power
management, and then let printer vendors migrate their programs to
WS-Management utilizing the MFD spec.
If Microsoft and others can be expected to provide full WS-Management
applications in the next 2-3 years, then perhaps we should redirect the
effort towards creating an SNMP -> MFD WS-Services Listening Agent so
that legacy printers can work with the full IT environment WS-Management
applications, and so that all printer vendors can support legacy devices
in their WS-Printer Management applications.
-Nancy
------------------------------------------------------------------------
------------------
Principal Engineer
Solutions and Technology
Oki Data
2000 Bishops Gate Blvd.
Mt. Laurel, NJ 08054
Phone: (856)222-7006
Email: nchen at okidata.com
"William A Wagner" <wamwagner at comcast.net>
Sent by: owner-wims at pwg.org
07/10/2008 04:11 PM
To
<wims at pwg.org>
cc
Subject
WIMS> Concall- 14 July 11AM NOTE PHONE CHANGE!
NOTE CALL-IN CHANGE
The next WIMS/CIM concall is at 11 AM EDT Monday, 14 July.
The dial-in information is:
Call-in toll-free number (US/Canada): 1-866-469-3239
Call-in toll number (US/Canada): 1-650-429-3300
Call-in toll number (US/Canada): 1-408-856-9570
Attendee access code: 21967831
Don't worry about attendee ID code.
The agenda is much like last weeks. But Item 4 should be considered in
the
light of the information from Nancy and Rick that boils down to that
fact
that a CIM provider deriving its device information by SNMP access to
the
printer, even when used in conjunction with existing Windows facilities,
will NOT:
A. allow printers to be managed along with other network devices by
some extant general Web Services management capability
B. Provide anything but a low-level command line user management
application, roughly equivalent to a simple SNMP browser.
We need to come up with some conceptual diagrams:
SNMP CIM WS-MAN (?)
Printer <-------->CIM provider proxy <--------->COMOM<------------>
WIN-RM
(or
higher level management application)
Proposed Agenda:
1. Review of 7 July minutes:
ftp://ftp.pwg.org/pub/pwg/wims/minutes/cim-wims_080707.pdf and
ftp://ftp.pwg.org/pub/pwg/wims/minutes/cim-wims_080707.doc
2. Counter MIB CIM conversions. Ira posed several questions for which no
answers are listed
(ftp://ftp.pwg.org/pub/pwg/wims/cim/mofinput/ira-20080615.zip).
a. Mapping String length
b. Config Change Element
c. Timestamp
3. Update on Dell Prototyping Activity
4. MIB-CIM Provider Effort
a. Ideas on development sponsor...Company that would benefit
sufficiently
to sponsor development
b. Member Companies willing to contribute funds, manpower for Open
Printing effort
c. What do we really want as a result of development?
1. second implementation of Printer Schema to get out of
experimental status (Yes)
2. Freely available, product level release of Provider application
a. Who provides executables for which OS?
b. Who makes availability known, distributes
c. Who maintains software, does customer service
3. Open source code to be used by Imaging Equipment manufacturers of
others to produce (proprietary) applications?
5. Next steps.
Thanks. Hope you can join the call.
Bill Wagner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20080711/fec7f26b/attachment.html