I agree with Harry in that there are multiple ways to interpret the
original IPP charter; however, rather than looking at the charter, I would
like to look at the result.
I content that IPP is not optimized for a print server/print subsystem
running on a general computing platform to communicate with a
printer/marking engine running on a separate piece of hardware, e.g.
- long, internationalized, text-string parameter based
commands and responses are not optimal for an embedded product.
- no support for alerts, etc.
- no detailed control and status information e.g. TIPSI's
"gas gauge" supplies level reporting
the target of the SDP. It therefore needs to be optimized for:
- delivering the job
- reporting printer configuration and status
- setting printer defaults
- supporting alerts from the printer to the server
- reporting the results of printing the job (accounting)
I continue to maintain that we need a single large, well designed protocol
to accomplish this goal and not a conglomeration of protocols patched
together.
**********************************************
* Don Wright don@lexmark.com *
* Product Manager, Strategic Alliances *
* Lexmark International *
* 740 New Circle Rd *
* Lexington, Ky 40550 *
* 606-232-4808 (phone) 606-232-6740 (fax) *
**********************************************