clarifications to the Printer MIB

clarifications to the Printer MIB

clarifications to the Printer MIB

Bob Pentecost bpenteco at boi.hp.com
Fri Aug 2 17:24:19 EDT 1996


Here are some answers to Jay's comments (some parts of the message were 
deleted to make this shorter).


Bob




> > ----------
From:  JK Martin[SMTP:jkm at underscore.com]
> Sent:  Friday, August 02, 1996 1:32 PM
> To:  bpenteco at boi.hp.com
> Cc:  pwg at pwg.org
> Subject:  RE: clarifications to the Printer MIB
>
>
> > > *********************************************************************
> > > If a device does not have NVRAM, the device shall none the less 
respond
> > > to a SET with the value resetToNVRAM(5) with some sort of "warm 
reset"
> > > that resets the device to some implementation-defined state that is
> > > preferaby under control of the system administrator by some means
> > > outside the scope of this MIB specification.
> > > *********************************************************************
> >
> > I would prefer that the device reset to its power on state since that 
is
> > most likely the only state that it will know. I don't think that a 
device
> > that has no NVRAM will implement a "state that is preferaby under 
control
> > of the system administrator by some means outside the scope of this MIB 
> > specification."
>
> It's really hard to imagine that we can actually force printer vendors
> to respond to any kind of reset command.  Hey, if you can do it, then 
great.
> Otherwise, the device should just respond with some sort of 
"other/unknown"
> value.


I think Tom's clarification should read "If a device does not have NVRAM, 
the device shall none the less respond to a SET with the value 
resetToNVRAM(5) with some sort of 'warm reset' that resets the device to 
some implementation-defined state." The recommendation of being able to 
control the state by means outside the MIB is asking quite a lot. If a 
device can't do a reset, then its "implementation-defined state" is the 
same as it was before.


>
> What do other printer vendors say about this?  As software developers,
> we really need to know whether this is something we should expect to
> support as a standard feature in our software.
>
>
> > > *********************************************************************
> > >    An interlock is a mechanism that stops the printer from operating
> > >    when the interlock is in the interlockOpen or interlockClosed
> > >    state, depending on implementation.
> > > *********************************************************************
> >
> > This statement implies that doorOpen or doorClosed will not stop the
> > printer from operating and I don't think that should be the case. On 
the
> > LaserJet 5Si we have covers/doors (interestingly, the object is
> > prtCoverStatus, but the values are doorOpen and doorClosed) that stop 
the
> > printer from printing and we have interlocks between the printer and
> > input/output devices that can also cause printing to stop. The alert 
table
> > tells (via critical/warning) whether printing is stopped and whether 
the
> > interlock or cover being opened or closed is the problem; however, just 
> > looking at prtCoverStatus doesn't reveal whether or not there is a 
problem.
> >
> > Whether something is a cover/door or an interlock should be 
implementation
> > specific.
>
> I'm really glad you've brought up this issue, Bob.  For the longest time 
I
> had no idea why there was "cover" vs. "door" in name choices.  If nothing
> else, we should normalize these names--just choose one and be done with 
it.
> (According to IETF rules, we can rename enum symbols, right?)
>
> Regarding the difference between a "cover" and an "interlock", I am again
> confused.  I can understand if one wants to define an "interlock" as some
> sort of device that causes the printer to stop printing if its state is
> the boolean state "X" (rather than "Y"); however, to define "interlock"
> such that EITHER "X" or "Y" can indicate that printing has stopped (due
> to the implementation) is really pretty useless.
>
> I mean, how are we (as software developers) supposed to know the 
difference?
>
> You might reply, "Just look at the Alert Table to see if you have a 
critical
> alert (ie, printing has stopped), then resolve the value of the 
associated
> Group (which points to the interlock) and that should tell you that 
Vendor Z
> says 'off' implies 'stop printing'."  Egads.  What problem is this 
solution
> trying to solve, anyway??
>
> Define an "interlock" so that a value of "X" means "no problem" and the
> value of "Y" implies "problem present"...and all vendors implement them
> the same way.


Agreed. To me, an interlock must be closed for the printer to work. On my 
printers, the covers are interlocks and must be closed for printing. If a 
cover is open, but doesn't affect printing, does anyone care? It may look 
bad, but everything works fine.
>
> Better yet, I suggest we eliminate the concept of "interlock" altogether!
> Why is the concept of "cover" vs. "interlock" even presented to the 
outside
> world, anyway?  It's even stranger that interlocks are listed under the
> "Cover" Group.  Very, very strange.
>
>
> Bob, this comment of yours is pretty important IMHO:
>
> > The alert table
> > tells (via critical/warning) whether printing is stopped and whether 
the
> > interlock or cover being opened or closed is the problem; however, just 
> > looking at prtCoverStatus doesn't reveal whether or not there is a 
problem.
>
> This is a real failure on our part in defining the data model for the
> printer represented by the MIB.  We have lots of "prtXXXStatus" objects,
> and these values are supposed to be used by management apps to determine
> the precise nature of the problem (where the Alert Table identifies the
> problematic Group).  However, when it comes to the prtCoverStatus, we 
can't
> really use (most of) the assigned values due to the 
"implementation-specific"
> assignments of the values.
>
> This rots and should be changed.
>
>
> Regarding your many (similar) suggestions about Tom's proposed additional
> definitions for "Available", "Idle", "Active" and "Busy":
>
> > I think "sub-unit" is more appropriate instead of "printer" since this 
is
> > the "Sub-unit Status" section.
>
> I think I know where you're coming from, but I (for one) would like to
> see those kinds of definitions in that section.  Perhaps what we need
> is to introduce those "refinements" of the terminology as they would
> apply to a specific Group or situation, possibly in the last paragraph
> of that section.


I didn't mean the clarifications don't belong where suggested, only that 
they are for sub-units and not the entire printer.
>
>
> > > Busy means that the printer is not able to accept print jobs
> > > for some period of time, such as because the printer is in a
> > > power saving state.
> >
> > I think "sub-unit" is more appropriate instead of "printer" since this 
is
> > the "Sub-unit Status" section. The example of the reason being in power 
> > saving state is wrong (that would be "Available and Standby").
> >
> > Busy means that the sub-unit cannot do anything more. An input tray is 
busy
> > when paper is being pulled from it. I suppose an input tray would be 
active
> > if it can feed more than one marker at a time and it is feeding only 
one,
> > but for our engines, inputs are either busy or idle.
>
> Perhaps a more general question here is whether all defined values
> are valid for all defined Groups, or if some values are not applicable
> to certain groups.  Your scenario about input trays being only in the
> "Busy" or "Idle" states illustrates the scenario where "Active" is not
> valid for that Group (at least for HP products).
>
> This may seem like a nit to some folks, but for external management
> apps (such as those Underscore develops), this can be a big deal.  For
> example, if we fetch the status of an Input unit on one printer and
> find that the status value indicates "Active" -- but on another printer
> the same (apparent) condition is declared by "Busy" -- how are we
> supposed to write anything but ugly, non-obvious, spagetti,
> special-case-for-every-type-of-printer software?
>
> As a special "hint" of things to come, just consider the disastrous 
results
> of the recent PWG Bake-Off with regard to the combinations of values
> for the "Magic Decoder Ring" indicating overall printer status (ie,
> hrDeviceStatus, hrPrinterStatus, hrPrinterDetectedErrorState).
>
> [Note:  You might be scratching your head saying "I thought the Bake-Off
>         was a success".  Well, it wasn't, IMHO, but I'll send those 
comments
>         in a separate posting.]
>
> Defining when and how the defined Sub-unit Status values are to be used
> is essential if mgmt apps are supposed to present the "true" state of
> the printer.
>
> 	...jay
>
>



More information about the Pwg mailing list