Minutes of Printer MIB Teleconference, October 30, 1996

Minutes of Printer MIB Teleconference, October 30, 1996

Minutes of Printer MIB Teleconference, October 30, 1996

rbergma at dpc.com rbergma at dpc.com
Fri Nov 1 12:54:01 EST 1996


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.



More information about the Pwg mailing list