Draft Printer MIB Review Results:
This document is a compiled version of the review results that
was done by the individuals that took the time to review the Draft
Printer MIB.
Note: In time this document will contain the review contributions
outside of HP, as well.
Send in your comments/questions to: Binnur Al-Kazily.
- Textual Conventions (TC):
- The use of textual conventions in the document was disliked
by almost everyone.
- Textual conventions should be grouped in some logical order.
Ex: PrtChannelTypeTC & PRTChannelStateTC are not any where
near each other in the TC section.
- The TC syntax of "PrtxxxTC" should be followed through
out the document.
- Difficult to find reference to different types; an appendix
should be added which contains the master list.
- Remove the excessive "enumeration type" comment
from the body of the objects if Textual Convention type is used.
- Document layout:
- It is hard to scan the document and see where the description
of a new group begins.
- There should be an easy reference to objects in a table of
contents, or as such.
- The document should be spelled checked.
- Information should be added regarding to accessing the ISO
documents.
- As appropriate, the objects should have a specified range
to help with development and testing.
- Update & correct:
- The header & footer section of the document.
- Problems with smart quotes through out the document should
be corrected.
- The author & the PWG meeting attendee section.
- Request for comments section on the front page.
- Table of contents.
- References to Channel group should be changed to "Print
Job Delivery Channel" throughout the document.
- Pg. 6 - 2nd paragraph "
alert information
about printer can be thought of
" "printer"
should be "the printer".
- Pg. 8 - General Printer section: line 4:
"In addition to the providing..", remove "the"
from the sentence.
- Pg. 9 - "explicitely"
is misspelled; should be "explicitly".
- Pg. 9 - "
Input Group which represents that media that
"
should be "
Input Group which represents the media that
".
- Pg. 10 - Remove the dash in "xero-graphic".
- Pg. 12 - Section 2.2.12: sentence "
current message
on the operators console
of the
" - "operators" should be "operator's".
- Pg. 16 - In hrPrinterStatus,
the numbers used for "idle", "printing", "warmup",
and "unknown" in the syntax section don't match the
numbers in the description
section.
- Pg. 18 - "This section provides and overview
"
change "and" to "an".
- Change references to "simple" alerts to "unary"
alerts throughout the document.
- Optional trailing edge alert implementation should be made
more visible in the document:
- Pg. 13 - Section 2.2.13: The sentences 'if and only if the
event is a critical even, initiating a trap' and 'Each reportable
event causes an entry to be made in the Alert Table' should be
rephrased to reflect the optional alert alert implementation.
- Pg. 19 - 1st paragraph: Rephrase this section.
- Pg. 19 - 2.2.13.4, 3rd paragraph: Rephrase this
section.
- Pg. 20 - Line 3: "It they were never
"
should be "If they were never
".
- Pg. 20 - Section 2.2.13.5
missing. It should include information from prtAlertGroupIndex
description, i.e. the MIB is indexed with hrDeviceIndex &
another index optionally which could be the value '-1' if not
present.
- Pg. 21 - Put quote marks around "external means"
in "here external means include using the operator
".
- Pg. 21 - Item #2:
The sentence "The printer will behave differently if the
installation of the resource is reported than the printer would
if the installation were not reported; that is, the object is
not to be used as a place to put information not used by the printer,
i.e., not a "PostIt"" should be reworded.
- Pg. 21 - "the printer believes that information
"
change "that" to "the".
- Pg. 22 - Section 2.4.1 enumeration(3): "controls; An"
change ";" to ".".
- General comments:
- Since General Group TCs, Channel Group TCs & Interpreter
Group TCs moved from other areas of the document, the changes
whit in these groups are not readily identifiable.
- PrtOutputTypeTC, PrtOutputStackingOrderTC, PrtOutputPageDeliveryOrientationTC,
PrtMarkerMarkTechTC, etc. appear to be under the Interpreter Group
heading, and they do not belong there.
- prtConsoleDisable: why this is not defined as a textual convention.
- Glossary of definitions for enumerations would be helpful;
ex. PrtMarkerCounterUnitTC.
- CapacityUnit:
There is no provision to describe the type of sheet; ex. Envelope,
17# paper, 20# paper, cardstock, ¼" plywood, etc.
- PrtMarkerCounterUnitTC
description: "
The time units of measure are provided
",
there is only one time unit of measure listed (hours).
- PrtSupplementaryPageContentTC
is never used elsewhere in the document.
- PrtAlertTrainingLevelTC:
noInterventionRequired(7) is not explained in the description
section.
- Add "enumeration type" comment to:
- PrtChannelTypeTC
comments:
- PrtMediaPathTypeTC:
is there a need to add "longEdgeBindingSimplex" and
"shortEdgeBindingSimplex"?
- PrtInterpreterLangFamilyTC
comments:
- PrtAlertTrainingLevelTC
comments:
- PrtAlertGroupTC
comments:
- Where does the conformance of printerV1Alert & printerV2Alert
fit? There is nothing that indicates whether these objects are
mandatory or not in the MIB.
Additions:
- Following definitions should be added to the glossary:
- spot color;
- process color;
- impressions;
- agent.
- Master list of the enumerations used throughout the document.
Editorial corrections:
- Update:
- Some of the sentences end with periods, and some don't.
- In the definition of Idempotent:
- Pg. 117 - "in a non-idempotent way, the this data
"
delete "the".
- Pg. 117 - '"press foot toggle switch" , is not
'
delete the comma.
- Pg. 118 - In the definition of "Object", "..
usage)." appears
at the end of the definition, and it doesn't seem to belong there.
- Pg. 118 - In the definition of "Printing" delete
the dash from "gen-eration".
- Pg. 116 - Collation description should
read "
placing the pages from separate copies into separate
ordered sets, ready for binding." By including "separate
output bins" the definition is unnecessarily restrictive.
- Pg. 121 - Delete the hyphen from "prtInputDeclared-MediaDimFeedDir".
- Pg. 125 - Printer job state should
read "
within a printer". It doesn't make any
sense as written.
Overall comments:
- General Printer Group should
have an explanation of which tables/groups it includes. The only
connection of the prtCoverTable, the prtLocalizationTable and
the system resources table is in the index and a comment within
each table (??).
Issues:
- prtGeneralConfigChanges:
- How easy is it to use this object? It indicates that a change
has took place, and does not go beyond that. How far the software
should check to find out which parameter values have been changed?
- prtGeneralCurrentLocalization:
- The description is not clear. Question on the phrase "that
are identified as being dependent on the value of this object.".
- prtGeneralReset:
- Is there a need for making this object "read-write"?
Editorial corrections:
- prtGeneralConfigChanges:
- Seems to be conflicting statements" Counts configuration
changes
, such as addition/deletion of input/output bins,
"
and "this counter would not be incremented when an input
tray is removed".
- prtGeneralReset:
- Pg. 44 - add a "'" to "the values 'notResetting'
and resetToNVRAM'.".
- Remove the reference to the "enumeration type" maintenance.
Issues:
- prtLocalizationCountry:
- The sentence "A blank string shall indicate that the
country is not defined" causes a question. The description
implies that the sequence of country code is fixed. If a printer
chooses not to localize to a specific language, than its sequence
should be "US, <SP><SP>, DE,
.". If
the above is TRUE, why doesn't the MIB spell out all the country
codes.
- prtLocalizationLanguage:
- ISO 639 only defines a two-character code for Chinese. How
would the "Traditional" and "Simplified" Chinese
would be implemented using the Printer MIB.
Editorial corrections:
- Remove the extra return from the Localization Table description.
- prtLocalizationLanguage:
- ISO 639 uses lower case letters, these examples
should, too.
Editorial corrections:
- Add a description to:
Editorial corrections:
- prtGeneralCurrentOperator &
prtGeneralServicePerson descriptions:
The description of phone numbers should be the same for both,
i.e. one mentions whitespace, while the other does not.
- prtGeneralServicePerson
description: "staring"
should be "starting".
Editorial corrections:
- Add an entry to the Table of Contents for Auxiliary Sheet
Group.
- prtGeneralStartupPage:
- Pg. 51 - "diable"
should be "disable".
Issues:
- The mechanism for declaring the media size and finding out
what size the tray was actually set to was difficult to implement
and is hard for software developers to use. In the printer we
have to convert from a paper size to these dimensions, and the
software has to convert from the dimensions back to a known paper
size. Problems also exist because it is a two-stage mechanism.
Since you have to set both the X & Y coordinates, it requires
two set operations. If the second set operation fails for any
reason, the tray media size is set to a really weird dimension.
- PrtInputEntry:
- Why doesn't the MIB include Min and Max media sizes for input
trays? (It is included for the output bins, but not for input
trays.)
- prtInputDefaultIndex:
- How does one know the correlation of Input Units to Physical
devices. In some current implementations there is no useful database
of what DefaultIndex's are in use. This information would be necessary
from a developers point of view, and there should be some verbiage
that ensures a development team would make available the legal
values.
- prtInputType:
- It would be nice to know how "names" are given to
the integer values assigned by the printer. How does the developer
know this information? How do the numbers change internally if
sub units are added. There doesn't seem to appear any structure
other than what the "default" is.
- prtInputMediaDimFeedDirDeclared:
- It would be nice to develop some sort of standard for the
values given by the input indexes. The values are not appropriately
documented by specific devices, some rigor (forcing an enumeration,
or other specific algorithm) would help enforce the readability
and workability of this section of the document.
- prtInputMediaDimXFeedDirDeclared:
- When discussing dimension, is that page dimension, or resolution
dimension. Is there some standardization as to how these objects
are used by host applications?
- prtInputMaxCapacity:
- It might be useful to point out, when the unit can reliably
sense this value, they might see the access type as read-only.
Editorial corrections:
- prtInputType:
- prtInputMediaDimFeedDirChosen:
- prtInputMediaDimXFeedDirChosen:
- "DimUnit"
should be prtInputDimUnit.
- prtInputMaxCapacity:
- prtInputCurrentLevel:
Issues:
- Do the following object are localized based on the prtGeneralLocalization:
- prtInputSerialNumber:
- How does the manufacturer set this initial value? This object
seems difficult to implement, and probably not necessary to fulfill
"Extended Input Group" compatibility.
- The range for prtOutputSerialNumber is
given as 0..63, but prtInputSerialNumber is
defined as having a range of 0..32. Seems strange that there should
be a difference between input and output devices.
- prtInputSecurity:
- What is the benefit of this object?
Editorial corrections:
- The Extended Input Group should
stand out and be separated from the previous group by many blank
lines.
Issues:
- prtInputMediaWeight
- A range should be specified, especially with negative values.
- Is a fixed unit of measure (gm/m2) for Media Weight
flexible enough for this object? Is it consistent with other objects
that provide a selection of choices on what unit of measure is
to be used (ex. MediaUnit, CapacityUnit)?
- What does a value of "-1" mean for this object?
- prtInputMediaType:
- The object "prtInputMediaColor"
indicates that the implementor is free to add additional string
values as long as they follow a certain naming convention. This
object makes no such mention. Does this imply that the implementor
may NOT add additional strings?
- Should this become a textual convention rather than an Octet
String.
- prtInputMediaColor:
- A range should be specified, especially with regard to negative
values.
- Should this become a textual convention rather than an Octet
String.
- prtInputMediaFormParts:
- The definition is confusing. What is trying to be achieved
is not understood, so the object is always set to "-2".
Editorial corrections:
- prtInputMediaType:
- "mailing purposes"
text should be tabbed/spaced over to line up with the rest of
the definitions.
Issues:
- prtInputManualFeedTimeout:
- The value of '-1' implies "this input sub-unit doesn't
support manual feed".. when in fact the unit might support
manual feed, but never want to time-out, which would be infinite.
It appears as though infinite and "doesn't support"
are two distinct different things, and should not be lumped together
as '-1'. A value of '-2' supports the notion that "doesn't
support manual feed" better than does '-1' (or infinite).
- prtInputManualFeedTimeout should not be limited to manual
feed operation. It could also be used for media sizes and types
that aren't currently loaded.
- prtInputNextIndex:
- A value should be provided that allows the printer to select
the next input source.
Editorial changes:
- The last word of the input switching group definition is "empty".
Since this group exists to handle this situation, the term "empty"
should be one of the first words in the paragraph.
- Add the Input Switching Group to the Table of Contents.
Editorial changes:
- PrtOutputEntry:
- prtOutputMaxCapacity:
- Pg. 64 - "CapacityUnit"
should be "prtOutputCapacityUnit" for clarity.
- prtOutputRemainingCapacity:
- Pg. 64 - "CapacityUnit"
should be "prtOutputCapacityUnit" for clarity.
Editorial changes:
- The Extended Output Group
should stand out and be separated from the previous group by many
blank lines.
Editorial changes:
- prtOutputMaxDimFeedDir:
- "DimUnit"
should be "prtOutputDimUnit" for clarity.
- prtOutputMaxDimXFeedDir:
- "DimUnit"
should be "prtOutputDimUnit" for clarity.
- prtOutputMinDimFeedDir:
- "DimUnit"
should be "prtOutputDimUnit" for clarity.
- prtOutputMinDimXFeedDir:
- "DimUnit"
should be "prtOutputDimUnit" for clarity.
Editorial changes:
- prtOutputStackingOrder:
- Pg. 68 - 'FirstToLast'
should be changed to 'firstToLast'.
- Pg. 68 - 'LasttoFirst'
should be changed to 'lastToFirst'.
- prtOutputPageDeliveryOrientation:
- Pg. 68 - 'Face-Up'
should be changed to 'faceUp'.
- Pg. 68 - 'Face-Down'
should be changed to 'faceDown'.
- prtOutputDecollating:
- Pg. 69 - In "
that the output supports supports
"
remove 2nd "supports".
- prtOutputPageCollated:
- Pg. 69 - Description should be continued with "Collation
is the process by which
".
- prtOutputOffsetStacking:
- Pg. 69 - Description should be continued with "Offset
stacking is the process by which
".
Issues:
- PrtMarkerCounterUnitTC:
- Some of the units that are given in the PrtMarkerCounterUnitTC
are quite ambiguous; ex. impressions.
Editorial corrections:
- prtMarkerDefaultIndex:
- PrtMarkerEntry:
- prtMarkerIndex:
- Change "
this marking SubUnitStatus"
to "
this marking sub-unit".
- prtMarkerLifeCount:
- "CounterUnit"
should be "prtMarkerCounterUnit" for clarity.
- prtMarkerPowerOnCount:
- prtMarkerProcessColorants:
- prtMarkerSpotColorants:
- prtMarkerAddressabilityUnit:
- Should the enumerations be converted into TC?
- prtMarkerAddressabilityFeedDir:
- prtMarkerAddressabilityXFeedDir:
- prtMarkerNorthMargin:
- prtMarkerSouthMargin:
- prtMarkerWestMargin:
- prtMarkerEastMargin:
Editorial corrections:
- PrtMarkerSuppliesEntry:
- prtMarkerSuppliesMaxCapacity:
- "SupplyUnit"
should be prtMarkerSuppliesSupplyUnit.
Issues:
- Most of the information in this group seems redundant. The
only new information is prtMarkerColorantTonality.
Editorial corrections:
- PrtMarkerColorantEntry:
- prtMarkerColorantValue:
- Should this object become a TC instead of an Octet String?
Issues:
- PrtMediaPathTypeTC:
- prtMediaPathDefaultIndex:
- If the range is specified from (1..65535), why not use "Integer"
instead of "Integer32". Also, the given range seems
large.
- prtMediaPathMaxSpeed:
- If a uses "impressions per hour" unit of measure,
there is no indication of the size of paper that will deliver
that performance. This number is meaningful only for a specific
(but unspecified) size of paper.
Editorial corrections:
- The Media Path Group
description does not indicate whether it is mandatory or optional.
- PrtMediaPathEntry:
- prtMediaPathIndex:
- prtMediaPathMaxSpeedPrintUnit:
- prtMediaPathMaxSpeed:
- prtMediaPathMaxMediaFeedDir:
- prtMediaPathMaxMediaXFeedDir:
- prtMediaPathMinMediaFeedDir:
- prtMediaPathMinMediaXFeedDir:
Using NSM Table:
- NSM MIB index object:
- Reasonable way to allow adding NSM MIB support without requiring
a lot of new object support.
- Comments on possibly only high-end printers using this MIB.
- Deprecating prtChannelType
& replacing it with assocApplicationProtocol:
- Don't see the advantage of replacing this object with the
assocApplicationProtocol. Mostly, only the high end printers will
implement the Network Services Monitoring MIB. From a JetAdmin
perspective it is much easier to deal with an enumerated type
as opposed to an OID.
Issues:
- Channel group description section:
- The definition of the Channel Table should be extended to
include the use of the NSM MIB.
- Should the "ChannelType"
references be a reference to "assocApplicationProtocol"
instead?
- prtChannelState:
- This could be more useful if it were expended to include more
than just enabled or disabled. The NSM MIB object applOperStatus
has some useful information that could be incorporated into this
object This object could be useful for describing states that
are not considered errors by underlying low level protocols, but
that affect printing. Ex: TCP connection to port 9100 when printer
is off-line. The TCP connection is valid, but data is blocked
until the printer is set on-line. The ability to determine states
like this would be helpful.
- prtChannelStatus:
- The status mechanism is too heavily tied to traps via the
alert mechanism. It would be nice if there were a way to determine
the alert associated with the channel status. Perhaps adding a
new object, prtChannelStatusIndex that returned the index of the
highest priority warning, or critical alert outstanding for the
sub-unit would be a way to help applications that don't support
traps.
- prtChannelCurrentJobCntlLangIndex
& prtChannelDefaultPageDescLangIndex:
- Is there a current language index for the "chFax"
channel? Does the current language mean the final destination,
since channel's data could be going to some kind of filter which
translates it to PCL without the channel having knowledge of it.
Editorial corrections:
- The "Channel Group"
is now called "Print Job Delivery Channel Group". References
to the Channel Group through out the document should be corrected.
- Channel group description section:
- PrtChannelEntry:
- prtChannelType:
- Description for "chAppSocket"
is unclear. The sentence "using TCP Port 9100 for control
and using TCP Port 9101 for control and TCP Port 9100 for data"
needs to be rewritten.
- Description for "chIrDA"
refers to SIR when IrDA could also be FIR or Fast Infrared.
Editorial corrections:
- Interpreter Group object definitions should be changed to
reflect the support for MFPA device communications and discovery
functions.
- PrtInterpreterEntry:
- prtInterpreterLangFamily:
- Pg. 95 - Remove the sentence "This type 2 list of enumerations
requires review before additional entries are made."
- prtInterpreterFeedAddressability:
- Pg. 96 - In "10000 prtMarkerAddressabilityUnit s (see
"
remove the " s".
- prtInterpreterXFeedAddressability:
- Pg. 97 - In "10000 prtMarkerAddressabilityUnit s (see
"
remove the " s".
Issues:
- prtConsoleNumberOfDisplayChars:
Editorial changes:
- Should prtConsoleDisable
enumerations be a TC?
Editorial corrections:
- prtConsoleDisplayBufferText:
Issues:
- prtConsoleOnTime &
prtConsoleOffTime:
- These objects do not fully cover the cases of "always
on" and "always off". If both prtConsoleOnTime
and prtConsoleOffTime are 0, then it is always off. However, if
prtConsoleOnTime is 0, prtConsoleOffTime can be anything. If prtConsoleOffTime
is 0, prtConsoleOnTime can be anything except 0. It would be less
confusing to explicitly state that when one of them is 0, the
value of the other is ignored (except of the 0 - 0 case).
Editorial corrections:
- PrtConsoleLightEntry:
NMS & alerts/traps:
- NMS & use of alert table:
- There should be a section summarizing how network management
stations should be using the alert table to receive messages.
- The trap is sent only when there is a critical error occurs
in the printer. NMS would need to poll the printer to determine
the problem before it becomes a critical error (such as paper
low). Polling the table for large number of printers would be
very ugly, and unwise.
- Big concerns on implementing the alert table for a management
station. Problems with keeping track a copy of the alert table
in the NMS, and constantly polling the stations, parsing the alert
table to see if there are new entries added, etc.
- Prefer to have traps sent on everything, possible ways:
- modify table to poll for only couple of objects to determine
the error state, etc.
- information on what NMS should do to use the alert table.
Issues:
- prtAlertLocation:
- printerV2Alert
& printerAlert:
- How about including the prtAlertTime in the trap?
Editorial corrections:
- PrtAlertEntry:
- prtAlertIndex:
- Should the optional alert alert code implementation be included
here? See the end of the description on pg. 104 relating to discovering
binary alerts that are deleted.
- prtAlertGroupIndex:
- "Group"
should be "prtAlertGroup".
- "GroupIndex"
should be "prtAlertGroupIndex".
Last updated: in June
4, 1996
binnur@boi.hp.com