# >Tom or somebody else from the MIB project,
# >could you answer some of these questions?
# Pat, given some other starting point, you are probably right, SNMP
# is not the ideal approach...
# >I have looked at some of the stuff, and have a sinking feeling that
# >the folks who are doing the MIB stuff have never tried to build/monitor
# >a printing system with jobs flowing through/around it, make it portable,
# >small, and able to be implemented by the lowest bidder :-)
# As an aside, it appears HP has done this...
Ummm... yes, but did they do it RIGHT? *
*Sorry HP folks, couldn't resist that one...
# >I always try to do the simplest thing, on the grounds that the more
# >complex you make it the more things you forget.
# But, we're not starting at the beginning. It has taken several years
# for printer vendors to respond to market demand for SNMP in their
# network products - in a standard way. The complex SNMP overhead you
# refer to is already there in many cases as a result. Given *this*
# starting point... what seems undesirable is the need to invent and
# accommodate *yet* another protocol, perhaps unless it is one that
# looms so large that it can't be ignored - such as HTTP.
OK, this makes sense.
Horrible, ugly, nasty sense, but sense... Sigh...
# >Why not just define some simple MIB objects that haul text strings
# >over and parse the text strings? The overhead of implementing a
# >SNMP MIB with all of the complexity that they are putting in will be
# >a horrific nightmare. The management of the system will be hideous,
# >the database alone will be nasty to design and build, and most of the
# >information will be of little use.
# If we're designing a MIB that contains mostly useless information...
# that's a *separate* problem!
Ummm... perhaps that is the problem I am trying to express.
# >I also note that many of the folks on the MIB team seem to feel an
# >need to have enumerated status types/messages. I keep wondering why -
# >most of the time the detailed information about a state is being
# >supplied in an additional message. Why not just send a text string
# >with the state as the first token? It is trivial to parse this.
# >And besides, for display purposes you will need to translate/index
# >into a table of strings.
# I agree with Don's assessment, here. You could parse fixed string definitions
# and land on your feet at the same time for one of 49 languages. Where's
# the benefit? If you're going to parse the string then it must be
# specifically listed somewhere otherwise you are wide open to interpretation
# (ex. PCL5, PCL-5, PCL5e, PCL FIVE...). A list implies a number. A
# number is shorter than most strings. Why not use it?
Because there are alternatives to this that have worked in other places.
The FTP/SMTP (Simple Mail Transfer Protcol) come to mind. In this protocol,
we send a command, and get a response:
220 sdsu.edu ESMTP Sendmail SDSU ready for action at Fri, 7 Mar 1997 17:16:11 -0800 (PST)
>>> EHLO dickory.sdsu.edu
250-sdsu.edu Hello dickory.sdsu.edu [130.191.163.56], pleased to meet you
250-EXPN
250-VERB
250-8BITMIME
250-SIZE
250-DSN
250-ONEX
250-ETRN
250-XUSR
250 HELP
>>> MAIL From:<papowell at dickory.sdsu.edu> SIZE=37
250 <papowell at dickory.sdsu.edu>... Sender ok
>>> RCPT To:<papowell at sdsu.edu>
250 <papowell at sdsu.edu>... Recipient ok
>>> DATA
354 Enter mail, end with "." on a line by itself
>>> .
When you have multiple status lines you can use the continuation facility -
220-this line
220-that line
220 last line
See 250 stuff above.
Note: I once thought about using SMTP/MIME as a print protocol. I think I have
a working document around somewhere...
# Harry Lewis - IBM Printing Systems.