draft of new prtChannelMagicCookie MIB object

draft of new prtChannelMagicCookie MIB object

draft of new prtChannelMagicCookie MIB object

David Kellerman davek at nls.com
Sun Aug 4 22:26:24 EDT 1996


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. 



More information about the Pwg mailing list