If we were to define another naming scope, say "attributes", that reflected
object-for-object, the data objects that are in our MIBs, then I would be
less opposed. To some degree we have already started doing this that in the
existing IPP 1.0 printer object attribute set.
The fact that we are switching naming scopes (printer-attributes over to
SNMP OIDs) in midstream seems a little odd, and emphasizes the technical
"shortcut" we are attempting, thus confusing the IPP model. I would much
prefer us to extend IPP the way we originally intended, through the use of
additional printer attributes.
I think I will always have reservations about doing this, but if the PWG
decides they want to do this anyway, then I would urge the PWG to include
text in whatever document is generated that says something like "If this
mechanism is implemented co-resident with an existing SNMP agent, then the
mechanism must support, at a minimum, the minimum level of security that
the SNMP agent provides for the same objects". This should be a mandatory
compliance statement, and not just a strongly worded suggestion. This would
give future network administrators at least some comfort that there printer
MIB data cannot be "hacked".