>>> > ----------
There have been few comments on the prtChannelMagicCookie object,
> which either means everyone is happy with it or no one has given it
> too much thought. ...
>> Bill Wagner, DPI
>
I asked Jeff Dunham who works on our JetDirect cards (and has been to a few
PWG meetings) for his comments on the prtChannelMagicCookie object.
Attached is his reply. If you have comments just reply to the mail
reflector, Jeff monitors our discussions.
Bob Pentecost
HP
Just a general comment: The architecture of this channel
type/cookie/whatever
object(s) needs a lot of work. It should be entirely reworked into a
table that captures the many-to-one or many-to-many relationships
correctly.
>prtChannelMagicCookie OBJECT-TYPE
This is a nitty comment, but "MagicCookie" is goofy. I know its a "Unix
thing", but the MIB should be a professional document, not one that
talks about "Magic Cookies".
> 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 }
If I understand this, it is a further qualifier associated with each
Printer
Channel Type? Of course, you have to have a many-to-one relationship
between type and "cookie" to correctly capture the information.
>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
This existing list is nonsense. It is trying to capture items from
different
levels in a protocol stack. For example, chIRDA is a low-level backplane
item, and chFTP is a high-level application layer. They don't belong in
the same list.
If you want an example of how this might be done, check out MS NT 3.51 or
greater. The way they handling network stack bindings captures the the
hierarchy that needs to be captured here.
You essentially need to define a hierarchy that describes the protocol-path
of the data from the frontplane to the backplane (and for that matter, all
the way to the formatter: PS vs. PCL, etc).
> 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.
If a valid architecture was defined, this wouldn't be such an ugly problem.
Once a sensical hierarchical design was formed, a list of PWG-approved
enums could be created. Also, a domain of implementor-defined enums could
be set aside, much like the use of TCP/IP port numbers in Unix. This would
have to be done at each layer (physical, link, ...).
> 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.
If, after coming up with a sane design, unusual/dynamic information still
couldn't be modeled, there might be cause for an "open-season" type of
object as a catch-all for this type of information.
> 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.
The known methods should be covered now, as part of a sane design. Then,
new, unknown elements should be able to be added to an extensible design.
> 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.
I don't know anything about the Network Services MIB. If it simply models
the hierarchical connection of frontplane to backplane, then ok.
>> 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
Danger! Need to keep it simple!
> 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
I'd call it a short-term, simple-minded, poorly-architected approach.
> 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.
--
Jeff Dunham