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