This has been a pretty interesting discussion, one we have similarly
touched on in the past but not in detail. I think for the purposes
of host software support of printer models, it is reasonable to
assume that, when a application is developed, that some set of
known product support is included within the application.
When the application is started, a "scan" is made of the printing
topology to find out which of the devices on the network that the
application has "knowledge" of. As far as the registry of known
hrDeviceIDs, it would be nice of there was one big registry, but
what I think you will find, is that manufacturers will be
carving out a section of their vendor-specific OID tree for product
OIDs. This does not make it that much more difficult than a single
primary repository for such OIDs, since printing application vendors
need to focus on a core set of printer models they want to
specifically support...and during this process they can grab the
specific vendors' product OIDs at that time.
In short, OIDs are definitely the way to go, and if its possible,
I would like to see a single device registry also; except, not just
for printers....I would like to see the industry as a whole have a
way to translate hrDeviceIDs to actual product strings for all of
their devices. I could still do it with vendor specific device OID
trees, it would just take a little more time.
Besides, I would hate to see the domain of the hrDeviceID problem
get splintered off into so many different device class registries,
all located in different places, managed by different entities, with
different rules and policies.
I think we should adopt a strategy of using OIDs to uniquely identify
product models and approach the IETF or other working groups
(possibly at the next network management open area meeting in
December) about establish such a singular hrDeviceID registry.
Just my $0.02
Randy
Harry Lewis wrote:
>> Jay Martin wrote-
>> >During the PMP conference call last Friday (Oct 18), I brought up
> >the question of how a client can accurately determine the precise
> >printer model for an agent of the Printer MIB.
>> Jay, I'm glad you brought this up. A very valid requirement and the
> fact that it's surfacing so intensely is a good sign of growing
> RFC1759 oriented software support!
>> >I went on to say that Underscore has been unable to locate any
> >relevant MIB object (either in the Printer MIB or other MIB) that
> >can give us that information.
>> Actually, you did more - you proposed or suggested) a prtGeneral object
> to address the need for printer Model identification. Your idea has
> the advantage of symmetry with similar Input and Output printer MIB
> objects as well as a "common sense" containment of printer attributes
> within the printer MIB.
>> >Harry Lewis was kind enough to point out that the hrDeviceID object
> >in the Host Resources (HR) MIB does indeed exist to provide exactly
> >that kind of information.
>> Given that it's October, it may have been more like trick-or-treat than
> kindness... anyhow... it's true. The fact that no one seems to
> remember the hrDeviceID scenario probably means that you have developed
> a healthier ability to block out the memory of extremely painful
> experiences. Remember? "Common sense containment" was not our forte
> in those early days!
>> >Well, upon further investigation, Harry was 110% correct. (Sorry, Harry!)
> >The hrDeviceID object is *exactly* what we've been looking for!
>> No apology needed. I think the key point here is, although distasteful,
> I don't believe we can say the MIB is substantially "broke" in this
> regard. So, by our guidelines, we shouldn't be adding a new object,
> even though the symmetry is very tempting.
>> >Therefore, while it's great that we won't have to add a new MIB object
> >to the prtGeneral Group, it is imperative that all Printer MIB implementers
> >accurately implement the hrDeviceID object for all of us software vendors.
>> I agree. Easy for me to say, huh? Remember, I'm the guy who had my
> hrPrinterDetectedErrorState bits backward. Can't win them all!
>> >PS: Following on the heels of this topic should be a discussion as to
> > how printer vendors can publish their printer model OID values in
> > a general and public manner so that developers can stay abreast of
> > the set of defined values. To my knowledge, no such general repository
> > exists for this purpose (please correct me if I'm wrong here!).
> >
> > If no such Internet-accessible repository exists, then Underscore
> > would be willing to maintain such a repository as part of the PWG
> > ftp site. Let's get this going as soon as possible!
>> I have already posted this portion of the IBM enterprise MIB. I don't
> have the structure memorized or in front of me but I think I took the
> liberty to create an "enterprise" directory on PWG and put my stuff
> under /IBM. I suggest everyone follow suite if agreed.
>> Harry Lewis - IBM Printing Systems