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