You're going to find that mapping IPP semantics (control file, job reject codes, etc.)
is going to be very difficult to do, especially given the diverse LPR/LPD
environments. I think administrators would much rather transition to IPP than
invest a large amount of time shoe-horning these users into the new environment.
There current implementations are working fine, and I think we are only talking
about Unix clients making up the bulk of these end users. The user interface
available with unix-based LPR/LPD clients doesn't even handle the fact that
a job can be refused for the vast majority of possible reasons that an IPP server
might issue. The LPR interface only handles any errors dropping the file into the
spool directory. The LPD daemon writes any errors into an administrative log
file that must be looked at to determine if and why a job might not have printed.
Its just not realistic to expect massive amounts of gateway code to be written
for LPR/LPD clients, only to give them the ability to know whether their job
can be printed (i.e., VALIDATE_JOB), which is the only feature of IPP that
I could see LPR/LPD clients utilizing. The existing interface just doesn't allow
any interactivity with the job submission process.
LPR/LPD -to- IPP is not how I think IPP will be deployed; we need a rich user
interface (GUI, http-capable, etc.) to really take advantage of what we are
offering. Also the Windows print provider interface seems to also provide all
of these capabilities to GUI-based windows clients.
> I might note that IPP Spoolers are currently not part
>of the IPP protocol, so we are simply having an academic discussion,
>right?
We haven't restricted IPP to either spoolers or print servers, and we shouldn't
preclude either implementation.
Randy
(I hope my email messages are easy to read now, I re-configured my
email client to not wrap all of my text)