Rick,
Thanks for your observations. I agree generally with your summary of the CIM core opinions. However, I suggest:
1. The white paper was part of the PWG process, not necessarily something to be submitted to CIM core. The white paper was to be used both to allow a third person (Craig) to generate the CRs and to publicize to the PWG members what was being done in the name of the organization. I think it is an important part of our activities.
2. However, the white papers should contain the overview information CIM requested. Indeed, one of the callers suggested that a white paper may help them understand the background. So we may want to make the white paper available to CIM.
3. We need to consider the Capabilities and Settings issue. I have the notion that this structure is distinctly different from the model that we are trying to propagate. I wonder how the fact that settings can be changed by the print jobs as well as by management setting operations would be accomodated by this approach. That is, your have capabities, defaults and actuals.
4. As was dicussed, the profile is a posibility for the future but is not currently part of the PWG/CIM realignment plan. If you that that the profile should be done as part of this this activity, please indicate your rational. It has been stated that the profile is complicated and of limited use, being primarily for WEBM which we believe will be replaced by WSDM.
Thanks,
Bill Wagner
-------------- Original message --------------
From: <Richard_Landau at Dell.com>
Short notes on a few things I heard in the CIM Core concall today. (I didn't have much opportunity to take notes for the first half hour, but here are some things I remember.)
Easy changes first: good idea. One, maybe two, CRs; maybe enums are separate, since they're sizable and substantive.
Don't bother with white papers. Draft directly into CR format, then edit as needed.
Don't bother with PWG private extensions. Propose phase 3 changes as experimental. Then the implementation experience of two companies will be needed to promote the changes to full status.
Do UML diagrams first for the new class structure, and get agreement on the structure before writing a lot of text.
Core needs some overview of the printing model. (Printer MIB has a good intro. Where is the similar overview for IPP?)
Use Capabilities and Settings classes (CIM_xxxx) to express such for printers. The usual division is
- What is the device capable of? (r/o in Capabilities)
- What has the manager requested of the device? (r/w in Settings)
- What is the device actually doing? (properties in the device class itself)
(These classes are not completely straightforward, as I recall. I will look for some examples.)
Think about doing a profile in the long term. (A really good idea. I will explain this and get an example for PWG to look at. I think we should draft the profile along with the UML.)
For the major changes, be sure to include some consideration of
- related element causing error
- health and status
- messages
- indications (event notifications in CIM, related to traps, alerts, alarms, etc.)
Send draft things, if we wish, to John Crandall and Jon_Hass at dell.com, or to wg_cimcore at dmtf.org
Gotta go.
rick
-------------------------
Richard_Landau(at)dell(dot)com, System Mgt Arch & Stds
+1-512-728-9023, One Dell Way, RR5-3 Box 8509, Round Rock, TX 78682
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20060123/60017268/attachment.html