Re: IPP> Comments on MIB access document

[Tom Hastings <[e-mail]>]

Paul,

You ask some good questions.  Yes, it is true that the MIB access
proposal is not exactly the same as the current attribute of the
Printer and Job objects in IPP/1.0.

Here are my replies.

Several ISSUES are indicated that need to be resolved.

Thanks,
Tom

At 18:34 07/16/98 PDT, Paul Moore wrote:
>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.

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

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

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

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

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:  Should we change the description of a device so that it is not
an object?


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

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:

  'printer-description'
  'job-template'
  'all'

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.

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

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:  Should we add a note at to this method for testing as to whether
the MIB access feature is supported?

>
>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 getjobs? What about
>printer-status and the MIB status?

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: 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 dont say what device I want it will go to the 'first' one. What does
>first mean? 

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?

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

ISSUE:  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?

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?

ISSUE:  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 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.

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:  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 "devices-supported".

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

ISSUE:  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