WIMS> RE: Counter MIB questions

WIMS> RE: Counter MIB questions

McDonald, Ira imcdonald at sharplabs.com
Fri Jul 7 11:54:25 EDT 2006


Hi Bill,
 
I agree that 'icMediaUsedMediaInfo' is overloaded with two probably
incompatible uses, but it isn't the MIB that did this overloading.  This
is a bug in the PWG Candidate Standard Imaging System Counters
(PWG 5106.1) - see section 5.3 on the bottom of page 27.
 
This bug cannot be fixed in the MIB independently, without revision 
of the source document's element semantics.
 
Cheers,
- Ira
 

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 

-----Original Message-----
From: wamwagner at comcast.net [mailto:wamwagner at comcast.net]
Sent: Thursday, July 06, 2006 4:36 PM
To: McDonald, Ira; 'Stuart Rowley'
Cc: wims at pwg.org
Subject: Re: WIMS> RE: Counter MIB questions


OK. Ira, it seems that you agree with Stuart that: 

icMediaUsedMediaSizeName DisplayString and

icMediaUsedMediaInfo SnmpAdminString

both are not localized. 
 
The former is a PWG 5101.1 defined keyword; the latter is freeform in that
it is not a public-spec defined keyword, but operationally should be one of
a set of strings defined for use in a particular environment or with  a
particular application.
 
This appears to overload icMediaUsedMediaInfo as both a qualifying
descriptor for media identification and as a description for human
consumption.
 
Since the MIB is informational only (pending prototyping), and Stuart may be
doing the prototyping, I would suggest that we collect the issues discovered
during this effort and define an updated version of the MIB for resubmission
as a candidate standard. 
 
Bill Wagner
 
-------------- Original message -------------- 
From: "McDonald, Ira" <imcdonald at sharplabs.com> 


Hi Stuart,
 
The ASCII keyword in '...SizeName' should NOT be localized, 
but the equivalent elements in '...MediaInfo' ARE supposed to 
be localized.
 
But, because '...MediaInfo' in the Abstact Counter spec (PWG 
5106.1) and Counter MIB is required for the key distinguishing 
two instances of the same size media (e.g., by color), it's highly
undesirable to change the value of '...MediaInfo' when the printer
locale changes -  lousy side effects for accounting applications.
 
Bill - I consider this a probable errata against the Counter MIB.
 
Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 

-----Original Message-----
From: Stuart Rowley [mailto:Stuart.Rowley at ktd-kyocera.com]
Sent: Wednesday, July 05, 2006 9:07 PM
To: McDonald, Ira
Cc: wims at pwg.org
Subject: RE: Counter MIB questions



Hi Ira,

 

Thanks for the quick reply. 

 

The description for icMediaUsedMediaSizeName says:

 

"The media size self-describing name for this specific media,

for use with remote network management scripts and GUIs,

specified as a Unicode string encoded in UTF-8 (RFC 3629)

in the language specified in 'icGeneralNaturalLanguage'.

 

...so would this ASCII keyword be localized...?

 

Thanks,

 

Stuart


   _____  


From: McDonald, Ira [mailto:imcdonald at sharplabs.com] 
Sent: Wednesday, July 05, 2006 12:47 PM
To: Stuart Rowley; McDonald, Ira
Cc: 'wims at pwg.org'
Subject: RE: Counter MIB questions

 

Hi Stuart,

 

I copied the WIMS list, so others could see my remarks and chime in.

 

The significance of icMediaUsedMediaSizeName being DisplayString is

that it MUST be strict ASCII (it's a _keyword_ that follows the format in

PWG 5101.1, not a free form name - even a custom size name has a

format and MUST be strict ASCII).

 

icMediaUsedMediaInfo is a description that makes '...SizeName' unique for 

instances of different (but same size) media.  Because the IETF leaned

on us hard to make all future MIB descriptive strings be internationalized,

it's of type SnmpAdminString (UTF-8) and localized.

 

Now - nothing prevents you from making the "localized" media info in

Kyocera products be of the form:

 

  media-info = english-media-identifier ":" localized-description

 

So that your accounting applications use the invariant identifier and

save the localized-description (if at all) in a separate database field

that's informational.

 

Or you could cheat (I don't recommend this) and leave the value of

icGeneralNaturalLanguage empty and just support all descriptive

fields in US-English only (the default) - I _really_ don't recommend

this approach, because it's not very customer-friendly.

 

Hope this helps,

- Ira

 

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com 

-----Original Message-----
From: Stuart Rowley [mailto:Stuart.Rowley at ktd-kyocera.com]
Sent: Wednesday, July 05, 2006 1:47 PM
To: McDonald, Ira
Subject: Counters MIB questions

Hi Ira,

 

I hope you had an enjoyable 4th of July weekend. 

 

I have a couple questions about the Counters spec and MIB regarding media
used.

 

There are 3 objects used to describe the media size and type.

icMediaUsedMediaSizeName DisplayString,

icMediaUsedMediaInfo SnmpAdminString,

icMediaUsedMediaName SnmpAdminString

 

What is the significance of icMediaUsedMediaSizeName using DisplayString and
the others using SnmpAdminString?

 

In the MIB it lists all three as being localized, but it seems only
icMediaUsedMediaName should be localized. I need icMediaUsedMediaSizeName
and icMediaUsedMediaInfo to be used by our accounting apps to identify the
size and type for billing purposes. This would be hard to achieve using
localized strings. Our apps would need to read standardized names from these
two objects. Am I missing something?

 

Thanks,

 

Stuart

 

Stuart Rowley

Network Product Mgr.

Kyocera Technology Development


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.9/382 - Release Date: 7/4/2006
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20060707/ee7bf2c3/attachment.html


More information about the Wims mailing list