Greetings,
First, since some protest prtChannelMagicCookie as even an interim
tag, let me put in my vote for prtChannelInformation as being
sufficiently bland.
prtChannelContext... gets confused with Novell NDS Context
prtChannelBootstrap ... no, it isn't a bootstrap
prtChannelProfile ... too grandiose
prtChannelCharacteristics .. suggests more than a key
prtChannelSpecification...much too grandiose
David Kellerman has outlined the intent of the prtChannelInformation
object as it was proposed.
"It's supposed
to provide just enough information for a knowledgeable
application (one that knows how to use a particular channel
type) to get from the MIB "domain" to the channel "domain."
(although "domain" may too loaded a term).
In this context, I agree that some of the email seemed to reflect an
excess that goes far beyond the intent of this simple object. This
appears to be a tendency with MIB's. As Ira M has indicated, there are
substantial MIB's that deal with PPP, and Serial, and Parallel and
other interface/channels which appear to have escaped their
appropriate layer. And there are other MIB's that deal with channels
which are more applications than interfaces. Indeed, one could easily
throw multiple MIB's at this subject.
But the intent was to provide a key so that, having somehow discovered
a printer by access to its MIB, an application could figure out how to
print to it. I suggest that we must first agree that this is a
reasonable objective.
A printer can and typically will have interfaces other than network
interfaces, and therefore will have channels using those interfaces.
Indeed, I think it is clear that the Printer MIB requires that
parallel and serial interfaces (for example), in their primitive,
non-layered, non-packetized, non-networked form are to be identified
via the MIB-II interfaces table (which, even if were possible using
rfc1213, still makes little sense to me). It follows that the
'channels' by which these interfaces connect to interperters be also
identified. This is what confuses the Channel concept because it puts
primitive connections, well known to printer people but unappreciated
by network types, on the same level as network print service
applications.
Of what use is this information in a network-oriented MIB? It does
help to identify the printer hardware configuration, and could help
to identify a printer problem due to a non-network interface. It would
be useful for a printer connected to the network via a local host. But
will it be used in these ways?
If we were to ignore (or handle in some other way) non-network
interfaces (as I understand some implementors have), then I think
channels might clear up some and the purpose of the
prtChannelInformation object would be more clear.
Yes Harry, I know you have suggested this periodically. But I think we
must first have consensus on what interfaces are reported (only
network interfaces,as rfc 1213 suggests?) and what interface-channel
relations are reported.
I suggest that, if the only use the group can agree to is port number
for one of the several TCP/IP channels, the idea is best dropped.
Bill Wagner, DPI