Bob Herriot
> From rturner@sharplabs.com Mon Sep 8 13:53:38 1997
>
> Robert Herriot wrote:
> >
> > > From rturner@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
>