IPP> Comments on MIB access document

IPP> Comments on MIB access document

IPP> Comments on MIB access document

Paul Moore paulmo at microsoft.com
Wed Aug 5 15:58:24 EDT 1998


I must be being really stupid here. Cos I still dont undertsand

Two Example:

I have an IPP printer that fans out to six devices. Devices-supported
returns six names.

How do I read system.sysdescr of the second device?

How do I read the hrDevice table of the fifth device (to find how much RAM
it has)?

> -----Original Message-----
> From:	Tom Hastings [SMTP:hastings at cp10.es.xerox.com]
> Sent:	Wednesday, August 05, 1998 12:46 PM
> To:	Paul Moore
> Cc:	'ipp at pwg.org'
> Subject:	RE: IPP> Comments on MIB access document
> 
> At 19:57 08/04/98 PDT, Paul Moore wrote:
> >	>
> >	>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-'.
> >
> >So which IPP fan-out device gets queried when I do a get attributes for
> >non-prt MIB OIDS. 
> 
> Any devices that the implementation supports through SNMP.  So if the
> implementation supports a printer, a disk, and memory device MIBs, then
> the 'mib-' attribute group names can be used to access which ever SNMP
> MIB devices are supported.  Which actual device is specified explicitly in
> the
> hrDeviceIndex OID sub-identifier in the 'mib-xxx', so which hrDeviceIndex
> is explicit (not implicit) in each requested attribute.  In the
> following example, the printer is device 4 in the hrDeviceTable in the
> Host Resources MIB.  The name of the printer would be the one and only
> value (and hence the first value) of the Printer's "devices-supported"
> attribute.
> 
> From the MIB access paper:
> 
> The following rules are used to create IPP attribute names to represent
> MIB
> objects:
> 
> 1. The attribute name begins with "mib-".
> 
> 2. The rest of the attribute name is the decimalized OBJECT IDENTIFIER of
> the Object in the MIB.  Each sub-identifier in the OID according to
> [SMIv2], is separated by a PERIOD character (.).  SNMP MIB table indexes
> may be part of an OID and may be an integer (usual), string-valued
> fixed-length, string-valued variable-length, object-identifier-valued, and
> IpAddress-valued according to [SMIv2].  [SMIv2] specifies how each
> sub-identifier for these index data types is represented.  Each such
> sub-identifier is separated by a PERIOD character (.). 
> 
> NOTE:  The "mib-..." names are intended primarily for accessing MIBs other
> than the Printer MIB.  However, the examples in this specification use the
> Printer MIB, since that MIB is familiar MIB to the readers (and these
> examples should work on an implementation the supports the "mib-" names).
> For example: "prtInputMediaName" for device 4 tray 3 is represented as:
> "mib-1.3.6.1.2.1.43.8.2.1.12.4.3"
>                              ^
>                              |
>                              +-- specifies device 4 (which is the printer
> in
>                                                      this example)
> 
> If the implementation had several printers (and other devices),
> the hrDeviceTable would indicate which device numbers are used for
> which devices, say, 4, 6, and 7 were printer devices.  Then the
> three values of the IPP Printer object's "devices-supported" would be
> the names of the three printers, say, "peter", "paul", and "mary".
> 
> The clarification below is that the order of the printers in the
> "devices-supported" attribute must be the same order as the hrDeviceTable,
> 
> so that doing a "MIB walk" with the 'mib-xxx' attribute gets the same
> printer
> objects in the same order as using 'prt-xxx' attribute and stepping though
> 
> each device in order.
> 
> Tom
> 
> 
> >
> >
> >> -----Original Message-----
> >> From:	Tom Hastings [SMTP:hastings at cp10.es.xerox.com]
> >> Sent:	Tuesday, August 04, 1998 6:40 PM
> >> To:	Paul Moore
> >> Cc:	'ipp at pwg.org'
> >> Subject:	Re: IPP> Comments on MIB access document
> >> 
> >> 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
> >
> >



More information about the Ipp mailing list