At 17:31 02/14/97 PST, Ron Bergman wrote:
>Harry,
>>It looks like the object jmResourceName is more confusing than
>descriptive. It is not intended to be the name of the resource
>but is to be used for resources that require a string to be
>returned. For example, fileName(3) and documentName(4) are
>resources that cannot be represented by a numeric value. In
>this case jmResourceAmount would be zero and the actual value
>of the resource is presented in jmResourceName. (I believe
>that this was discussed in last weeks meeting after you left
>for the airport.)
>>In the case of a numeric value jmResourceName would be a
>string of zero length. Use of the object as a name of the
>resource in this case was agreed to be removed in the meeting
>last week.
>>To eliminate some of this confusion the jmResourceName object
>name should be changed to something like jmResourceStringValue.
>>Can anyone suggest a better name?
So now we have:
The Attribute Group (Mandatory) 78
jmAttributeTypeIndex 80
jmAttributeInstanceIndex 81
jmAttributeValueAsInteger 81
jmAttributeValueAsOctets 82
Ok?
>>> Ron Bergman
> Dataproducts Corp.
>rbergma at dpc.com> (805)578-4421
>>>---------- Forwarded message ----------
>>>Harry wrote:
>>One thing I'm finding is that Resource Name seems to be redundant
>with information that should already be in the Printer MIB. I wonder
>how useful resource name is. If we're trying to name a resource like
>OutputBin (3) "Big Bin" - then the name is surely in the printer MIB
>and a server implementation would not be representing this resource.
>If we're trying to get fancy and say MediaType (Paper) "Hillary's
>Pink LetterHead", I really doubt any accounting application will
>be this sensitive. I think a Paper enum (Grade-A, Grade-B etc.)
>for charging purposes is more practical.
>>Anyone else vie for eliminating Resource Name?
>>>Harry Lewis - IBM Printing Systems.
>>>>>