Here is a draft description of the new channel group object discussed at
the July PWG meeting. Thanks to Bill Wagner and Jay Martin for
providing very helpful comments on an initial draft.
There are three parts that follow: (1) the object definition itself, (2)
suggested encodings for the different channel types, (3) my comments
(information, justficiation, questions) on the new object.
Have at it!
:: David Kellerman Northlake Software 503-228-3383
::kellerman at nls.com Portland, Oregon fax 503-228-5662
prtChannelMagicCookie OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..127))
MAX-ACCESS read-write
MIN-ACCESS read-only
STATUS current
DESCRIPTION
"Auxiliary information to allow a printing application to use
the channel for data submission to the printer. An application
capable of using a specific prtChannelType should be able to use
the combined information from the prtChannelMagicCookie and
other channel and interface group objects to 'bootstrap' its use
of the channel.
The encoding and interpretation of the prtChannelMagicCookie
object is specific to channel type. The description of each
PrtChannelType enum value for which prtChannelMagicCookie is
defined specifies the appropriate encoding and interpretation,
including interaction with other objects. For channel types
that do not specify a prtChannelMagicCookie value, its value
shall be null (0 length).
The prtChannelMagicCookie value may contain information that is
not normally coded in human-readable form. In these cases,
whatever symbolic representation is conventionally used for the
information is used for encoding the prtChannelMagicCookie.
(For instance, a binary port value might be encoded as a decimal
number.) The encoding defined for a particular channel type may
also specify a way to indicate that part or all of the value is
'unknown'.
When a new PrtChannelType enumeration value is registered, its
accompanying description must specify the encoding and
interpretation of the prtChannelMagicCookie value for the
channel type.
"
::= { prtChannelEntry 9 }
PrtChannelMagicCookie encodings for current PrtChannelType values:
other
chSerialPort
chParallelPort
chIEEE1284Port product identification string
chSCSIPort SCSI type and port number
chAppletalkPAP printer name, zone name
(net, node and socket number?)
chLPDServer printer queue name (anything else?)
chNetwareRPrinter [chNetwareNPrinter]
Pserver name, printer number
chNetwarePServer queue name
(pserver name, fileserver or context, NDS or
bindery based?)
chPort9100 port number
chAppSocket port number
chFTP user name?
chTFTP
chDLCLLCport
chIBM3270
chIBM5250
chFax
chIEEE1394
chTransport1 port number
chCPAP
chDCERemoteProcCall
chONCRemoteProcCall
chOLE
chNamedPipe
chPCPRINT
chServerMessageBlock
chPSM
chDLLAPI
chVxDAPI
chSystemObjectManager
chDECLAT port name (P port-name) or service name (S service-name)
chNPAP
chUSB
chIRDA
chPrintXChange
chPortTCP port number
chBidirPortTCP
chUNPP
Comments:
1. In considering this object, please keep in mind that it is intended
as a pragmatic solution to an ugly problem -- nailing down the
linkage between the Printer MIB and the essentially unconstrained
collection of channels/protocols/whatever that might be used to send
data to the printer.
Hence the choice of an OCTET STRING, which can serve as a receptacle
for whatever information is needed for a particular channel type.
Hence the relegation of semantic descriptions to the text
accompanying the PrtChannelType enum values. It lacks formalism,
it's not pretty, but it seems appropriate.
I'd also suggest that this object isn't the solution for all channel
configuration problems. If we find ourselves trying to squeeze in a
dozen pieces of information for a particular channel type, maybe
it's not a good candidate for this approach. Likewise, if we
discover a dozen variants are needed to cover all the cases.
2. As an alternative to this approach, it has been suggested (Randy
Turner, July 1996 PWG meeting) that the channel table reference the
Network Services Monitoring MIB. This is a MIB intended to contain
"the elements common to the monitoring of any network service
application," and the channel table could be interpreted as
describing the network services provided by the printer. It was
hoped that by using NSM MIB, we would avoid duplication of MIB
objects, take advantage of IANA registry of network service types,
and be able to take advantage of further development of the NSM MIB.
However, using the NSM MIB runs into several problems. Its
standardization status is uncertain. Most of the objects in the NSM
MIB appear to be overkill or irrelevant to the channel table. The
channel table includes non-network services, which are not addressed
by the NSM MIB (as a result, things like prtChannelType don't map as
cleanly as one might like). It looks like you'd have to supplement
the NSM MIB by defining conventions for how it is used with the
channel table in order to ensure that the needed information is
present and can be interpreted consistently (for instance, the NSM
MIB itself doesn't specify that an LPD service provide the target
printer name for the service).
On the balance, I'd say prtChannelMagicCookie is a pragmatic
approach to supplementing the channel information that is suited to
the admittedly grab-bag character of the channel group, and the
channel group isn't orderly enough to benefit from using the NSM
MIB.
3. The interface group may be a more appropriate source of information
for some channel types than prtChannelMagicCookie. (Serial and
parallel ports come to mind.)
4. The name prtChannelMagicCookie is certainly provisional. If someone
has a more "serious" name that is consistent with existing
conventions, please speak up.
5. Who can help with encoding specifics? I've outlined it in cases
where I know something about the channel type, but it's still pretty
sketchy. I'm hoping that people who are "authorities" on various
channel types will step in and provide appropriate details.
Also, can anyone suggest appropriate encoding for cases where the
object encodes multiple values? (Are there other objects that deal
with this issue?) I'd like to see some consistency in coding, but
don't want to complicate simple values (if all you need to specify
is a printer name, you shouldn't have to quote, escape, tag, etc.).
Putting multiple values on separate lines, required values first,
and prefixing optional values with "keyword=" seems like a good
possibility.
6. All channel group objects are currently mandatory, so I assume
prtChannelMagicCookie would be also.