prtChannelMagicCookie object

prtChannelMagicCookie object

David_Kellerman at nls.com David_Kellerman at nls.com
Wed Sep 4 18:17:37 EDT 1996


Hello again.  Sorry for the abrupt disappearance -- I had a family
emergency last week that completely took me out of commission, and
kept me away from San Diego and my e-mail. 




After reading the mail concerning the prtChannelMagicCookie object,
I figure it's worth a try to get this back on track. 


A couple of observations first of all: 


 1. It seems as though, in trying to rectify some of the problems
    with the channel group, we find it much easier to get stuck than
    to make any progress.  I don't know if this is because it
    offends people's sense of aesthetics (it does mine), because
    people are burned out, or what.  But if we can't get some focus
    and nail this down pretty quickly, we ought to go back to Jay's
    suggestion from July, which I think was: leave it as is, and be
    done with it. 


 2. I may be thin-skinned, but Jeff Dunham's comments irritated me. 
    I'm hoping they weren't intended for public consumption, and
    that explains the tone. But they strike me as off-the-cuff and
    based on preconceptions -- he seems to have a different
    objective than what was intended for the prtChannelMagicCookie,
    and fails to admit the implication of his proposed alternatives.  


    If this is the result of my own obtuseness in trying to provide
    a rationale for the object, I apologize.  But in light of my
    comment (1) above, I think the tenor of the note is unfortunate. 




In retrospect, I should never have put "MagicCookie" down in print. 
As noted in the message that presented the object, I expected
someone more familiar with MIB naming conventions to come up with a
serious alternative.  I've looked at the DPA spec (I figured it was
voluminous enough to contain any keyword that might be appropriate
;-)), and here are some alternatives: 


    prtChannelContext
    prtChannelBootstrap
    prtChannelProfile
    prtChannelCharacteristics
    prtChannelInformation
    prtChannelSpecification


These are ranked according to my personal preference.  Are there
other suggestions, votes? 




I think these are key issues with respect to the
prtChannelMagicCookie object: 


 1. The information is primarily intended to provide a "bootstrap"
    for an application attempting to use the channel.  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." 
    Once it gets its bearings in the channel "domain," the
    application may collect additional information, and may perform
    additional setup based on its knowledge of the channel type. 


    It's NOT supposed to fully characterize the channel.  It's NOT
    supposed to duplicate information that a knowledgeable
    application knows already or can determine within the channel
    "domain." 


    Look, we've got a couple of companies represented on the PWG
    producing printing applications software (Northlake and
    Underscore).  The Printer MIB offers a promising way of allowing
    software to auto-configure itself for a particular printer. 
    (What is the printer model, what hardware options are present,
    how are the channels configured for submitting jobs, etc.) 
    Status quo, the software steps through the MIB information, and
    eventually, depending on which channels are present, has to have
    the user provide a few obscure bits of information about the
    channel before they're done.  This may seem trivial, but it
    really dimishes the value the auto-configuration when some of
    the most obscure settings have to be provided manually. 


 2. I don't see how you can "architect" a solution to this problem
    without ending up with a solution that is disproportionately
    large.  You just don't have any consistency to work with. 


    Look, suppose you've got a subway system, a skateboard, a Model
    T and a Volvo, and a cargo ship.  They're all transportation,
    but they have about as much in common as the different channel
    types used for printing.  If you know how to drive a car, what
    you need is the keys to the ignition, not a taxonomy of
    transportation systems, not a scheme that is organized to
    reflect the commonalities between skateboards and cargo ships. 


 3. It isn't necessary to try to characterize all the different
    channel types.  With some of them, the additional information is
    simply never going to be used.  Some are not good candidates for
    an SNMP "bootstrap," some are not rigorously defined or are
    defined privately, and so forth. 


    It's fair to pick and choose, based on our best judgement, and
    not get sidetracked by a misplaced desire for completeness. 




Here are a couple suggestions on positions that I would not
personally choose, but would at least move us toward resolution: 


 1. Someone presents a compact, nicely architected solution, that
    gets us past the discomfort that is apparently widely felt with
    the current structure. 


 2. We decide that the prtChannelMagicCookie solution is too ugly to
    enshrine in a standard MIB, say the problem is intractable (due
    either to lack of insight or motivation), and leave it unsolved. 


I'd like to get away from just kicking this around.  I thought there
was enough consensus from the July meeting to put together a
solution along the lines I proposed.  If this is not the case, I'd
like to back out gracefully. 


::  David Kellerman         Northlake Software      503-228-3383
::  kellerman at nls.com       Portland, Oregon        fax 503-228-5662



More information about the Pwg mailing list