Subject: IPP> Printers and Spooling Systems

From: [email-masked]
Date: Mon, 15 Sep 1997 17:45:53 -0700 (PDT)

I apologize for my absence of the three months,  but a 2 week
vacation unwillingly turned into three months off.

I have been reading the various discussions about Job URI/URL and Job IDs,
and there are always various objections raised involving 'job movement'.

At this point I would like to point out that during initial
discussions of the IPP protocol,  the following issue was raised
(at San Diego, and at several teleconferences prior to this):

Patrick Powell:  "Is IPP a 'submit job to printer' protocol or
a 'submit job to spooler' protocol?"

Summary of Answers:  It is a 'submit job to printer' protocol.  We do not
want to deal with spooler management issues in the first draft.

In the discussions that are going on,  I notice that most of the effort
is given to worrying about 'moving jobs' or 'job spoolers'.  I would like to
then ask the question:

     Is IPP now a 'submit job to spooler' protocol?

If you treat a printer like a 'leaf' at the end of the 'print tree'
of client->spooler->spooler....->printer  or even client->printer,
it simplifies the understanding of the requirements considerably.
If you want IPP to be a 'client->spooler' protocol AND a 'client->printer'
protocol AND a 'spooler->printer' protocol,  I think that you are
trying to undertake a major set of problems.

One of the difficulties with LPR (RFC1179) was that it was a 'client->spooler'
protocol,  and did not deal with the 'client->printer' or 'spooler->printer'
problems.  I would like to solve the 'client->printer' and 'spooler->printer'
problems as well as we can.

I would like to note that 'moving jobs' from one printer to another can
be accomplished at a higher level by having a spooler 'remember' the job
and then 'remove' it from the printer and 'send' it to the new printer.
There is a cost to this, of course - the spooler has to save the job.
However, there is also a cost to 'moving jobs' from the printer - the
PRINTER has to save the job.

I would like to suggest that we focus on client->printer and spooler->printer
issues,  and not try to deal with client->spooler or designing spoolers.
Let the print spooler vendors/developers do this and do not try to build all
the necessary spooler functionality into a printer.

Patrick Powell