Robert Herriot wrote:
>> > From rturner at sharplabs.com Fri Sep 5 18:50:19 1997
>> > I don't consider the scenario of an LPD client talking over the
> network
> > to a IPP server to be a viable scenario. For transitional purposes,
> > administrators should not be tearing down their existing printing
> > environments, in this case, we don't have to worry about actually
> > converting LPD control file attributes to IPP equivalents; because
> each
> > site's existing LPD environment works fine as it is.
>> You forgot about the very important case of new IPP servers having to
> take jobs from existing LPD clients. This will require LPD-to-IPP
> gateways
> on such servers in order to allow for an orderly transition of
> customers.
This is the case I was talking about, I don't think this is a
prevalent case. The currently existing base of LPR clients currently
use LPR/LPD to print, and these systems work. When transitioning
to IPP, I don't expect these systems to be torn down. Rather, I
expect client to slowly be configured with IPP clients. You could
even have a hybrid case where the LPR/remote-LP (SYSV) system has
their respective "printcap" file entries for certain IPP-enabled
servers point to shell scripts that automatically launch a real
IPP client to do the "over-the-wire" stuff.
Overall, I don't consider this particular gateway problem to be
worthy of altering the original model. The real value in getting
IPP to users is not enabling LPR clients, its enabling IPP clients
being able to locate IPP printers via the WEB and subsequently
printing to them. I think we're spending too much time trying to
save gateway writers a few lines of code.
Randy
>> Those clients expect job-Ids which are INTEGERS. Otherwise, they
> break.
>> > Getting back to the LPD gateway problem, while I am writing this,
> Jay's
> > mail message stating that "there is no way for an LPD client to know
> > what job id was created on job submission" echoes a conversation Jay
> > and I had on the phone earlier. RFC 1179 states that the only way an
> > LPD client knows how to reference a job is by executing a subsequent
> > LPQ request and obtaining a list of jobs and hoping that the LPD
> server's
> > job list contains enough unique information for the end user to pick
> out
> > his or her job from the list.
>> It is true that a client does not get the job-Id from lpr, but there
> is
> still the round trip problem where the client gets a job-Id via lpq
> and
> then returns it via lprm. The LPD-to-IPP gateway has to know which IPP
> job-ID/job-URI is associated with the LPD job-ID received with the
> lprm
> command. That is the hard part when IPP supports only job-URI; and it
> is a real problem, not an imagined one.
>> Bob Herriot