SL> Surely you are not suggesting that an IPP client implementation must
SL> include SNMP as well as HTTP? If you thought you were getting
SL> resistance to layering IPP on HTTP...
>>>>> "JK" == JK Martin <jkm at underscore.com>:
JK> Are you suggesting that submitting a job using one protocol--but using
JK> a *completely* different protocol to monitor the status--is not a very
JK> good thing to do?
>>>>> "HL" == Harry Lewis <harryl at us.ibm.com>:
HL> No, I was suggesting the IPP client would include SNMP as well as IPP. It's
HL> everyone trying to squeeze through the same hole in the firewall which is
HL> causing HTTP to enter the conversation. If IPP is to layer
HL> on HTTP, they why not SNMP. I'm sure it has already been done.
There have been a couple of proposals for layering SNMP over HTTP
and/or mapping SNMP operations to URLs. There is no standard for
either, however.
Perhaps I should have been more explicit:
Requiring the use of two protocols to solve one problem, whether
or not they are both layered over a third protocol, is a Bad
Idea.
The essential issue here is one of complexity; I believe that what
IPP is attempting to do is define a the operations for submitting
and user-level control of print jobs. The MIBs (which I have not
studied) should be designed to support _Management_ (the 'M') -
which is to say monitoring and control, usually by a third party
(neither the printer nor the user of the printer).
The requirements for operation and management are different, and I
don't think that it helps either effort to combine them. It
certainly isn't good design (IMHO) to require both MIME/HTTP parsers
and ASN1/SNMP parsers just to submit a job to a printer.
--
Scott Lawrence EmWeb Embedded Server <lawrence at agranat.com>
Agranat Systems, Inc. Engineering http://www.agranat.com/