As is often the case with agreements at the PWG
meetings, each individual has a different notion about what was agreed
to. My understanding was that, as suggested by the whimsical name,
this object was to serve several purposes; but primary was the notion
of providing information that could allow an administrator (or
program) to establish a printing connection to the printer on the
combined information on the interface and channels groups; and,
considering the Job Monitoring MIB, to be able to correlate a specific
job to a specific channel. I missed the objectives of human readable
(an unfortunate term, meaning different things to different people)
and distinguishing different channels of the same type (except to the
extent of identifying an interface/channel path.)
With regard to specific points. I suggest that:
1. The object be mandatory (although the definition of specific fields
to be included for each channel may allow a way to specify 'unknown').
2. If there is no applicable information for a particular type, the
response be a null (0 length). This is consistent with the RFC 1573.
3. The objective of defining a path could not only be alternately
addressed by the Network Services Monitoring MIB, but also by the
extensions to the interface group (rfc1573) (which allows a
multi-layer definition of an 'interface' supported by a 'stack'
table,) particularly in conjunction with cited media-specific
mibs. Indeed, I think questions like 'what TCP port is being used ?'
would be answered by this combination. Also, things like serial port
setup and (heaven forbid) parallel port setup, including all
parameters considered necessary to make a connection, could be
defined. However, it is a mite cumbersome. And if we
desire to make life easier by including the TCP port number in this
new object, why not suggest including other critical parameters for
other channels. For example, why not provide
a. baudrate, data bits, stop bits, parity, and flow control
information for RS-232 interfaces?
b. The standard IEEE1284-1994 product identification string would
be useful for 1284-ports (useful if one is doing a parallel port
redirector to the network, and information perhaps not otherwise
accessible though the network)
c. SCSI type and port number
d. printer name; zone name (perhaps net, node and socket number)
for AppleTalk
e. more stuff for LPD... Queue name
f. for Pserver... pserver name as well as queue.. and if you have
queue, you need fileserver or context, and should have identification
if it is NDS or bindery based
etc.
That is, I suggest we solicit an identification of the type of
information appropriate for each type of channel that would be
desirable.
Bill Wagner, DPI