RE: IPP> Comments on MIB access document

[Paul Moore <[e-mail]>]

	>
	>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:[e-mail]]
> Sent:	Tuesday, August 04, 1998 6:40 PM
> To:	Paul Moore
> Cc:	'[e-mail]'
> 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