IPP> Re: JMP> Re: MOD - Comments from Patrick Powell

IPP> Re: JMP> Re: MOD - Comments from Patrick Powell

IPP> Re: JMP> Re: MOD - Comments from Patrick Powell

Patrick Powell papowell at dickory.sdsu.edu
Fri Mar 7 20:18:40 EST 1997

# >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 [], pleased to meet you
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.

More information about the Ipp mailing list