Scott,
This is an excellent clarification for those, like myself, who have been
trying to follow the discussion with minimal time invested. Thanks.
Using "stringified OIDs" has at least one additional benefit that I can
think of: it forces the implementation to maintain EXACTLY the same
semantics for the attributes. Thus, there can be no temptation to fix or
extend the semantics of those attributes that may be less than perfect in
their current form.
Thanks,
Angelo
-----Original Message-----
From: Scott Isaacson [SMTP:SISAACSON at novell.com]
Sent: Tuesday, April 28, 1998 10:55 AM
To: ipp at pwg.org; Angelo.Caruso at usa.xerox.com
Subject: Re: RE: IPP> Using OID access with IPP/SDP
Angelo,
>>> "Caruso, Angelo " <Angelo.Caruso at usa.xerox.com> 04/27 8:49 AM >>>
>Perhaps someone would please enlighten me as to why we need to build
Printer
>MIB OID access into IPP. I thought the intent was to extend the IPP
>attribute list to eventually cover all the printer MIB stuff. Why is this
so
>difficult?
In the original "Sub-Units" proposal that I presented in Portland, I showed
a
mapping from MIB OIDs to IPP attribute names. It not really a complete
mapping,
but examples and some rules of how to complete the mapping.
This seemed simple enough to me. This is the direction that I thought we
were
going.
Some of the comments on the proposal during the meeting were:
1. Since an implementation of IPP with Printer MIB sub-unit support will
most likely
be co-resident with a Printer MIB agent which already names things with
OIDs,
it would be a waste of resources to require that implementation and agent
to translate back and forth between strings and OIDs. So, in order to
"extend the IPP attribute list to eventually cover all the printer MIB
stuff." the
thought process was to name the new attributes by their stringified OIDs
rather than some arbtrary symbolic name
2. The discussion seems to be focused on now "how hard can it be" but "is it
necessary" since we already have SNMP.
3. If we stick with arbitrary new strings for attributes, it might be
harder to get at
other MIBs using the same mechanism without a full mapping document. For
example,
the Finishing MIB. If we just go with stringified OIDs we can easily extend
that to any
MIB object OID without having to show a mapping to the IPP attribute name.
These are just the thoughts behind the disucsisons that I have heard.
Scott