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