>>>>> "JK" == JK Martin <jkm@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@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@agranat.com> Agranat Systems, Inc. Engineering http://www.agranat.com/