SM> FW: WIMS> Fix for Media Used accounting key bug

SM> FW: WIMS> Fix for Media Used accounting key bug

McDonald, Ira imcdonald at sharplabs.com
Tue Nov 14 14:12:42 EST 2006


Hi,

The Semantic Model (version 2) and WIMS (CIM modelling)
need to resolve the missing unique media used accounting
key problem.

Please read the note below and send your comments to 
'wims at pwg.org' (you must be a subscriber to post - see
'http://www.pwg.org/mailhelp.html').

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: owner-wims at pwg.org [mailto:owner-wims at pwg.org]On Behalf Of
McDonald, Ira
Sent: Wednesday, November 08, 2006 8:17 PM
To: 'wims at pwg.org'
Subject: WIMS> Fix for Media Used accounting key bug


Hi folks,                                    Wednesday (8 November 2006)

For discussion at our WIMS-CIM teleconference tomorrow.

Below is an approach to solving our MediaUsed accounting bug in the
Abstract Counter spec (cs-wimscount10-20050923-5106.1.pdf) and the
corresponding Counter MIB (info-wimscountmib10-20051223.pdf).

Add one NEW element, 'MediaUsed.AccountingKey' in the Abstract Counter
spec and 'icMediaUsedAccountingKey' in the Counter MIB, as follows:

icMediaUsedAccountingKey OBJECT-TYPE
    SYNTAX      DisplayString (SIZE(0..255))
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
        "The locally unique accounting key for this specific media, for
        use with remote accounting systems, network management systems,
        fleet management based on SLAs (service level agreements), etc.

        This accounting key MUST be specified in the visible subset of
        US-ASCII characters (0x20 to 0x7E inclusive).  This accounting
        key MUST NOT contain any control characters (0x7F or 0x00 to
        0x1F inclusive).  This accounting key MUST NOT be localized
        (thus the US-ASCII datatype), unlike the corresponding localized
        'icMediaUsedMediaInfo' object.

        This accounting key is NOT limited to only IPP 'keyword' or
        'name', unlike the related (but more restricted) 'media-key'
        attribute defined in PWG 5100.3.

        Note:  Construction of locally unique values of this accounting
        key is implementation dependent and is NOT standardized."
    REFERENCE
        "icMediaUsedMediaSizeName and icMediaUsedMediaInfo in this MIB.
        media-key (more restricted) in section 3.13.1 of PWG 5100.3."
    ::= { icMediaUsedEntry 12 }

Discussion:

(a) The 'media-key' attribute (member of 'media-col') defined in PWG
    5100.3 is broken for our MediaUsed purposes, because it's restricted
    to IPP 'keyword' (closed set) or 'name' (language tagged, localized)
    syntaxes.

(b) No change is needed to the description or semantics of the Abstract
    Counter spec 'MediaUsed.MediaInfo' (localized) or the Counter MIB
    'icMediaUsedMediaInfo' (localized) - they are still useful for human
    consumption and should keep their "MUST clearly distinguish
    different instances of the same media size" descriptions.

(c) The construction of 'icMediaUsedAccountingKey' values is defined
    above as implementation dependent for simplicity of specification.
    But Chris Story (Ricoh) seemed to want a parseable standard format.
    So below is an interoperable way to construct unique values of
    'icMediaUsedAccountingKey'.

(d) This new 'icMediaUsedAccountingKey' is specified as max length 255
    (rather than 63) for compatibility with similar elements already
    implemented in legacy systems.

(e) In order to be machine-readable and NOT be server-side localized,
    values of 'icMediaUsedAccountingKey' MUST be in a single fixed
    charset.  But we could allow use of UTF-8 (instead of US-ASCII).


Questions:

(1) Do you prefer using UTF-8 (the IPP default charset), for better
    compatibility with legacy accounting systems (IPP, SNMP, etc.)?

(2) Do you think we should add the complicated (but interoperable)
    method for constructing unique values described in ABNF and prose
    below as a RECOMMENDATION?


Comments?

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
------------------------------------------------------------------------

        Recommended Method for Creation of Accounting Keys

Conforming Counter MIB implementations SHOULD construct values of
'icMediaUsedAccountingKey' according to the following ABNF [RFC4234],
for interoperability and user-friendly behavior.

The core productions DIGIT, HEXDIG, VCHAR are imported from [RFC4234].

Note:  The OPTIONAL final element 'media-uuid' alone is sufficient to
create unique values of 'icMediaUsedAccountingKey' but is opaque.

acc-key = media-size-name *[ ";" media-property ] [ ";" media-uuid ]
    ; set of media properties concatenated into one accounting key

media-property      = media-back-coating /
                      media-color /
                      media-form-parts /
                      media-front-coating /
                      media-hole-count /
                      media-order-count /
                      media-pre-printed /
                      media-recycled /
                      media-type /
                      media-weight /
                      media-custom

media-back-coating  = "mbco" "=" keyword-or-name
    ; media back coating (e.g., 'glossy' or 'satin')
    ; see section 3.13.10 'media-front-coating and media-back-coating'
    ; in PWG 5100.3
    ; for complete list of standard keywords

media-color         = "mcol" "=" keyword-or-name
    ; media color name (e.g., 'white' or 'custom-media-color-mauve')
    ; see section 4 'Media Color Names' in PWG 5101.1
    ; for complete list of standard keywords and precise ABNF
    ; see also 'prtInputMediaColor' in RFC 3805

media-custom        = custom-tag "=" ( name / number)
    ; media custom property (e.g., 'chp-tooth=17')

media-form-parts    = "mpar" "=" integer
    ; media form parts (e.g., '1' or '3')
    ; see 'prtInputMediaFormParts' in RFC 3805

media-front-coating  = "mfco" "=" keyword-or-name
    ; media front coating (e.g., 'none' or 'matte')
    ; see section 3.13.10 'media-front-coating and media-back-coating'
    ; in PWG 5100.3
    ; for complete list of standard keywords

media-hole-count    = "mhol" "=" integer
    ; media pre-drilled hole count (e.g., '0' or '3')
    ; see section 3.13.6 'media-hole-count' in PWG 5100.3
    ; for standard range and semantics

media-order-count   = "mord" "=" integer
    ; media number of sheets in sequence (e.g., '3' for third-cut tabs)
    ; see section 3.13.7 'media-order-count' in PWG 5100.3
    ; for standard range and semantics

media-pre-printed   = "mpre" "=" keyword-or-name
    ; media pre-printed (e.g., 'blank' or 'letter-head')
    ; see section 3.13.15 'media-pre-printed' in PWG 5100.3
    ; for complete list of standard keywords

media-recycled      = "mrec" "=" keyword-or-name
    ; media recycled (e.g., 'none' or 'standard')
    ; see section 3.13.11 'media-reycled' in PWG 5100.3
    ; for complete list of standard keywords

media-size-name     = "msiz" "=" size-name
    ; media size name (e.g., 'na_letter_8.5x11in' or 'iso_a4_210x297mm')
    ; see section 5 'Media Size Self-Describing Names' in PWG 5101.1
    ; for complete list of standard keywords and precise ABNF
    ; see also 'prtInputMediaName' in RFC 3805

media-type          = "mtyp" "=" keyword-or-name
    ; media type name (e.g., 'stationery' or 'custom-media-type-splash')
    ; see section 3 'Media Type Names' in PWG 5101.1
    ; for complete list of standard keywords and precise ABNF
    ; see also 'prtInputMediaType' in RFC 3805

media-uuid          = "muid" "=" 32HEXDIG
    ; media UUID (128-bits encoded as 32 hexadecimal digits)
    ; see section 4.1 'Format' in UUID URN Namespace (RFC 4122)
    ; see also ISO/IEC 9834-8 | ITU-T Rec. X.667
    ; see also DCE: Remote Procedure Call (Open Group CAE C309)

media-weight        = "mwei" "=" keyword-or-name
    ; media weight in grams per square meter
    ; see section 3.13.9 'media-weight-metric' in PWG 5100.3
    ; see also 'prtInputMediaWeight' in RFC 3805

custom-tag          = "c" vendor "-" keyword
    ; custom tag (e.g., 'chp-tooth')

vendor              = keyword
    ; vendor (e.g., 'hp' or 'ibm')

keyword-or-name     = keyword / name
    ; standard keyword or custom name
    ; see section 4.1.3 'keyword' and section 4.1.2 'name' in
    ; RFC 2911

keyword             = lowalpha *( lowalpha / DIGIT / "-" )
    ; standard keyword (lowercase, digit, hyphen - no dot or underscore)
    ; see section 4.1.3 'keyword' in RFC 2911

name                = 1*VCHAR
    ; custom name (visible US-ASCII - no space, semicolon, equal sign)
    ; see section 4.1.2 'name' in RFC 2911

size-delimiters     = "_" / "."
    ; underscore for size parts and dot (decimal point) for dimensions
    ; see section 5 'Media Size Self-Describing Names' in PWG 5101.1

size-name           = *( keyword / name / size-delimiters )
    ; see section 5 'Media Size Self-Describing Names' in PWG 5101.1

integer             = 1*DIGIT
    ; unsigned integer number (e.g., '0' or '123')

lowalpha            = %x61-7A
    ; lowercase alpha (a-z)

number              = integer [ "." integer ]
    ; unsigned integer or real number (e.g., '7' or '1.34')

------------------------------------------------------------------------

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.0/524 - Release Date: 11/8/2006
 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.14.5/534 - Release Date: 11/14/2006
 



More information about the Sm mailing list