Bob,
Boy, we've gotta give you credit for doing your assigned homework!
So many changes and so little time...
> > *********************************************************************
> > 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.
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.
Regarding your media path comments, I agree entirely with your suggested
text changes. (But have you taken into account the "SouthWestern" feed
direction??? ;-)
> > *********************************************************************
> > 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.
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.
> > 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.
Nice comments, Bob.
...jay