I agree with Dave that we must understand what the objective of
prtMagicCookie is, and define it to meet that objective.
I agree that the original objective was to allow a management app "to
determine how to interact with the printer (for job submission, in
particular)", although only job submission via TCP/IP was initially
considered; indeed, the addition of chPortTCP and chBidirPortTCP
channels are what prompted the object in the first place.
Further, the discussion in New York suggested that this objective was
not easily satisfied for channels other than chPortTCP and
chBidirPortTCP. The difficulty was sufficient to consider whether this
objective was an appropriate one for the MIB. It is unclear that
providing sufficient information about a channel for a management app
to set up a job submission path was ever an intent of the MIB.
Aside from Dave's comment about human readability in his proposal, I do
not know where it came from, or what the intent was. If the objective is
allowing a management app to set up a job submission path, I see no reason
why human readability is necessary or even desirable. If there are other
objectives requiring human readability, they should be explicitly stated
and agreed to before we worry about how to implement human readability.
So, I suggest we review the objective of including this object. If it
is to be implemented for only two channel types, we must
consider if it is warranted. If it is an important capability and one
critical to the applicability of the MIB, then we should consider if we
can put in the effort to define the object fields for all channel types, or
merely identify how one could define these fields (probably useless).
I have not seen a printer with SNMP that did not also have a private MIB,
and the private MIB usually contains the sort of information necessary to
satisfy the initial objective. So it can be done, but probably not
reasonably with one object. Perhaps this is better handled elsewhere?
Bill Wagner, DPI