Subject: Re: IPP> Job-URI discussion

From: [email-masked] (Robert Herriot)
Date: Mon, 8 Sep 1997 14:51:32 -0700

I think that you are missing a piece in the transition story.
Customers will install print servers that run IPP servers, but printers
acessible via these servers must also be accessible via LPD protocol
for those client still running older systems.  Thus these new IPP servers
will also have to support LPD as well, either directly or via an
LPD-to-IPP gateway.

Bob Herriot

> From [email-masked] Mon Sep  8 13:53:38 1997
> 
> Robert Herriot wrote:
> > 
> > > From [email-masked] 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
>

---

From: Randy Turner <[email-masked]>
Date: Mon, 08 Sep 1997 15:12:33 -0700

> will also have to support LPD as well, either directly or via an

I'm assuming that you're talking about the installation of a 
new print server box, since existing print server boxes would be
running LPD already for the existing LPR clients. In the case of a
new print server being installed that will host IPP services, if
the administrator also wants LPD support, why can't he/she enable
LPD as well and run LPD<->LPD? Maybe we should be exchanging
graphical pictures ...

Randy