Participants:
Ron Bergman, Dataproducts
Jeffrey Copeland, QMS
Tom Hastings, Xerox
Scott Isaacson, Novell
David Kellerman, Northlake
Harry Lewis, IBM
Jay Martin, Underscore
Bob Pentecost, HP
Bill Wagner, Digital Products
Lloyd Young, Lexmark
prtChannelInformation object:
-----------------------------
1. If DisplayString is the object syntax how can Unicode strings
be represented?
Tom Hastings recommended mapping Unicode to NVT-ASCII. The ISO
Unicode Standard (ISO 10646) UTF-8 appendix defines the preferred
method to accomplish this mapping. If any other data types are
desired to be used, they would also be required to perform an
equivalent conversion. It is essential that the object contain
only NVT-ASCII characters.
2. Why is DisplayString used here and not anywhere else in the printer
MIB?
After much discussion it was concluded that the decision to use
Octet String rather DisplayString was made by Steve Waldbusser.
The decision was likely due to the requirement that most of the
strings in the printer MIB require localization.
3. How should the prtChannelInformation entry be defined?
It was agreed that the elements of the entry would be designated
Keyword and Value. (i.e. The entry format is Keyword=Value.) No
spaces are allowed between the Keyword, the equal sign and the
Value.
Keywords are to be case sensitive and the first character must be
capitalized. If more than one word is required for the Keyword,
the first character of each word should be capitalized. No spaces
are allowed in the Keyword.
The value may contain any NVT-ASCII character from hex 20 to 7E.
The Linefeed character is reserved to delimit entries. Tom
Hastings recommended the inclusion of the hex value for Linefeed
in the description to avoid confusion.
4. Should an SNMP set be allowed for prtChannelInformation entries?
It was unanimously agreed that the MAX-ACCESS and MIN-ACCESS should
be read only. These objects should be defined independently of
SNMP.
5. Does the order of the entry listings imply they must be returned
in the same order?
If the entries must be in a specific order for proper
interpretation by a management station, this must be specified in
the description. Otherwise, they may returned in any order.
6. Are multiple same-type Keyword entries allowed for a given channel?
(e.g. If the TCP channel supports ports 9100, 9200 and 9300, can
all three values be returned for the same channel index value?)
In most cases, separate channel table entries will be required.
The purpose of this new object is to provide information to a
management station that is not currently available. Separate
channel table entries would be normally expected by a management
station. When in doubt, is it best to error in the direction of
separate channels.
7. Why the requirement for human-readable entries?
This is primarily for a common format for the entries. Otherwise,
escape sequences of complex data type definitions will be required.
Human-readable strings also allow for easier entry and can be
easily parsed.
8. Should Plug and Play information be included as an entry in the
prtChannelInformation object?
There are two Plug and Play information formats.
- Serial and Infrared (ISA), is a seven character field. The
first three characters are assigned by ISA to a vendor and the
remaining are assigned by the vendor.
- 1284 id format. (No one could remember this format.)
Plug and Play information can be easily obtained by the client
platform. The purpose of the prtChannelInformation object is not
to determine the channel characteristics, but to provide information
that is not readily available on the network that is necessary to
allow printing through the channel. If the parameters are readily
available using the common printing protocols normally used with
the channel, this object is not required.
Volunteers for the remaining channel types:
-------------------------------------------
Scott Isaacson volunteered for RPrinter, PServer, SPX, and NDPS.
(NDPS is a new request submitted by Scott.)
Ron Bergman volunteered for AppleTalk PAP and Server Message Block.
Anyone else care to join this elite group?
Comments on the Update Printer MIB Charter:
-------------------------------------------
Only comment was the question; Is the schedule too aggressive?
Other new business:
-------------------
1. Do non-network interfaces and channels need to be identified and
described in the MIB?
This presents an interesting dilemma in light of the current work
on job monitoring. If the Job MIB provides accounting data for
non-network channels then there should be related data in the
Printer MIB.
The PWG needs to define the level of support required for conforming
implementations relative to non-network interfaces and channels.
Bill Wagner agreed to post an email on this subject.
2. Does the Printer MIB require implementation of hrDeviceId for
conformance? Exactly what is mandatory to be included from the
Host Resources MIB?
The group generally agreed that the Printer MIB is not clear as
to this answer. A volunteer is needed to rewrite this text.
Bill Wagner agreed to publish an email to initiate this effort.
3. Jay Martin commented that implementations of the Alert Table
appeared very different between vendors. As an example, when a
paper tray was removed from the printer, vendor A reported "Input
Tray Missing" while vendor B reported "Input Media Type Change",
"Input Media Weight Change", etc. This is a serious problem for a
management application. How can this issue be resolved?
The Alert Table is presently defined as a "Shopping List" which
encourage differences in implementations.
4. It was unanimously agreed to deprecate chPort9100
5. Updated Printer MIB should be available prior to the New Orleans
meeting for review. Several persons expressed interest in having
this document ASAP.
Randy Turner will most likely not be able to continue as the MIB
editor after the first of the year. A volunteer is needed to fill
this position. This must be resolved in New Orleans!
-----------------------------------------------------------------------
Ron Bergman
Dataproducts Corp.