WIMS> RE: Counter MIB questions

From: Stuart Rowley (Stuart.Rowley@ktd-kyocera.com)
Date: Wed Jul 05 2006 - 21:06:56 EDT

  • Next message: McDonald, Ira: "WIMS> 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@sharplabs.com]
    Sent: Wednesday, July 05, 2006 12:47 PM
    To: Stuart Rowley; McDonald, Ira
    Cc: 'wims@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@sharplabs.com

            -----Original Message-----
            From: Stuart Rowley [mailto:Stuart.Rowley@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

    This archive was generated by hypermail 2.1.4 : Wed Jul 05 2006 - 21:06:39 EDT