Regarding Chuck's responses to Stuart's original message:
> > 1. PrtSubUnitStatusTC Clarification
> > I think the Availability bit descriptions desparately need
> > clarification. What is the difference between Available and Busy vs.
> > Available and Active? What about Standby vs. Idle (is Standby only
> > for power save mode?) What is Unavailable and OnRequest for?
>> I concur that this Textual Convention needs clarification.
> I assumed that active did not imply selected. I thought this
> was handled by the input table.
The topic of "Busy vs. Active" has arisen now and then over the years,
but we never really seem to post the official consensus (if any). It's
time we did that as quickly as possible.
It may very well be that one of these terms should be deprecated if no
one can submit a compelling argument to differentiate between the two.
Frankly, I'm at a loss to suggest any real (and common) difference
between the two terms, at least in generic terms. However, some scenarios
might support a useful differentiation.
There is at least one scenario in which "Active" could imply the
subunit is currently engaged in useful work, but could be enlisted for
future work (ie, the subunit would queue the request) during processing
of the current task; such would be the case for an incoming request to
print a job via the "Channel" abstraction. In this scenario, "Busy" would
imply something to the effect "I can't talk to you right now, check back
when I'm not currently processing a task." Such would be the case for
certain existing LPD implementations, in which the implementation has a
request queue of 1, thereby rejecting incoming connections while a single
request is being processed.
A useful, yet common scenario for general use inside the printer? Probably
not. Can anyone suggest scenarios to differentiate between "Active" and
"Busy"?
> > 2. hrPrinterStatus when hrDeviceStatus is Down
> > In the table in almost all cases where hrDeviceStatus is Down, the
> > hrPrinterStatus is listed as Idle or Printing or Warmup. According to
> > the HR MIB for hrPrinterStatus:
> > "The current status of this printer device. When
> > in the idle(1), printing(2), or warmup(3) state,
> > the corresponding hrDeviceStatus should be
> > running(2) or warning(3). When in the unknown
> > state, the corresponding hrDeviceStatus should be
> > unknown(1)."
> > Therefore, when hrDeviceStatus is Down, hrPrinterStatus should be
> > Other or Unknown.
>> Here is someone's chance to make an alternate proposal because
> I do not like the current wording that forces this behavior.
> Maybe Harry is correct we should redo the hr variables.
Yeah, I totally agree that this is a problem. This language is what has
kept Underscore from making any effective use of these HR MIB variables
in our "PrintAlert" product. We support any effort to improve the
definitions of these values...as long as the rest of the industry stands
behind those changes and commences shipping product conforming to those
changes. If such support is not publicly shown, then the effort could
very well be waste of time.
...jay