This was a mistake on my part. I had the wrong pointer in mind. I
thought that there were cases where the MarkerIndex was zero, and that
is not permitted. Instead it was the ColorantIndex that was zero, and
that is explicitly permitted (in RFC3805).
So that's a big OOPS, NEVER MIND to all. Sorry for crying wolf.
rick
-----Original Message-----
From: Ira McDonald [mailto:blueroofmusic at gmail.com]
Sent: Tuesday, November 18, 2008 00:15
To: Landau, Richard; Ira McDonald
Cc: wims at pwg.org
Subject: Re: WIMS> CIM> Yet another strangeness in Printer MIB
implementation.
Hi Rick,
Actually there are common valid use cases - e.g., the 'supply' is
'staples' and is NOT associated with a Marker.
The design error in Printer MIB v1 was calling it Marker Supplies and
then including ALL supplies in the enums
- note that we renamed it PrintSupply for CIM MOFs to reflect actual
intended usage.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect) Chair - Linux Foundation
Open Printing WG Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Mon, Nov 17, 2008 at 4:57 PM, <Richard_Landau at dell.com> wrote:
> Another one for the list of anomalies in Printer MIB implementations.
> Sometimes the prtMarkerSuppliesMarkerIndex is a zero. This is
> supposed to be the index of the marker with which a particular supply
> is associated. By law, indices are nonzero. But someone thought that
> transfer rollers and fusers were consumable supplies that weren't
associated with a marker.
> Surprise! Just try looking up marker zero in the table.
>> Easy to code around, but crummy.
>> rick
>> ----------------------
> Richard_Landau(at)dell(dot)com, Stds & System Mgt Architecture, CTO
> Office
> +1-512-728-9023, One Dell Way, RR5-3, MS RR5-32, Round Rock, TX 78682