IPP> MIB - Responses to Paul Moore's issues with IPP access to MIBs

IPP> MIB - Responses to Paul Moore's issues with IPP access to MIBs

IPP> MIB - Responses to Paul Moore's issues with IPP access to MIBs

Hastings, Tom N hastings at cp10.es.xerox.com
Mon Sep 28 21:21:42 EDT 1998

I've copied Paul's issues that he raised last August with the MIB Access
paper with my responses to:
as well as included in here in the mail message.
There are a number of issues that we need to review as well.
If we have time after going over the bake-off and needed clarifications, I'd
like to go over this paper.

ISSUES with the MIB Access Proposal from Paul Moore with TH replies
File:  ipp-mib-access-issues-from-paul.doc,  8/18/98

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.
TH> Do you have an alternative?  The goal was to leverage the implementation
of Printer MIB agents that are in many network printers today.  So that an
IPP printer implementation that chooses to support the MIB access extension
would be able to do so with minimal extra code in the printer.  The IPP
Printer object implementation would pass the MIB attribute requests to the
SNMP agent, either through the front door using SNMP or through the back
door using internal calls.  In either approach, the access to the SNMP agent
would use the Get and GetNext semantics to access the objects in a subtree.
1.	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 deliberately 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.

TH> Yes, it is a change.  But it is a natural kind of changes, since the IPP
Printer is a logical printer and the MIB is a physical concept.  This is a
time-honored approach to system design.  Some things you want to hide and
some things you don't.
However, even IPP/1.0 does have the 'stopped-partly' concept to reflect the
state of an IPP Printer that has some devices stopped and some not.  So the
concept of multiple devices is already present in IPP 1.0.  See the figures
in section 1.1 and 2.1 which both show multiple devices for a single IPP
Printer object.
Also for the simplest (and most likely) implementation, one IPP Printer
controls one device.  So the difference between the logical and physical
There is no way to think of the Printer MIB as representing several devices
at once, so we couldn't keep the Printer MIB attributes at the same level as
the IPP Printer.
	Note that this is done for some non-MIB attributes as well. 
TH> Yes, in just the same way as the IPP/1.0 "document-format" input
parameter specializes certain Printer attribute values to the specified
document format, so that the Printer attribute isn't representing the union
across multiple document. 

2.	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.

TH> Perhaps we should not call it an object, unless we have operations that
have a device as a target.  We could be more vague, same as we have done for
documents, which are not described as objects.  See section 2.2.
ISSUE 1:  Should we change the description of a device so that it is not an
object?  Yes.

3.	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. 

TH> Agreed.  The name space is structured to achieve the goal of simple
implementation without complex mapping tables from attribute keyword names
in English to Printer MIB objects.  On the other hand, these structured
names are really "attribute group names" like we have in IPP/1.0.  In
IPP/1.0, we have the attribute group names that can be supplied in a
Get-Printer-Attributes operation:

that return more than one attribute in the response.

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

TH> I suggest that the Finisher MIB will add four structured attributes,
since it is an extension to the Printer MIB.
However, for any Job MIB attributes that we want to have access to via IPP,
we should add as real IPP attributes with U.S. English keywords.  There is a
lot more overlap between Job MIB attributes and IPP job attributes already
(on purpose).

5.	The MIB query is optional but is overloaded on the get attributes
	I cannot find out if a printer supports it without trying and
TH> As with any Get-Printer-Attributes query, any supported Operation
attribute that is supplied with unsupported attribute values is ignored and
does not return an error.  Instead, the IPP Printer returns the
"requested-attributes" operation attribute in the Unsupported Attributes
group [2] with only the values that are unsupported, i.e., with the keyword
names of the unsupported attributes as the values.
So an application could supply unsupported MIB attributes along with
supported other attributes and still get back a response.
If we made it a separate operation, so that it could be queried as a value
in the Printer's "operations-supported" attribute, you would still need to
make a query if you wanted to find out.  Instead, you can query a required
MIB object, such as 'prt-att-5-1' (prtGeneralConfigChanges) to see if it
comes back as an attribute with a value, or you get back no attributes. 
ISSUE 2:  Should we add a note at to this method for testing as to whether
the MIB access feature is supported?
	Normally such big pieces of functionality would be a separate
TH>  ISSUE 3:  OK NOT to make MIB access a separate operation?
6.	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 Get-Jobs? What
about printer-status and the MIB status?

TH> Certainly the Job MIB should return both IPP jobs and non-IPP jobs,
i.e., jobs submitted to the printer via some other job submission protocol.
Whether an IPP Get-Jobs operation also returns non-IPP jobs, would be up to
implementation.  NOTE that if non-IPP jobs were returned, there might not be
a "job-uri" attribute, even though there is a "job-id".  On the other hand,
there is no reason why an IPP Get-Jobs operation couldn't manufacture a
"job-uri" for each non-IPP job, as long as it produced the same value for a
job on successive queries.
ISSUE 4: Should we RECOMMEND that non-IPP jobs be accessible via Get-Jobs,
Cancel-Job, and Get-Job-Attributes?  Should we REQUIRE it?

7.	If I don't say what device I want it will go to the 'first' one.
What does first mean? 

TH> The first value in the corresponding IPP Printer object's
"devices-supported" attribute.  See lines 451-452.

	Is it guaranteed to be the same always?  
TH> The same unless the system is reconfigured.

	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).  
TH> ISSUE 5:  Should the "document-format" input parameter affect which
devices are returned or not?  If it MAY, then the first device in the
"devices-supported" might depend on which document-format value was supplied
(and that the implementation supports the "document-format" specializing the
returned attributes).
My suggestion is that "document-format" NOT affect which devices are
returned.  This is simpler and conforms to the definition that the
"document-format" input parameter only reflects what the IPP Printer object
uses to validate jobs which are all "xxx-supported" attribtes.  None of the
Printer MIB attributes are of the form "xxx-supported".

	What should the device list return?
TH> I suggest that the "devices-supported" Printer attribute not be affected
by the "document-format" input parameter, if supplied and if supported.

	What happens if a device is turned off?
TH> ISSUE 6:  Good question.  I suggest that the IPP Printer return the IPP
out-of-band 'unknown' value for each attribute for a device that is turned
off.  It should return real values for any other attributes.  OK?
If the first device is the device turned off, then a Get-Printer-Attributes
with no "which-device" supplied may get back 'unknown' for each attribute,
same as if a particular "which-device" was supplied that was turned off.

8.	You state that for non-printer MIB things you don't 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.
TH> Yes, it is a level shift on purpose, because the "devices-supported" and
the "which-device" only apply to the attribute group names that start with
'prt-'.  The "devices-supported" and "which-devices" (being printers only)
have no meaning when accessing attribute group names that start 'mib-'.
ISSUE 7:  How about saying that the list of devices supported by the
"devices-supported" Printer attribute is the subset of the hrDeviceTable
list of devices that are printers.  For consistency with MIB walks using the
'mib-att-xxx' group name, we should also specify that the order of the
printer devices in the hrDeviceTable be the same order as in the

9.	You do not say what must happen if I send a valid query but the
result is empty. I.e. read the alert table.
TH> ISSUE 8:  Good point.  What should be returned with each SNMPv2 error?
We suggest the following mapping of SNMPv2 out-of-band values for SNMP
objects to IPP out-of-band value for attributes:

SNMPv2 out of band value	IPP out-of-band value or action
noSuchInstance	'no-value'
noSuchObject	ignore the requested attribute and return the
"requested-attributes" operation attribute with only the unsupported values
in the Unsupported Attributes Group [2].

So if requesting the alert table and there are no entries, return:

   "prt-tab-18" = 'no-value'

We suggest the following mapping of SNMPv2 errors to IPP out-of-band
attribute values.  An error cannot be returned, since other valid attributes
may be requested in the same request.

SNMP error	SNMP version	action or attribute value returned
noError(0)	v1	return the requested value of the object
tooBig(1)	v1	make repeated requests of smaller amounts or chunk
the responses back to the client MUST not return an error
noSuchName(2)	v1 compat only	ignore the requested attribute and return
the "requested-attributes" operation attribute with only the unsupported
values in the Unsupported Attributes Group [2].
badValue(3)	v1 only set	can't happen
readOnly(4)	v1 only set	can't happen
genErr(5)	v2 deprecated	return 'server-error-internal-error'
noAccess(6)	v2	return 'client-error-not-authorized'
wrongType(7)	v2 only set	can't happen
wrongLength(8)	v2 only set	can't happen
wrongEncoding(9)	v2 only set	can't happen
wrongValue(10)	v2 only set	can't happen
noCreation(11)	v2 only set	can't happen
inconsistentValue(12)	v2 only set	can't happen
resourceUnavailable(13)	v2 only set	can't happen
commitFailed(14)	v2 only set	can't happen
undoFailed(15)	v2 only set	can't happen

Tom Hastings
(310) 333-6413

More information about the Ipp mailing list