I agree that we need to be careful on "function creep". On the other hand:
1. some of the useful new operations being proposed are also only for
operators, such as PausePrinter and PurgePrinter.
2. More over, a way to disable/disable an IPP Printer from accepting jobs
fits in as an optional operation for use with IPP/1.0, in that there is
already a Printer attribute: "printer-is-accepting" jobs that has no way
to be set true or false in the protocol, even though there is also an IPP/1.0
error status to return if the value is 'false' and a client attempts
to submit a job.
3. Finally, the operations being proposed (PausePrinter) also stop new
jobs from being submitted from an IPP Printer to a device, so also being
able to prevent jobs from being submitted to the IPP Printer is a
natural operation to have.
Tom
At 15:17 07/07/98 PDT, don at lexmark.com wrote:
>I think we have quickly gone over the edge already. Once we start adding
>these kind of functions, we are starting the "function creep" process all
>over again. One of the problems with the existing IPP definition is that
>taken individually, each and ever function and enhancement we added made
>sense. However, on the whole, IPP swelled to enormous proportions. We
>need to strongly push back on going beyond the simple MS operational
>enhancements until we have some real world experience and customer feedback
>on IPP 1.0.
>>**********************************************
>* Don Wright don at lexmark.com *
>* Product Manager, Strategic Alliances *
>* Lexmark International *
>* 740 New Circle Rd *
>* Lexington, Ky 40550 *
>* 606-232-4808 (phone) 606-232-6740 (fax) *
>**********************************************
>>>>