Lloyd,
Thanks for the much needed update summary. Do you think you (or someone
else) could repost this summary with a couple of lines for each item
stating the actual final resolutions? This would be a big help for most
folks so that they don't have to go back and pour over the mailing list
to determine the final resolutions:
> - Evolution of the Interfaces Group
> - Serial Number and Administratively Assigned Printer Name
> - Localization
> - Colorant Value
> - InputMedia Form Parts
> - Manual Feed Timeout
> - All of the Miscellaneous Clarifications
> - Alert Table
> The following are the open issues that will be discussed at the New York
> meeting:
> - Addition of new Channels Group (aka MagicCookie)
> Host Software groups feel that the simple group as proposed by
> David Kellerman would be sufficient for them.
This could be tough, as neither Dave nor I will be attending the NYC meeting,
and without our involvement the "Host Software" side of the issue will not
be supported, nor will direct questioning be possible.
I am requesting that this topic be deferred to the November meeting
in New Orleans.
> - Channel Type TC
> This was closed at the San Diego meeting but Jay Martin raised
> an issue on the mailing list that he still thought the
> definition might be wrong. Bob Setterbo and Bob Pentecost from
> Adobe and HP respectively were asked to respond from their
> companies.
The title of this topic might be a bit confusing to some, so I'd like
to just add that this topic is where the textual descriptions for the
"chPort9100" and "chAppSocket" enums appeared to get reversed in
Ron Bergman's messages requesting updates to the Channel Types list.
In all honesty, I don't know why this remains an issue, since my last
posting on this topic produced a COMPLETE, HISTORICAL RECORD of the
definitions of these channel types. How Ron got them backwards in
the first place is unclear, but notwithstanding, the historical record
should prevail...unless, of course, HP and/or Adobe can comment on this
issue to the contrary.
> - Problem of referencing hrMIB when it hasn't progressed
> Alternatives
> 1. Take over the hrMIB, deprecate all but what we want.
> 2. Bring needed hrMIB objects inside the printer MIB. Don't change
> objects but assign new OIDs.
> 3. Define status without the hrMIB.
This topic is really fascinating, even to the point of stopping ALL progress
on the MIB until it is resolved. I mean, if we remove the dependency on the
HR MIB, doesn't the entire *structure* of the Printer MIB totally fall apart?
(Am I missing something here? If so, can someone please post a simple
summary of the impact of this issue?)
Lastly, I concur with Harry Lewis regarding the need to ensure that the
"TonerCartridgeMissing" alert code is put back into the MIB.
...jay