CIMCoreCR00901.005aem_RBLreplies20070305.htm

<html> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered)"> <title>DMTF Change Request</title> <style>  </style> </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> <h1>DMTF Change Request</h1> <h2>DMTF Confidential</h2> 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. <table class=MsoNormalTable border=1 cellpadding=0 width="90%" style='width:90.0%'> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> DMTF Change Request Number   [sysdevCR006655] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  CIMCoreCR00901 </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> CR Owner Name, Email  [My Name, my.name@company.com] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'> Richard Landau, Richard_Landau@dell.com </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'> Alliance Partner submitting CR request (if applicable) </td> <td valign=top style='padding:0in 0in 0in 0in'> Printer Working Group, pwg.org </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'> Alliance Partner vote history (e.g. SNIA XYZ Approved on 8/12/06) </td> <td valign=top style='padding:0in 0in 0in 0in'>   </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'> Alliance Partner identifier/tracking number (if available) </td> <td valign=top style='padding:0in 0in 0in 0in'>  n/a </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Errata   [Yes/No] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  No </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Short Description </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'> Add new class  CIM_PrintOutputTray to enhanced printer device model. </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Spec, Document or Model(s) Being Changed   [Device Model] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  [Core Model] </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Spec, Document or Model Version Incorporating the Change  [V2.9 Final] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  V2.15 Experimental </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Filename(s) Incorporating the Change [Device_USB.mof] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'> CIM_PrintOutputTray.mof </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Date Originated  [mm/dd/yyyy] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  02/07/2007 </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Date of Last Revision of the Change Request [mm/dd/yyyy] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  02/27/2007 </td> </tr> <tr> <td width="60%" style='width:60.54%;padding:0in 0in 0in 0in'> Dependencies   [smwgCR00567,sysdevCR00555] </td> <td width="38%" style='width:38.7%;padding:0in 0in 0in 0in'>  n/a </td> </tr> </table> 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: <a href="http://isotc.iso.org/livelink/livelink.exe/fetch/2000/2122/3146825/4229629/4230450/4230456/ISO_IEC_Directives__Part_2__Rules_for_the_structure_and_drafting_of_International_Standards__2004__5th_edition___pdf_format_.pdf?nodeid=4230517&vernum=0">http://isotc.iso.org/livelink/livelink.exe/fetch/2000/2122/3146825/4229629/4230450/4230456/ISO_IEC_Directives__Part_2__Rules_for_the_structure_and_drafting_of_International_Standards__2004__5th_edition___pdf_format_.pdf?nodeid=4230517&vernum=0</a> 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) <a name="Requested_Change"></a>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): <a name="Discussion_Points"></a>//add the new class CIM_PrintOutputTray as CIM_PrintOutputTray.mof     // Copyright (c) 2007 DMTF.  All rights reserved. // ================================================================== // CIM_PrintOutputTray // ==================================================================      [Experimental, Version ( "2.15.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_ManagedElement {         [Key, Description (           "The CreationClassName of the scoping printer. The "           "OutputTray is defined in the context of a CIM_Printer, "           "where it is hosted or to which it applies."),        MinLen ( 0 ), MaxLen ( 255 )]    string PrinterCreationClassName;         [Key, Description (           "An identifying name of the scoping Printer. The OutputTray "           "is defined in the context of a CIM_Printer, where it is "           "hosted or to which it applies."),        MinLen ( 0 ), MaxLen ( 255 ),        ModelCorrespondence { "CIM_Printer.PrinterName" }]    string PrinterName;         [Key, Description (           "Indicates the name of the class or the subclass used in the "           "creation of an instance. When used with the other key "           "properties of this class, it allows all instances of this "           "class and its subclasses to be uniquely identified."),        MinLen ( 0 ), MaxLen ( 255 )]    string CreationClassName;         [Key, Description (           "A unique value used by this printer to identify this output "           "subunit. Although these values may change due to a major "           "reconfiguration of the subunit (e.g., the addition of new "           "output devices to the printer), values SHOULD remain stable "           "across successive printer power cycles."),        MinValue ( 1 ), MaxValue ( 65535 ),        MappingStrings { "MIB.IETF|Printer-MIB.prtOutputIndex" }]    uint32 Id;         [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" },        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 OtherType;         [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" },        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;         [Write, 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 may not be changed by management "           "requests; otherwise, the value may be written (by a Remote "           "Control Panel or a Management Application). The value (-1) "           "means other and specifically indicates that the subunit "           "places no restrictions on this parameter. The value (-2) "           "means unknown."),        MinValue ( -2 ), MaxValue ( 2147483647 ),        MappingStrings { "MIB.IETF|Printer-MIB.prtOutputMaxCapacity",           "MIB.IETF|Printer-MIB.prtOutputCapacityUnit",           "MIB.IETF|Printer-MIB.PrtCapacityUnitTC" }]    sint32 MaxCapacity;         [Write, 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 may not be modified by "           "management requests; otherwise, the value may be written "           "(by a Remote Control Panel or a Management Application). "           "The value (-1) means other and specifically indicates that "           "the subunit places no restrictions on this parameter. The "           "value (-2) means unknown. The value (-3) means that the "           "printer knows that there remains capacity for at least one "           "unit."),        MinValue ( -3 ), MaxValue ( 2147483647 ),        MappingStrings {           "MIB.IETF|Printer-MIB.prtOutputRemainingCapacity",           "MIB.IETF|Printer-MIB.prtOutputCapacityUnit",           "MIB.IETF|Printer-MIB.PrtCapacityUnitTC" }]    sint32 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" },        MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]    uint32 StatusAvailability;         [Description (           "Status: If true, there are currently non-critical alerts on "           "this printer subunit."),        MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]    boolean StatusNonCriticalAlerts;         [Description (           "Status: If true, there are currently critical alerts on "           "this printer subunit."),        MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]    boolean StatusCriticalAlerts;         [Description (           "Status: If true, the current state is offline on this "           "printer subunit."),        MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]    boolean StatusOffline;         [Description (           "Status: If true, the current state is transitioning from "           "one value to another on this printer subunit."),        MappingStrings { "MIB.IETF|Printer-MIB.PrtSubUnitStatusTC" }]    boolean StatusTransitioning;         [Write, Description (           "The name assigned to this output tray subunit."),        MinLen ( 0 ), MaxLen ( 63 ),        MappingStrings { "MIB.IETF|Printer-MIB.prtOutputName" }]    string AdminName;         [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;         [Write, Description (           "The current state of the stacking order for the associated "           "output tray subunit. 'FirstToLast' means that as pages are "           "output the front of the next page is placed against the "           "back of the previous page. 'LasttoFirst' means that as "           "pages are output the back of the next page is placed "           "against the front of the previous page."),        ValueMap { "2", "3", "4" },        Values { "Unknown", "FirstToLast", "LastToFirst" },        MappingStrings { "MIB.IETF|Printer-MIB.prtOutputStackingOrder",           "MIB.IETF|Printer-MIB.PrtOutputStackingOrderTC" }]    uint32 StackingOrder;         [Write, Description (           "The reading surface that will be 'up' when pages are "           "delivered to the associated output tray subunit. Values are "           "faceUp and faceDown. (Note: interpretation of these values "           "is in general context-dependent based on locale; "           "presentation of these values to an end-user should be "           "normalized to the expectations of the user)."),        ValueMap { "3", "4" },        Values { "FaceUp", "FaceDown" },        MappingStrings {           "MIB.IETF|Printer-MIB.prtOutputPageDeliveryOrientation",           "MIB.IETF|Printer-MIB.PrtOutputPageDeliveryOrientationTC" }]    uint32 PageDeliveryOrientation;         [Write, Description (           "This property indicates that the output tray supports "           "offset stacking,and if so, whether the feature is enabled. "           "See RFC 3805 Appendix A, Glossary Of Terms, for how Offset "           "Stacking is defined by this document."),        ValueMap { "3", "4", "5" },        Values { "On", "Off", "NotPresent" },        MappingStrings { "MIB.IETF|Printer-MIB.prtOutputOffsetStacking",           "MIB.IETF|Printer-MIB.PresentOnOff" }]    uint32 OffsetStacking; };     // end of class    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.  I'm not the one that has to make your MOFs match DMTF conventions so I don't have a strong opinion on this.  However, most CRs are built by hand and precisely this sort of painful tinkering is done.  Its up to the CIM Core Chair to decide how much he wants you to do and how much he's willing to do. [RBL responses in green, as this is.]Right.  Message received loud and clear.  I understand that we need to burden the editors as little as possible.  They hardly need any more problems to deal with.  We did fix the Values formatting problem, and we have resolved to work around any other mofpretty or similar problems we run across.     <table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0 style='border-collapse:collapse'> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border:solid windowtext 1.0pt; border-left:none;padding:0in 5.4pt 0in 5.4pt'> value/valuemap properties should not include "Other" unless you have an OtherXXX property that accompanies it.   </td> <td width=371 valign=top style='width:243.0pt;border:solid windowtext 1.0pt; border-left:none;padding:0in 5.4pt 0in 5.4pt'> 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.  </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> the value/valuemap do not need to be listed one per line   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.     </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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?)   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.  Fair enough, but this communications status is actually b/w the instrumentation and the managed element to indicate whether you're providing good information.  Hmmm.  I was thinking that the instrumentation would be largely within the device, but you're right if the CIM instrumentation is a proxy provider to a host system's CIM Server, which early implementations will certainly be.  1.  Is it reasonable, though, for us to have a dozen "enabled logical elements" in a printer device, none of which can be enabled/disabled separately?  Seems misleading.  2.  Would it be unreasonable to adopt the four new status properties without inheriting from the EnabledLogicalElement class?   3.  Most of the combined properties of EnabledLogicalElement and ManagedSystemElement woule be either irrelevant (those dealing with state changes) or redundant or about-to-be-deprecated.  Would it be anti-social to respond with NULL for some or most of these properties?   4.  We still need to represent the five status variables that come from the existing printer status objects.   5.  EnabledLogicalElement derives from ManagedSystemElement.  But the printer device is not a system, is not derived from ComputerSystem, and it seemed rather misleading to us to include that implication in the inheritance.   </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> There is already a Description property on ManagedElement. The Name property seems redundant with ElementName on ManagedElement.   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> Accidental collision of Description property name, derived from existing model; will fix.  Change property name to LocalizedDescription with the same semantics.  Caption, unfortunately, is too short (63 vs 255).  Did you mean to say that the existing Description property is too short?  Sorry, that was confusing.  The semantics of ManagedElement.Description do not seem appropriate to this use.  The typical semantics for ManagedElement.Caption are much closer to what is done with printers, so we could have changed to Caption, but that property is too short for the existing model.  (And neither of them is required to be localized.)    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.  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. Got it, thanks.  I need to talk to you about goes in there, though.  Is this even close?  "Instances of this class require an administratively assigned name property that is writable by the user.  Neither ManagedElement.ElementName nor ManagedSystemElement.Name is suitable for this use; the AdminName property is used for this purpose."  </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> Also need at least one Key property.   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> Fixed.    The properties used relate to the printer device instance as the scoping element, since CIM_Printer is not derived from CIM_ComputerSystem.     Why not use InstanceId instead of propagated properties?  There has been a general shift towards using a single property instead of multiple. Good question.  My thought originally was that the properties of the subsidiary object ought to tell one which parent it belongs to;  but the associations do that.  (I have to keep remembering to think CODASYL instead of relational db.)  Will change.  </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> The commented value in the values qualifier do not match the actual value in the valuemap qualifier.   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.  The problem went away when you cleaned up the qualifiers Right.  As mentioned above, we will fix or work around such formatting bugs.   </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> Is there a reason that the valuemap integers are not sequential?   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.   </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> A property like MaxCapacity is generally implemented in an associated sub-class of Capabilities.   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> MaxCapacity is writable in cases where the value is not reliably sensed by the device; not suitable as a capability.  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. Hmmm.  Seems like additional complexity -- another class and an association instance -- for very little benefit.  Proxy instrumentation will never have information to make this distinction.  And these two additional instances would probably be repeated for several more of the new classes.  Can we use the simpler model at least until we gain some user experience with it?   Further, the text in the Description qualifier uses  "may not" where I think you want to say "shall not" Good catch, thank you.  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.   BTW, question about the latest thinking on normative wording.  I believe that MOFs now use SHALL instead of MUST, but is it SHALL or shall?   </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.    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. </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'> IBM </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> CapacityUnits should have the ProgrammaticUnits qualifier and adhere to the rules agreed to by architecture for DSP0004 (arch 72 and 89)     </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'> 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.   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. 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.   If we use ISPUNIT on this (or analogous) property, and the (for the time being) proxy providers translate from the existing vendor-supplied enum to the corresponding PUNIT string, does that improve interoperability?  If that is the direction of the future, it can certainly be done.     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.  No problem, the list has already been expanded in subsequent CRs to fill gaps. The Arch CRs that I have seen do not include either "sheets" or "items" in their lists.  Are there newer lists?  How should one go about adding these two values to the normative lists?  Is it cricket to CR a CR?    BTW, in Arch CR 72, in proposed Appendix C.1, the conversion of "one kilometer per hour" to "3.6 meters per second" is incorrect.  It's "0.28 meters per second." You're welcome.  </td> </tr> <tr> <td width=82 valign=top style='width:53.65pt;border:solid windowtext 1.0pt; border-top:none;padding:0in 5.4pt 0in 5.4pt'>   </td> <td width=261 valign=top style='width:171.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'>   </td> <td width=371 valign=top style='width:243.0pt;border-top:none;border-left: none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt; padding:0in 5.4pt 0in 5.4pt'>   </td> </tr> </table>     Change History (Mandatory after submission to the TC, May be used by the WGs): <table class=MsoNormalTable border=1 cellpadding=0 width=728 style='width:476.65pt'> <tr> <td valign=top style='padding:0in 0in 0in 0in'> Version </td> <td style='padding:0in 0in 0in 0in'> Date  </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'> Short description of changes </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'>  0.2 </td> <td style='padding:0in 0in 0in 0in'> 2007/02/08  </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'> Original version </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'>  0.3 </td> <td style='padding:0in 0in 0in 0in'> 2007/02/08 </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'> Fixed datatypes of Id and similar fields to uint. </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'>  0.4 </td> <td style='padding:0in 0in 0in 0in'> 2007/02/14 </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'> Added Key properties, accidentally omitted.   </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'>  0.5 </td> <td style='padding:0in 0in 0in 0in'> 2007/02/27 </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'> Responded to IBM comments, including a number of changes detailed in the response.   </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'>  0.7 </td> <td style='padding:0in 0in 0in 0in'> 2007/03/02 </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'> Fixed formatting of table of comments.   </td> </tr> <tr> <td valign=top style='padding:0in 0in 0in 0in'>   </td> <td style='padding:0in 0in 0in 0in'>   </td> <td width=484 style='width:4.4in;padding:0in 0in 0in 0in'>   </td> </tr> </table> 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 </div> </body> </html>