prtChannelMagicCookie object

prtChannelMagicCookie object

prtChannelMagicCookie object

Bill Wagner bwagner at digprod.com
Wed Sep 4 19:26:05 EDT 1996


     


     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



More information about the Pwg mailing list