Subject: Re: IPP> Job-URI discussion

From: [email-masked] (Robert Herriot)
Date: Mon, 8 Sep 1997 13:21:03 -0700

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

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 13:47:20 -0700

> on such servers in order to allow for an orderly transition of

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

---

From: Jay Martin <[email-masked]>
Date: Mon, 08 Sep 1997 18:00:53 -0400

> save gateway writers a few lines of code.

Randy's right (IMHO), that the REAL challenge is to get IPP clients
out in the field.  Printers and print server systems will probably
support LPR/LPD long into the future, and Randy makes a good point
that existing clients will continue to use that infrastructure.

Bob has made some good points in the last few messages, but I think
Randy has really hit the nail on the head...at least with respect to
LPR/LPD.

Windows may be a different animal to deal with, though...

	...jay