IPP Mail Archive: IPP> Comments on MIB access document

IPP Mail Archive: IPP> Comments on MIB access document

IPP> Comments on MIB access document

Paul Moore (paulmo@microsoft.com)
Thu, 16 Jul 1998 18:34:27 -0700

This document proposed many extremely significant changes to IPP. They are
so radical that I do not thing that they can be accepted simply as an
optional extension to 1.0. Many of the issue it tries to solve are very
valid - but this is not the right way to address them.


The current model is very strong on hiding the physical details of fanning
out. The only thing exposed is a logical printer - the fact that this may
represent multiple devices is deliberatly not exposed. This proposal turns
this 180 degrees and explicitly exposes this. No comment on whether this is
good or bad - I merely point out that this is a BIG change to slip in via an
optional extension for accessing MIBs.

Note that this is done for some non-MIB attributes as well.


The device is described as being an 'object'. This challenges the whole
concept of an object in IPP. Everywhere else an Object can receive
operations and has a URI; the device does neither. Having said that, a model
that does expose 'devices' and 'objects' but that does not represent such a
fundamental construct (device) as a object seems very strange.


This scheme introduces a structured namespace. No comment on whether this is
good or bad - I merely point out that this is a BIG change from the flat
list in the main model.


The printer MIB is given a special place in this scheme. What about the job
mib or the finisher mib.


The MIB query is optional but is overloaded on the get attributes operation.
I cannot find out if a printer supports it without trying and failing.
Normally such big pieces of functionality would be a separate operation.


What is the relationship between the information I obtain via the MIb query
and the data I obtain via the other queries? Will the result of querying the
job mib be the same as the result of doing a getjobs? What about
printer-status and the MIB status?


If I dont say what device I want it will go to the 'first' one. What does
first mean? Is it guaranteed to be the same always?
How do I support intelligent pools (If I send a PS file there is a choice of
two printers, if I send PCL there is a choice of 4. Only 2 printers are
available for large jobs, but if i send a small job there is a choice of 4).
What should the device list return?
What happens if a device is turned off?


You state that for non-printer MIB things you dont have to say what the
device is because this is implicit in the OID. There is a level shift here.
The devices enumerated by the proposed IPP device list is not the same as
the device list in each printer. A printer will have a printer device, a
disk, some RAM, etc.


You do not say what must happen if I send a valid query but the result is
empty. I.e. read the alert table.