WIMS> CIM & Counter Spec>11 Jan Concall at 2PM EST

WIMS> CIM & Counter Spec>11 Jan Concall at 2PM EST

WIMS> CIM & Counter Spec>11 Jan Concall at 2PM EST

wamwagner at comcast.net wamwagner at comcast.net
Mon Jan 8 11:12:02 EST 2007


The next CIM alignment  concall is at 2PM EST on Thursday, 11 January.

Dial In: 1-866-365-4406 
Toll #: 1-303-248-9655 
Passcode: 2635888# 

1. Acceptance of the minutes of 14 Dec.
ftp://ftp.pwg.org/pub/pwg/wims/minutes/cim_061214.pdf

2. It has been almost a month since the last  call, with no published activity, so this call will be mainly a review of progress made privately and when needs to be done next.

3. Although not part of the CIM related activity, I would like to spend some time on the Counter Spec/Counter MIB issue.  Ira had suggested a solution back in November and, as best as I can see, we no further action has been taken. A copy of Ira's suggestion follows.

Thanks,

Bill Wagner
==========================
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: mailto:imcdonald at sharplabs.com?Subject=Re:%20WIMS>%20Fix%20for%20Media%20Used%20accounting%20key%20bug 
------------------------------------------------------------------------ 

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

------------------------------------------------------------------------ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pwg.org/archives/wims/attachments/20070108/63c51957/attachment.html


More information about the Wims mailing list