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