Subject: IPP> Disable-Accepding-Jobs & Enable-Accepting-Jobs

From: [email-masked]
Date: Tue, 7 Jul 1998 18:17:56 -0400

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                 [email-masked] *
* Product Manager, Strategic Alliances       *
* Lexmark International                      *
* 740 New Circle Rd                          *
* Lexington, Ky 40550                        *
* 606-232-4808 (phone) 606-232-6740 (fax)    *
**********************************************

---

From: Tom Hastings <[email-masked]>
Date: Thu, 9 Jul 1998 20:54:13 PDT

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