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