attachment

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7652.24"> <TITLE>CIM> News from Core session today: slight progress. </TITLE> </HEAD> <BODY>  Ira, et al., Good news and bad news from Core today.  Bad news: Neither CR passed the first ballot.  Good news: We want to withdraw one of them anyway, and we have clear guidance about how to get the other one passed.  CIM_PrintAlertLog: - One issue: why not just use the base class?  Good idea.  Ira and I had already discussed using the base class directly before we submitted this CR.  We will withdraw this one and use the base class (CIM_RecordLog) instead.  (Already withdrawn.)  If we wish to preserve the MappingString to prtAlertTable, then we can add this to the base class.  It was asserted that this addition would not be unprecedented, though I have not tripped over any examples.  John Crandall noted that there should be a naming convention for logs rather than a proliferation of subclasses.  Good idea.  I will propose something to Core or Server Management.  CIM_PrintAlertRecord: Issue: Why not use RecordData instead of defining LocalizedDescription?  A fair question.  We do intend to put a lot of data into RecordData, but we have not specified it yet, and we don't want to leave writing something down until we write a Printer Profile, several quarters from now.  Question: Would it be reasonable for us to insert into the Description of RecordFormat a list of the data we intend to publish in there?  Answer: Yes, you can override the Description of RecordFormat or RecordData to describe what you plan to put in there, in advance of a formal profile.  We need to discuss what fields we want to put into the RecordData and what we want to say about them.  For instance, we could include a SHALL list and a MAY list of fields, and for each field, give a very short definition and maybe the mapping string to prtAlertXxx.  And do we wish to move any other fields that are currently broken out into the RecordData string?  (My vote: no, unless forced to do so.)  Another issue will come up eventually, and that is when do we add the list of alert codes to the CIM Message Registry?  And how?  I will argue that we ought to be assigned a region in which the mapping of IANA printer alert codes to CIM message number can be calculated.  Later.  Issue: Why not associate to the actually element instead of defining ComponentClassName/ComponentElementName?  Answer: The alert record is a static object, recorded at some time in the past.  It is intended to capture a snapshot of the condition as it was at that time.  The state of the device is not necessarily the same as it was back then, and it might not be possible to form sensible associations.  Result: Good reason.  Say that in the next draft.  Overall, given the rethinking and rewording necessary, we will have to deal with this CR next week.  I will start work on the last couple classes, too, Interlocks and ConsoleLights, and we'll try to submit all three next Friday.   rick ---------------------- Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO Office +1-512-728-9023, One Dell Way, RR5-3, MS RR5-09, Round Rock, TX 78682 </BODY> </HTML>