Randy's proposal for the prtChannelInformation object (aka MagicCookie)
makes some interesting suggestions in the direction of making the data
human readable, but I'm concerned that it tries to go too far in that
direction. I'd like to suggest an alternative that addresses the issue
of human-readability in a more limited way.
Briefly, I can see several areas of concern with the "scanf" approach
suggested by Randy: localization issues; problems with extracting
the data values from the surrounding text (quoting problems); encoding
of optional values is still open.
object is to benefit software that is using the MIB to determine how to
interact with the printer (for job submission, in particular), and in
this context it serves to "bootstrap" to connection. I won't try to
repeat the long justification in my earlier note on this subject, but I
still believe this is true.
I also believe we should focus on keeping this thing small, not
speculative -- define prtChannelInformation requirements for channel
types where it clearly has a practical use, and require data values that
clearly are needed for well-defined reasons. You ought to be able to
say, "we need item X for channel type Y because it is needed for
application Z that really is going to be implemented." I believe there
are only a small set of candidates that can currently be justified this
way -- add others later if necessary.
In my original prtMagicCookie proposal, the idea was that the
information string be "human-readable" in a fairly simple way. It was
clear that the data placed in the string would be a grab-bag of things,
and it was necessary to reduce it all to some common format -- hence the
idea of using the conventional human-readable representation of the
data. I hadn't meant to suggest that someone be able to read off the
value without benefit of a specification -- I would say this is both
unnecessary and too ambitious.
All that said, here is an alternate suggestion for encoding the
prtChannelInformation:
1. 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.)
2. If the prtChannelInformation consists of multiple values, they are
listed in a specified order, separated by linefeed characters.
3. If the prtChannelInformation includes optional values, they are
listed following the required values, each preceded by an
identifying tag consisting of alphabetic characters and a space.
4. The encoding defined for a particular channel type may also specify
a way to indicate that part or all of the value is 'unknown'.
5. The symbolic representation (if any) of values, the specified order
of multiple values, the tags used to identify optional items, and
the representation of unknown items (where allowed) shall all be
specified in the descriptive text associated with the PrtChannelType
enumeration value for which the prtChannelInformation is required.
I think this approach is one that will allow a software application to
simply and unambiguously decode the prtChannelInformation. It isn't as
"human-readable." But I haven't seen the justification for more
human-readability (in either meeting minutes or e-mail), and I can't
convince myself that more is needed.
These are cases I can readily justify defining prtChannelInformation
values:
chLPDServer -- printer queue name
chPort9100 -- TCP port number, represented as decimal value
chPortTCP -- TCP port number, represented as decimal value
chBidirPortTCP -- TCP port number, represented as decimal value
Note: The chPort9100 entry ought to be redundant, but are there any
existing interfaces that implement a Printer MIB that claims a
chPort9100 channel that is implemented on a channel other than
9100? (HP's JetDirect server uses a different port for each
attached printer, for instance, but doesn't implement a Printer
MIB, as far as I know.)
This is also possible; I just don't know if it would ever get used:
chDECLAT -- two optional values, one of which must be present:
-- port name (tag P)
-- service name (tag S)
This may not be an exhaustive list -- these are just the only instances
I can justify.
That's my two-bits worth. What do you think?
:: David Kellerman Northlake Software 503-228-3383
::david_kellerman at nls.com Portland, Oregon fax 503-228-5662