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