All changes to be submitted by the Working Group Chair (or designee) after approval by the working group.
The Change Request sample
(http://www.dmtf.org/members/zdata/CRTemplateSample.html) contains more
detailed
information on how to complete the template.
|
DMTF Change Request Number [sysdevCR006655] |
CIMCoreCR00901 |
|
CR Owner Name, Email [My Name, my.name@company.com] |
Richard Landau, Richard_Landau@dell.com |
|
Alliance Partner submitting CR request (if applicable) |
Printer Working Group, pwg.org |
|
Alliance Partner vote history (e.g. SNIA XYZ Approved on 8/12/06) |
|
|
Alliance Partner identifier/tracking number (if available) |
n/a |
|
Errata [Yes/No] |
No |
|
Short Description |
Add new class CIM_PrintOutputTray to enhanced printer device model. |
|
Spec, Document or Model(s) Being Changed [Device Model] |
[Core Model] |
|
Spec, Document or Model Version Incorporating the Change [V2.9 Final] |
V2.16 Experimental |
|
Filename(s) Incorporating the Change [Device_USB.mof] |
CIM_PrintOutputTray.mof |
|
Date Originated [mm/dd/yyyy] |
02/07/2007 |
|
Date of Last Revision of the Change Request [mm/dd/yyyy] |
05/03/2007 |
|
Dependencies [smwgCR00567,sysdevCR00555] |
CIMCoreCR00911 |
Terminology
The terminology used in this CR should conform to the "Rules for the structure and drafting of International Standards", 5th Edition, 2005 available at:
Particular attention shall be paid to Annex H which lays out guidelines for the expression of provisions.
Background/Rationale (Explanation of the background and reason(s) for the requested change, and supporting documentation):
As part of the PWG/DMTF Work Register dated 2005/05/12, the Printer Working Group (PWG, see http://www.pwg.org/) is updating the printing-related classes in the CIM data model. PWG is submitting a series of Change Requests to update the CIM model to align with the current model developed in the PWG.
The PWG models for printing related devices and services include many properties that need to be managed but are not currently represented in CIM at all. If these properties are to be visible to CIM-based management applications, then they must appear in the CIM model.
The current PWG printer device model, as embodied in the SNMP Printer MIB v2, RFC3805, contains many properties Some examples:
• Printer console displays and lights, and cover and other interlocks
• Printer input and output trays containing media
• Printer media paths that control the layout of page images on physical sheets
• Printer toners, colorants, and other supplies
• Printer communication channels and language interpreters
• Printer counters for pages and sheets printed in various operational modes
The CIM model will be extended to include these important management objects. This will require extensions to the CIM_Printer class and the addition of other CIM classes to represent the capabilities, settings, and counters required.
The current new class, CIM_PrintOutputTray, is the first of several classes to be added.
Alliance Partner Status (tracking number, other key identifiers, supporting documentation, etc.):
(insert text here)
Requested Change (Change information such as details before/after the change, readable/indented MOF, and/or references to "Uploaded" MOF and other documents if the changes are too lengthy to include inline):
//add the new class CIM_PrintOutputTray as CIM_PrintOutputTray.mof
// Copyright (c) 2007 DMTF. All rights reserved.
// ==================================================================
// CIM_PrintOutputTray
// ==================================================================
[Experimental, Version ( "2.16.0" ), Description (
"Subunit: Output tray on a printer (print device). Properties "
"of a device capable of receiving media delivered from the "
"printing process.") ,
UMLPackagePath ( "CIM::Device::Printing" )]
class CIM_PrintOutputTray : CIM_LogicalElement {
[Key, Description (
"Within the scope of the instantiating Namespace, InstanceID "
"opaquely and uniquely identifies an instance of this class. "
"To ensure uniqueness within the NameSpace, the value of "
"InstanceID should be constructed using the following "
"\"preferred\" algorithm: \n"
"<OrgID>:<LocalID> \n"
"Where <OrgID> and <LocalID> are separated by a colon (:), "
"and where <OrgID> shall include a copyrighted, trademarked, "
"or otherwise unique name that is owned by the business "
"entity that is creating or defining the InstanceID or that "
"is a registered ID assigned to the business entity by a "
"recognized global authority. (This requirement is similar "
"to the <Schema Name>_<Class Name> structure of Schema class "
"names.) In addition, to ensure uniqueness, <OrgID> shall "
"not contain a colon (:). When using this algorithm, the "
"first colon to appear in InstanceID shall appear between "
"<OrgID> and <LocalID>. \n"
"<LocalID> is chosen by the business entity and should not "
"be reused to identify different underlying (real-world) "
"elements. If the above \"preferred\" algorithm is not used, "
"the defining entity shall assure that the resulting "
"InstanceID is not reused across any InstanceIDs produced by "
"this or other providers for the NameSpace of this instance. "
"\nFor DMTF-defined instances, the \"preferred\" algorithm "
"entity that is creating or defining the InstanceID or that "
"is a registered ID assigned to the business entity by a "
"recognized global authority. (This requirement is similar "
"to the <Schema Name>_<Class Name> structure of Schema class "
"names.) In addition, to ensure uniqueness, <OrgID> shall "
"not contain a colon (:). When using this algorithm, the "
"first colon to appear in InstanceID shall appear between "
"<OrgID> and <LocalID>. \n"
"<LocalID> is chosen by the business entity and should not "
"be reused to identify different underlying (real-world) "
"elements. If the above \"preferred\" algorithm is not used, "
"the defining entity shall assure that the resulting "
"InstanceID is not reused across any InstanceIDs produced by "
"this or other providers for the NameSpace of this instance. "
"\nFor DMTF-defined instances, the \"preferred\" algorithm "
"shall be used with the <OrgID> set to CIM.")]
string InstanceID;
[Required, Override ( "ElementName" ), Description (
"The user-friendly name for this instance of output tray. In "
"addition, the user-friendly name can be used as an index "
"property for a search or query. (Note: The name does not "
"have to be unique within a namespace.) This name shall be "
"generated as a factory default by the manufacturer and may "
"be changed out-of-band to a site-specific name by the "
"system administrator."),
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputName" },
ModelCorrespondence { "CIM_ManagedElement.ElementName" }]
string ElementName;
[Description (
"A unique value used by this printer to identify this output "
"tray subunit. Although these values may change due to a "
"major reconfiguration of the subunit (e.g., the addition of "
"new output trays to the printer), values should remain "
"stable across successive printer power cycles. Note: This "
"property is necessary to correlate status and event (alert) "
"information between CIM and SNMP interfaces."),
MinValue ( 1 ), MaxValue ( 65535 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputIndex" }]
uint32 SNMPRowId;
[Description (
"A free-form text description of this output tray subunit in "
"the localization specified by "
"CIM_Printer.CurrentNaturalLanguage."),
MinLen ( 0 ), MaxLen ( 255 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputDescription",
"MIB.IETF|Printer-MIB.PrtLocalizedDescriptionStringTC" }]
string LocalizedDescription;
[Description (
"The type of technology supported by this output tray "
"subunit."),
ValueMap { "1", "2", "3", "4", "5", "6", "7", ".." },
Values { "Other", "Unknown", "RemovableBin", "UnRemovableBin",
"ContinuousRollDevice", "MailBox", "ContinuousFanFold",
"DMTF Reserved" },
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputType",
"MIB.IETF|IANA-PRINTER-MIB.PrtOutputTypeTC" }]
uint32 Type;
[Description (
"A free-form string that describes the type of technology "
"when the value of the Type property is equal to 1 (Other)."),
MinLen ( 0 ), MaxLen ( 255 )]
string OtherTypeDescription;
[Description (
"The unit of measurement for use in calculating and relaying "
"capacity values for this output tray subunit."),
ValueMap { "1", "2", "3", "4", "8", "16", "17", "18", "19",
".." },
Values { "Other", "Unknown", "TenThousandthsOfInches",
"Micrometers", "Sheets", "Feet", "Meters", "Items",
"Percent", "DMTF Reserved" },
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputCapacityUnit",
"MIB.IETF|Printer-MIB.PrtCapacityUnitTC" }]
uint32 CapacityUnit;
[Description (
"A free-form string that describes the capacity unit when "
"the value of the CapacityUnit property is equal to 1 "
"(Other)."),
MinLen ( 0 ), MaxLen ( 255 )]
string OtherCapacityUnit;
[Description (
"The basis for the limit property MaxCapacity, that "
"specifies whether a meaningful value is available. 1 "
"(Other) means the subunit places no restrictions on "
"capacity and MaxCapacity shall be null. 2 (Unknown) means "
"the subunit cannot sense a meaningful value and MaxCapacity "
"shall be null. 3 (Actual) means the subunit can sense a "
"meaningful value and MaxCapacity shall be present."),
ValueMap { "1", "2", "3", ".." },
Values { "Other", "Unknown", "Actual", "DMTF Reserved" },
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputMaxCapacity" }]
uint16 MaxCapacityBasis;
[Description (
"The maximum capacity of this output tray subunit. There is "
"no convention associated with the media itself so this "
"value essentially reflects claimed capacity. If this output "
"tray subunit can reliably sense this value, the value is "
"sensed by the printer and cannot be changed by the system "
"administrator; otherwise, the value may be changed "
"out-of-band by the system administrator."),
MinValue ( 0 ), MaxValue ( 2147483647 ),
MappingStrings { "MIB.IETF|Printer-MIB.prtOutputMaxCapacity",
"MIB.IETF|Printer-MIB.prtOutputCapacityUnit",
"MIB.IETF|Printer-MIB.PrtCapacityUnitTC" }]
uint32 MaxCapacity;
[Description (
"The basis for the gauge property RemainingCapacity, that "
"specifies whether a meaningful value is available. 1 "
"(Other) means the subunit places no restrictions on "
"capacity and RemainingCapacity shall be null. 2 (Unknown) "
"means the subunit cannot sense a meaningful value and "
"RemainingCapacity shall be null. 3 (Actual) means the "
"subunit can sense a meaningful value and RemainingCapacity "
"shall be present. 4 (AtLeastOne) means that the subunit can "
"only sense that at least one capacity unit remains (i.e., "
"not full) and RemainingCapacity shall be null."),
ValueMap { "1", "2", "3", "4", ".." },
Values { "Other", "Unknown", "Actual", "AtLeastOne",
"DMTF Reserved" },
MappingStrings {
"MIB.IETF|Printer-MIB.prtOutputRemainingCapacity" }]
uint16 RemainingCapacityBasis;
[Description (
"The remaining capacity of this output tray subunit. If this "
"output tray subunit can reliably sense this value, the "
"value is sensed by the printer and cannot be changed by the "
"system administrator; otherwise, the value may be changed "
"out-of-band by the system administrator."),
MinValue ( 0 ), MaxValue ( 2147483647 ),
MappingStrings {
"MIB.IETF|Printer-MIB.prtOutputRemainingCapacity",
"MIB.IETF|Printer-MIB.prtOutputCapacityUnit",
"MIB.IETF|Printer-MIB.PrtCapacityUnitTC" }]
uint32 RemainingCapacity;
[Description (
"Status: Assessment of the availability of this printer "
"subunit."),
ValueMap { "1", "2", "3", "4", "5", "6", "7", ".." },
Values { "Unknown", "AvailableIdle", "AvailableStandby",
"AvailableActive", "AvailableBusy", "UnavailableOnRequest",
"UnavailableBroken", "DMTF Reserved" },
MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" },
ModelCorrespondence { "CIM_ManagedSystemElement.OperatingStatus"
}]
uint32 AvailabilityStatus;
[Description (
"Status: If true, there are currently non-critical alerts on "
"this printer subunit."),
MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]
boolean NonCriticalAlertsStatus;
[Description (
"Status: If true, there are currently critical alerts on "
"this printer subunit."),
MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]
boolean CriticalAlertsStatus;
[Description (
"Status: If true, the current state is offline on this "
"printer subunit."),
MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" },
ModelCorrespondence { "CIM_ManagedSystemElement.OperatingStatus"
}]
boolean OfflineStatus;
};
Discussion Points (Summary of decisions and discussions of the WG in creating this CR) :
Additional general information:
The goal of the alignment project is to represent the current printer device model faithfully in the CIM schema, to the extent possible. Where the accepted model includes writable properties, specific semantics for status, or numeric enumerated values, we have tried to preserve these semantics. In cases where the CIM schema has an existing property or a clear convention that would be useful for such a property, we will adapt to that property or convention.
Early implementations of providers using the extended model will be proxy agents that mediate between CIM applications and SNMP-capable printer devices. To permit plausible implementations, the extensions to the CIM model should employ any information that is likely to be available, and not require too much invention beyond the capabilities of existing devices. Further extensions can be made in the future as CIM-capable agents migrate into such devices.
The machine translation that is used to convert most of the model into MOF format includes post-processing with mofpretty, and there is some unfortunate interaction between their formatting rules. For example, mofpretty deletes the final comments in Values and ValueMap lists, making some of the lists appear to be corrupt. We will try to ameliorate some of these problems in the future. Correction by hand-editing of all such formatting glitches is impractical for the expected fifteen CRs containing 120 new properties.
[IBM]Most CRs are built by hand and precisely this sort of painful tinkering is done.
[PWG response in green, as this is.] Message received. We did fix the Values formatting problem, and we have resolved to work around any other mofpretty or similar problems we run across.
The following table includes comments, replies, further comments in response to the replies, and then further replies. The exchanges are color-coded for legibility.
|
Company |
Comment and Response in color |
|
Comments |
2007-02-15 thru 2007-04-10 |
|
IBM |
value/valuemap properties should not include "Other" unless you have an OtherXXX property that accompanies it.
Will add OtherXxx to OutputType and CapacityUnit. This was a direct translation from existing printer model. In the case of OffsetStacking, there is no additional information to populate an OtherXxx property, we will eliminate the enum value. |
|
IBM |
the value/valuemap do not need to be listed one per line
Caused by a bug in mofpretty formatting that interacts with the output of our machine translation from the existing model. (mofpretty deletes trailing comments in such lists.) We will remove comments to avoid the bug.
|
|
IBM |
have you looked at specializing from EnabledLogicalElement instead of ManagedElement and reusing the status properties that are currently there (or the ones proposed by CIMCoreCR00874?)
The subunit cannot be enabled or disabled. Most of the properties of EnabledLogicalElement (and similar classes) do not apply. The status properties included in the class are directly derived from the existing model, which contains these five classes of status. The status values being proposed in CR874 are more appropriate to a system than to this simple subunit. E.g., there is no "communications status" between the subunit and its host device.
[IBM]Fair enough, but this communications status is actually b/w the instrumentation and the managed element to indicate whether you're providing good information.
[PWG]Will add the status properties from Core CR874. If these properties are promoted from EnabledLogicalElement to ManagedSystemElement, we will change the inheritance of this (and most future) classes to MSE, from the current ME, and acquire the new status properties that way. Note that the new status properties do not include all the information in the current model.
|
|
IBM |
There is already a Description property on ManagedElement. The Name property seems redundant with ElementName on ManagedElement.
Accidental collision of Description property name, derived from existing model; will fix. Change property name to LocalizedDescription with the same semantics. Will change Name to AdminName. The CIM_ManagedElement.ElementName property will be used to specify subunit identity. The AdminName property is a user-assigned (writable) string.
[IBM]Pls add an override of ElementName and modify the description qualifier to indicate its intended usage such that within the MOF file its clear why two properties are used.
[PWG]Instances of this class require an administratively assigned name property that is writable by the user. Rather than have two properties, we will override ManagedElement.ElementName (making it writable and required) to serve that purpose.
|
|
IBM |
Also need at least one Key property.
Fixed. The properties used relate to the printer device instance as the scoping element, since CIM_Printer is not derived from CIM_ComputerSystem.
[IBM]Why not use InstanceId instead of propagated properties? There has been a general shift towards using a single property instead of multiple.
[PWG]Will change to InstanceID.
|
|
IBM |
The commented value in the values qualifier do not match the actual value in the valuemap qualifier.
Which property, please? There is a bug in mofpretty that removes the comment after the last item of a Values or ValueMap list. This bug makes it appear that the lists don't match, but the values usually are parallel.
[IBM]The problem went away when you cleaned up the qualifiers
[PWG]We will continue to fix or work around such formatting bugs.
|
|
IBM |
Is there a reason that the valuemap integers are not sequential?
The values are preserved, wherever possible, from the existing model. Changing the enum values would add dissonance to the model and reduce traceability.
Many of the value lists in this and other classes are textual conventions controlled by IANA registry and therefore cannot be changed.
|
|
IBM |
A property like MaxCapacity is generally implemented in an associated sub-class of Capabilities.
MaxCapacity is writable in cases where the value is not reliably sensed by the device; not suitable as a capability.
[IBM]We still split this data into something like: CIM_PrintOutputTrayCapabilities.MaxCapacity and CIM_PrintOutputTray.CurrentMaxCapacity. how does mgmt client A know whether the value was provided by the device or written by mgmt client B?. By splitting into two values you can say that if Capabilities.MaxCapacity = unknown, and OutputTray.CurrentMaxCapacity has a value, someone must have written it.
[PWG]This additional complexity -- another class and an association instance -- yields extremely little benefit. Proxy instrumentation will never have information to make this distinction. We would much prefer to use the simpler model at least until we gain some user experience with it.
[IBM]Further, the text in the Description qualifier uses "may not" where I think you want to say "shall not"
[PWG]Will fix. The wording was taken directly from the MIB. We will have to be careful about places where the older, looser wording clashes with modern normative use.
|
|
IBM |
Its unclear whether RemainingCapacity would be used to advertise the capacity is known, and then have a different value later to reflect the actual capacity.
Derived from existing model. The property may be employed in various ways by users, depending on local policy. Also, again, this property is writable in cases where the value cannot be sensed reliably by the device.
[IBM]same basic comment as above. You're not providing a mechanism to allow a client to know what is provided by the instrumentation and what has been written by a different client.
|
|
IBM |
CapacityUnits should have the ProgrammaticUnits qualifier and adhere to the rules agreed to by architecture for DSP0004 (arch 72 and 89)
Is it possible to add Units qualifier when the exhaustive list of units in DSP0004 does not include equivalents for several of the required values? (Sheets, TenThousandthsOfInches, Micrometers, Items) We were not aware of the proposed PUNIT qualifier. After looking at CR72, we feel that we should not obscure the vendor's declaration of the unit to be used for capacity measurement. Different vendors must be free to choose units of measurement, which was the purpose of the CapacityUnits property in the original model. PUNIT would apply directly if we were to impose a fixed unit on MaxCapacity or RemainingCapacity, but that is not possible across the spectrum of devices. Also, it would be possible to change the representation of CapacityUnits to a string with the ISPUNIT qualifier. We don't see an advantage of changing the representation to this experimental form.
[IBM]I don't understand. It sounds like you're saying that you think it is more interoperable to allow vendors to dump whatever value they want into this property and force clients to treat it as an opaque string. Using IsPUnit would force a format while allowing implementations to use different base units. Further, this is the agreed upon direction for DMTF for expressing units.
[PWG]CapacityUnit is an enum, not an opaque string. Vendors don't get to use whatever they want; they choose from an existing enumerated list of legal values, the same ones in the Values list above. Using ISPUNIT on this (or analogous) property, and having the (for the time being) proxy providers translate from the existing vendor-supplied enum to the corresponding PUNIT string, would not improve interoperability, and would require much more code in the client applications Using the new units proposed in Appendix C.1, for instance, Micrometers = "meter * 10^-6" TenThousandthsOfInches = "inch * 10^-5" Sheets = (no equivalent base-unit) Items = (no equivalent base-unit) Need to add these two values to base-unit table in appendix.
[IBM]No problem, the list has already been expanded in subsequent CRs to fill gaps.
[PWG]The Arch CRs currently do not include either "sheets" or "items" in their lists. We will supply an exhaustive list of the values that must be added to PUNIT.
|
|
Symantec |
Wrong parent class. This new device ought to be considered a LogicalDevice
This subunit does not have most of the characteristics that LogicalDevice exposes. For instance, it does not have state that can be enabled or disabled, so most of the additional properties of LogicalDevice do not apply. However, the subunit does have status. We have modified the class to include the new scalar status properties from Core CR874. When these properties are moved to ManagedSystemElement, the parent class of this class will be changed to MSE and the then-redundant properties will be removed from this class.
|
|
Brocade |
I am not sure what the following text in the description
is for:
Good point. Removed the text.
|
|
Brocade |
Should Id really be something like TrayNumber since it can only be an integer and not a string?
We have tried to preserve the name from the original model. We could change the name to TrayNumber. However, this risks the confusion of users assuming that they are nice numbers like 1, 2, 3; but in real devices they are not necessarily small numbers nor contiguous.
|
|
Brocade |
There really should be a capabilities class for the property MaxCapacity, RemainingCapacity, StackingOrder, PageDeliveryOrientation, OffsetStacking. By inheriting from the right Capability class, you also get the capabilities for managing the Name.
All of these properties are explicitly writable in the model. In previous discussions, we concluded that they were not suitable as capabilities.
|
|
Brocade |
I believe an effort needs to be made to normailize the states to the new proposals in the DMTF.
States or statuses? Please clarify. A component at this low level does not have an independent state. The statuses we have tried to align with the new DMTF proposals. (See reply to last Symantec comment.)
|
|
Brocade |
I don't believe RemainingCapacity is how we handle localization.
Must be a typo here: RemainingCapacity is an integer. Please clarify: what property were you referring to.
|
|
Brocade |
I really think you need to inherit from MSE or below because of the ModelCorrespondence to CIM_ManagedSystemElement.DetailedStatus and CIM_ManagedSystemElement.HealthState"
Agreed. Done. However, when the new status properties (from Core CR874) are moved to MSE, how does one remove them from here? Shall I remove them from this class now and count on inheriting them sometime in the future?
|
|
Brocade |
Need to change the must to shall.
Done. (I copied the definition of InstanceID from SettingData.)
|
|
Comments on v0.94 |
|
|
Symantec |
Duplicate properties. You should not have to repeat the status properties.
Duplicate status properties removed.
|
|
IBM |
the status properties will be fixed. remove from here and add explicit dependency on 911.
Done.
|
|
Comments on v0.95 |
|
|
Symantec |
Wrong parent class
A print output tray is either a logical device or a physical element. Pick one.
We have purposefully put components into either of these buckets. See the core whitepaper for why this is so.
There are only two direct subclasses of ManagedSystemElement; LogicalDevice or PhysicalElement.
Change parent class to CIM_LogicalElement as requested.
|
|
IBM |
Try EnabledLogicalElement
Instead of ManagedSystemElement, LogicalElement or EnabledLogicalElement is more appropriate depending on whether you intend to support state management via RequestStateChange(). I believe change inheritance later to generalize is okay, while changing to be more special is not. Therefore I suggest inheritance from EnabledLogicalElement. If later you decide not to do state change, you can move further up the tree.
PrintOutputTray and the many other components of a printer cannot be enabled and disabled independently. The PWG model of a printer does not support any such operations.
Will change the parent class for PrintOutputTray, and all the other pending CRs for the other similar classes, to LogicalElement.
|
|
Comments on v0.96 |
2007-04-20 |
|
Brocade |
ID is simply the MIB Index which typically is used to map into tables. Does it need to be exposed. It seems ElementName is sufficient.
[PWG] Changed name to SNMPRowId to indicate its legacy origins and use. The property needs to be visible externally to permit clients to correlate status logs and events between SNMP and CIM (proxy) access paths.
|
|
Brocade |
OtherType or is it OtherType Description
[PWG] After searching all the MOF for similar names, changed to OtherTypeDescription. Usage is not consistent in MOF.
|
|
Brocade |
MaxCapacity and RemainingCapacity are mixing multiple meanings in a single value and an attempy whould be made to remove those either using WBEM semantics of a null value or some other case.
[PWG] Added XxxBasis properties to parallel both of these. The XxxBasis property specifies whether the Xxx property contains a real value or is unknown, infinite, etc. This is a traditional part of the printer semantic model. We had tried to retain the original compact SNMP data representation, but, you're right, it is better this way.
|
|
Brocade |
StatusNonCriticalAlerts and StatusCriticalAlerts seem to map to HealthState
[PWG] Both of these can be asserted simultaneously, which cannot be expressed in HealthState.
|
|
Brocade |
StatusOffline, StatusTransitioning, and StatusAvailability should map to our new properties from CIMCore00874
[PWG] Discussed these in detail with Jon Hass. StatusTransitioning will be removed in favor of a new enum value in OperatingStatus. The other printer-subunit-specific status properties cannot be absorbed into the generic statuses of ManagedSystemElement.
|
|
IBM |
Instead of ManagedSystemElement, LogicalElement or EnabledLogicalElement is more appropriate depending on whether you intend to support state management via RequestStateChange(). I believe change inheritance later to generalize is okay, while changing to be more special is not. Therefore I suggest inheritance from EnabledLogicalElement. If later you decide not to do state change, you can move further up the tree. Change to inherit from EnabledLogicalElement (no re-ballot required)
[PWG] Again, the individual subunits of a printer cannot be separately enabled and disabled. Most of the properties of EnabledLogicalElement (and similar classes) do not apply. The state of the printer overall will probably be visible in CIM_Printer.
|
Change History (Mandatory after submission to the TC, May be used by the WGs):
|
Version |
Date |
Short description of changes |
|
0.2 |
2007/02/08 |
Original version |
|
0.3 |
2007/02/08 |
Fixed datatypes of Id and similar fields to uint. |
|
0.4 |
2007/02/14 |
Added Key properties, accidentally omitted. |
|
0.5 |
2007/02/27 |
Responded to IBM comments, including a number of changes detailed in the response. |
|
0.7 |
2007/03/02 |
Fixed formatting of table of comments. |
|
0.8 |
2007/03/07 |
Made most changes requested by comments:
|
|
0.9 |
2007/03/08 |
Shortened discussions around comments. |
|
0.91 |
2007/03/15 |
Answered additional comment. |
|
0.92 |
2007/03/16 |
Changes responding to Brocade comments. |
|
0.93 |
2007/03/27 |
Inherit from ManagedSystemElement instead of ManagedElement. Make all properties read-only to reflect current feeling in PWG. |
|
0.94 |
2007/04/05 |
Add discussions of localization. |
|
0.95 |
2007/04/12 |
Add dependency to Core CR911, which promotes the new status properties up to ManagedSystemElement. Remove the copies of those status properties from this class, since they will be inherited. |
|
0.96 |
2007/04/20 |
Change parent class to CIM_LogicalElement. |
|
0.97 |
2007/05/02 |
Changed Id property to SNMPRowId to make legacy source and usage clear. Removed StatusTransitioning property, to be covered by new enum value of ManagedSystemElement.OperatingStatus. Added property MaxCapacityBasis to specify out-of-band values of MaxCapacity, which is then an ordinary int. Similarly for RemainingCapacity. Changed order of status property names to, e.g., AvailabilityStatus. |
Note that this document
is labeled as "DMTF Confidential". It is intended only for DMTF
member companies and alliance partners.
This Change Request may be withdrawn or modified by subsequent Change Requests.
All submissions MUST comply with the DMTF Patent and Technology policy (http://www.dmtf.org/about/policies/patent-10-18-01.pdf)
Template Sample Version 2.0.0.d