> 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