IPP Mail Archive: Re: IPP> Job-URI vs. Job-Id: How would you handle moving jobs?

Re: IPP> Job-URI vs. Job-Id: How would you handle moving jobs?

Robert Herriot (Robert.Herriot@Eng.Sun.COM)
Mon, 8 Sep 1997 12:56:41 -0700

> From jkm@underscore.com Fri Sep 5 20:13:55 1997
>
> Since the Job-Id approach implicitly uses the Printer-URL, then
> how would you handle moving jobs between Printers? Wouldn't this
> present something of a showstopping problem? How would the client
> keep track of the change in Job-Id, much less the change in Printer?
>
> For printing systems using IPP, it would seem that the Job-URL
> approach would suffice quite nicely due to the inherent opacity
> of the job identification.
>
> Comments?
>

It seems to me that there are two solutions to this problem. Either
a) a job has a constant identification for its life or
b) an identification that changes when it moves.

In case a, it doesn't matter whether a job has a job-URI or a
(printer-URI,job-Id), the same server manages the job for its duration
regardless of the location of the job

Case b may seem simpler because of the redirection that can
be applied to Job-URI. But this apparent simplicity hides the complexity
of how long the forwarding-server keeps a record of a job that it no
longer controls. The simplest solution for this case may be the same
as for case a, namely the server keeps a forwarding record for the duration
of the job.

I stand by my previous statements, that the cited advantages of a
job-URI are based on speculation. I have not seen anyone provide enough
detail for us to understand the full solution for the move-job
problem.

I have no problem with a design that might make the solution of future
problems easy as long as it doesn't affect the solution to current
well-understood problems.

Bob Herriot