IPP Mail Archive: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs?

Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs?

papowell@astart.com
Tue, 16 Sep 1997 15:18:16 -0700 (PDT)

> From rturner@sharplabs.com Tue Sep 16 13:09:05 1997
> Date: Tue, 16 Sep 1997 12:48:59 -0700
> From: Randy Turner <rturner@sharplabs.com>
> To: ipp@pwg.org
> Subject: Re: IPP>MOD What if we had both Job-Id and Job-URI for Jobs?
>
>
> PAPowell said:
> >I disagree. I feel that LPD->IPP gateways will be needed for
> >various compatibility reasons, as there are a very large number of
> >folks out there who have LPR/LP type of implementations and want to
> >get the services available with IPP type of control, but do not want
> >to upgrade/change their printing mechanisms on ALL the hosts under
> >their control.
>
> 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.

Ummm... that is not true. The LPRng interface quite happily delivers errors.
And note that it is free, compiles and runs on just about any UNIX system with
TCP/IP networking, and there is even an NT port (Don't ask, it wasn't pretty).

> 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.

Not true. See the LPRng implementation. The error messages are stored on
a 'per job' basis, and you can use LPQ to see the reasons for print failure.

> 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.

I don't think 'vast amounts' is the case. While I personally have not done it,
collegues have indicated that the IPP protocol could be implemented in about
1500 lines of Perl, and could be backended into LPRng very simply.

>
> 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.
>

I think that if you start trying to deal with spoolers and spooler topics
you are widening the scope of discussion far too much.

I must say that I think that this is simply a matter of opinion. Somebody
WILL implement a LPD to IPP gateway, somebody else (or the same person)
WILL implement a IPP to LPD gateway. Now the problem is to see if you
can get the gateways to interact correctly with IPP and LPD... Sigh...

> Randy
> (I hope my email messages are easy to read now, I re-configured my
> email client to not wrap all of my text)

I think that this type of discussion is need in the context of IPP.

Patrick Powell