I have some comments on the proposed changes.
>> > ----------
From: Binnur Al-Kazily[SMTP:binnur at hpb15650.boi.hp.com]
> Sent: Wednesday, July 31, 1996 11:27 AM
> To: 'pwg at pwg.org'
> Cc: 'Randy Turner'
> Subject: RFC: clarifications to the Printer MIB
>>> The followings has taken from Tom's previous e-mail messages.. Please
> provide your comments on the clarifications suggested by Tom to the PWG
> mailing list (pwg at pwg.org). If no comments are made by next Friday -
> 8/9/96 -(the original mail message was posted July 9th), these
> clarifications will be added to the revised Printer MIB documentation.
> Thanks.
>> 1.
> I suggest that we clarify that if a device does not have NVRAM, that
> it shall still implement some sort of reset. I suggest that we add the
> following sentence at the end of the prtGeneralReset object:
>> *********************************************************************
> 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."
>> 2.
> Add the following text to the end of the first paragraph of 2.2.7
> and the first paragraph in the Media Path Group on page 64 which are
> duplicates of each other and end in "plus a table of separate media
> paths.
>> *********************************************************************
> Each media path row may represent a logical or a physical media path
> in the device. Several logical media paths may represent a single
> physical media path. Each such logical media path expresses the
> capabilities of that logical path. For example, a device may have
> a single physical media path that can accept both short edge first
> and long edge first. An implementation may chose to represent the
> media math of such a device as two logical media paths, instead of
> a single physical media path.
> *********************************************************************
The original message said "Each such row would represent different default
capabilities, such as long edge or short edge duplex binding." I don't
think this should be mixed up with long and short edge feeding. It quickly
becomes very confusing when you start mixing a media path that may be short
edge first or long edge first with input media dimensions that are
specified in the feed and xfeed directions (i.e., what happens if
prtInputMediaDimFeedDirChosen = 8.5" and prtInputMediaDimXFeedDirChosen =
11" but the media path wants short edge first?). I would prefer something
like the following:
*********************************************************************
Each media path row may represent a logical or a physical media path
in the device. Several logical media paths may represent a single
physical media path. Each such logical media path expresses printing
capabilities of that logical path. For example, a device may have
a single physical media path that is used for duplex printing. However,
when duplex printing the printer can alter the orientation of printing
between the two sides such that binding can be done along the short
edge or the long edge of the media. An implementation may chose to
represent the
duplex media path of such a device as two logical media paths, instead of
a single physical media path.
*********************************************************************
>> 3.
> I think we should add the following statement to the Printer MIB
> to make it clear what an interlock is intended to be. I suggest adding
> the following sentence to the end of the first paragraph under
> The Cover Table (page 30, RFC 1759):
>> *********************************************************************
> 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.
>> 5.
> Add the following sentence to the end of the DESCRIPTION of
> prtInputDefaultIndex:
This is a good change. Don't forget to change delete the range restriction
on the SYNTAX Integer32 as has already been done for prtOutputDefaultIndex.
>> *********************************************************************
> This value shall be 0 if there is no default input subunit specified
> for the printer as a whole. In this case, the actual default
> input subunit may be specified by means outside the scope of this
> MIB, such as by each interpreter in a printer with multiple
> interpreters.
> *********************************************************************
>> 7.
> I suggest that we add the following definitions to 2.2.13.2.2:
>> *********************************************************************
> Available means that the printer can accept print jobs.
I think "sub-unit" is more appropriate instead of "printer" since this is
the "Sub-unit Status" section.
>> Idle means that the printer is not working on any print jobs.
I think "sub-unit" is more appropriate instead of "printer" since this is
the "Sub-unit Status" section.
>> Active means that the printer is working on at least one print job.
I think "sub-unit" is more appropriate instead of "printer" since this is
the "Sub-unit Status" 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.
> *********************************************************************
>> ---
> Binnur Al-Kazily Hewlett-Packard Company Internet Solutions Operation
>binnur at boi.hp.com (208)396-6372 KB7WYD DoD #2010
>
Bob Pentecost
Hewlett-Packard Co.
Business LaserJet Division