> I suggest that, if the only use the group can agree to is port number
> for one of the several TCP/IP channels, the idea is best dropped.
Let's not forget the need for a target "printer" (queue) name for LPD
applications. This one pervasive problem is (IMHO) worth the singular
MIB object alone.
How many printer vendors out there have documentation for their network
printers in which there is a table documenting the valid LPD queue names
used to specify certain kinds of print services?
Picking up the closest manual sitting on my desk, a well known vendor
cites these references for valid LPD queue names:
TEXT
PASS
(Now, funny thing is, I can't find where in the documentation those queue
names are defined... ;-)
It's reasonable to guess that the TEXT queue probably handles those
nasty ol' CRLF issues (such as auto-insertion of CR for LF-only systems,
etc), and as such, provides one type of simple print service.
Similarly, PASS probably provides a pass-thru (ie, raw) service where
the print data goes thru untouched. Usually good for Postscript, and
many kinds of binary data formats.
For this particular printer in question, I believe its network card
controls all aspects of LPD, or at least the external configuration for
LPD. This particular network card, incidentally, is essentially the
same (I believe) as that used on many other network printers, both from
the same vendor and several others.
I have seen similar approaches to LPD configuration (where the names
have been changed, but otherwise do the EXACT same thing) in not only
other network printers, but many external network printer interfaces.
So, this particular configuration scenario could be considered pretty
widespread, no? (Are there any users out there who might be able to
comment on this? Can Rudy Nedved and the others at CMU comment on this?)
All we are asking for in the prtWhoCaresWhatTheNameIs (;-) object is to
have the ability for the agent (in the card/printer) to provide these
simple configuration elements. When a system administrator runs some
software (provided by folks like Underscore and Northlake), that software
can simply go out to the printer targeted for use with a new, host-based
print queue and fetch the available options for selection by the user.
No need for a grand architecture. No need to make a stab at a Unifying
Approach to the Universe.
Just a simple string-like object...in the case of LPD, anyway.
Now, about that simple integer value denoting the TCP port number at
which to connect for a silly virtual stream print service...
...jay
PS: Alright, how about "prtChannelWart" ??? As good as any, eh? ;-)