attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=Content-Type content="text/html; charset=us-ascii"> <META content="MSHTML 6.00.2900.3354" name=GENERATOR></HEAD> <BODY> <DIV dir=ltr align=left> I understand <?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" /><st1:place w:st="on"><st1:City w:st="on">Nancy</st1:City></st1:place>'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.  <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p> </o:p> 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.  <o:p> </o:p> 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.  <o:p> </o:p> 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.  <o:p> </o:p> 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.  <o:p> </o:p> 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.  <o:p> </o:p> 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.  <o:p> </o:p> Have a nice weekend.  <o:p> </o:p> rick </DIV> <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left> <HR tabIndex=-1> From: owner-wims@pwg.org [mailto:owner-wims@pwg.org] On Behalf Of nchen@okidata.com Sent: Friday, July 11, 2008 16:16 To: William A Wagner Cc: owner-wims@pwg.org; wims@pwg.org Subject: Re: WIMS> Concall- 14 July 11AM NOTE PHONE CHANGE! </DIV> <DIV></DIV> 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 "<TT>to be managed along with other network devices by some extant general Web Services management capability</TT> ", 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@okidata.com <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD width="40%">"William A Wagner" <wamwagner@comcast.net> Sent by: owner-wims@pwg.org 07/10/2008 04:11 PM <TD width="59%"> <TABLE width="100%"> <TBODY> <TR vAlign=top> <TD> <DIV align=right>To</DIV> <TD><wims@pwg.org> <TR vAlign=top> <TD> <DIV align=right>cc</DIV> <TD> <TR vAlign=top> <TD> <DIV align=right>Subject</DIV> <TD>WIMS> Concall- 14 July 11AM  NOTE PHONE CHANGE!</TR></TBODY></TABLE> <TABLE> <TBODY> <TR vAlign=top> <TD> <TD></TR></TBODY></TABLE> </TR></TBODY></TABLE> <TT>NOTE CALL-IN CHANGE </TT> <TT>The next WIMS/CIM concall is at 11 AM EDT Monday, 14 July. </TT> <TT>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 </TT> <TT>Don't worry about attendee ID code. </TT> <TT>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:</TT> <TT>A. allow printers to be managed along with other network devices by some extant general Web Services management capability</TT> <TT>B. Provide anything but a low-level command line user management application, roughly equivalent to a simple SNMP browser. </TT> <TT>We need to come up with some conceptual diagrams: </TT> <TT>SNMP                         CIM             WS-MAN (?) Printer <-------->CIM provider proxy <--------->COMOM<------------> WIN-RM</TT> <TT>(or higher level management application) </TT> <TT>Proposed Agenda: </TT> <TT>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 </TT> <TT>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).</TT> <TT>a. Mapping String length b. Config Change Element c. Timestamp</TT> <TT>3. Update on Dell Prototyping Activity </TT> <TT>4. MIB-CIM Provider Effort a. Ideas on development sponsor...Company that would benefit sufficiently</TT> <TT>to sponsor development b. Member Companies willing to contribute funds, manpower for Open</TT> <TT>Printing effort c. What do we really want as a result of development?</TT> <TT>1. second implementation of Printer Schema to get out of experimental status (Yes)</TT> <TT>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</TT> <TT>3. Open source code to be used by Imaging Equipment manufacturers of others to produce (proprietary) applications? 5. Next steps. </TT> <TT>Thanks. Hope you can join the call. </TT> <TT>Bill Wagner </TT> </BODY></HTML>