RGH: It is more a matter that an end-user may be printing from many
RGH: different applications, some using IPP and others using LPD to
RGH: the same printer. The user may not even be aware of the route each
RGH: application takes to the printer. But the user may look at all
RGH: jobs through a single print queue window.
RGH: This answer applies to all of your questions that pertain to this
RGH: issue.
>
> Next, let's examine the LPD-to-IPP gateway where the gateway returns a
> Job-Id. The gateway client creates an job-Id which the gateway ignores
> because the IPP server creates its own Job-Id. Existing LPD servers
> sometimes ignore the Job-Id value requested by the client. LPD provides no
> mechanism for the gateway to inform the client of the Job-Id.
>
> <RKD> The following is to clarify normal lpr/lpd operation ...
> <RKD> So, an lpr request always generates a job-id on the client,
> <RKD> but sometimes it gets ignored (I assume then that the server
> <RKD> assigns the job-id. But there is no way for the server to tell
> <RKD> the client what id it assigned. Did I get it right?
RGH: Yes, you got it right, the server may use the client's job-Id or it
RGH: may create its own job-Id. When the server changes the job-Id, the
RGH: client can determine this only by using heuristics with the 'lpq'
RGH: to match the queued jobs with jobs known to have been submitted.
RGH: Yes, LPD has its problems.
>
> <RKD> How does the client know whether or not the id it assigned
> <RKD> is valid? What happens if it cancels the job with the client
> <RKD> assigned id? Does it get told that the id is invalid? This
> <RKD> seems pretty flaky to me.
RGH: If the client uses its job-Id, the server will assume that the job-Id
RGH: is the server's Job-Id. Yes, it is flaky. That's one of the reasons
RGH: for IPP.
>
> Finally, let's examine the LPD-to-IPP gateway where the gateway returns
> a Job-URI. The gateway client creates a job-Id. The gateway either
> remembers this Job-Id or creates its own because the IPP server creates
> a Job-URI which has no direct relationship to the integer Job-Id
> required by LPD.
>
> <RKD> In the previous case, it sounded like the client could never
> <RKD> depend on the job id it assigned anyway. Why does it do so here?
> <RKD> Why doesn't the gateway ignore the client assigned id as in
> <RKD> the previous case, and force the client to do an lpq?
RGH: The issue is that the gateway has to use some integer Job-Id and the
RGH: Job-URI does not satisfy the requirement. So the gateway either
RGH: creates a Job_Id or uses the client one. In either case, the gateway
RGH: must associate that Job-Id with the Job-URI and it is a number that
RGH: bears no relation to the Job-URI assigned by the IPP server.
>
> QUESTIONS ABOUT VIRTUES OF JOB-URI SOLUTION
>
> Now that I have presented the problems that the Job-URI presents, I
> now would like to question its touted advantages. I have heard two.
>
> 1) It allows for redirection more easily
> 2) It allows for better load balancing
>
> I address both below and conclude that Job-URI's aren't necessary with
> our current understanding of requirements.
>
> I also wonder if Job-URIs that are unrelated to the Printer-URI
> containing the job will confuse users who are exposed to them. A user
> thinks of a job as belonging to a printer. So if a Job is identified by
> the Printer-URI that the user selected and some number, that seems to
> me like a simpler concept.
>
> <RKD> Actually, I NEVER think of the job as belonging to the printer.
> <RKD> Most of the shared printers we use here in IBM are in printer
> <RKD> pools. I never know which one it will print on. I think of my
> <RKD> job as an object that (hopefully) the system knows how to
> <RKD> handle. When I cancel or query a job, I tell the client, and
> <RKD> let it worry about everything from there on. As a user I don't
> <RKD> care.
>
> REDIRECTION
>
> Whether a job is represented uniquely by Job-URI or (Printer-URI,Job-Id),
> either of these "names" references some host somewhere and when a job
> moves, that host has to keep track of where is has moved to, and when
> to delete the reference. It would seem to me that either Job-URI or
> (Printer-URI,Job-Id) are reasonable ways to keep track of jobs, even
> when they move. So either should suffice in this case and since Job-Id
> is easier for legacy connections, Job-Id is the better solution.
>
> <RKD> Certainly you can remember either a URI or a job-id.
> <RKD> I think Randy's point was that using a URI, HTTP provides an
> <RKD> easy way to do redirection. Using a job-id, we would have to
> <RKD> invent a scheme that was IPP specific.
RGH: In the teleconference we discussed that fact that if a client
RGH: accesses a Job-URI which requires redirection, the server
RGH: needs to know when to delete the mapping between the old and the
RGH: new job-URI. Is it immediately after the first query? Is it after
RGH: the job has completed? Each of these strategies has problems.
RGH: In other words, the Job-URI solves only one small piece of the
RGH: problem.
>
>
> In my opinion, the redirection of print jobs is a research area
> that is not well enough understood for us to be creating requirements
> for a standard.
>
> <RKD> Why don't you think it is well understood?
RGH: Because of the problems I cite above and because it has not been
RGH: fully implemented in DPA implementations.
>
> LOAD BALANCING
>
> The idea is that the Job-URI may reference a different host than the
> Printer-URI references so that references to the job don't load the
> print server.
>
> There may be other solutions, such as clustering of Web servers, which
> solve the problem without the added complexity of Job-URIs.
>
> This problem is way beyond the 80% solution we are striving for and is
> also a research area that is not well enough understood for us to be
> creating requirements for a standard.
>
>
> <RKD> One last question ... if we take the course of adopting a job-id,
> <RKD> how do we rationalize the notion of the job being an object? In
> <RKD> my mind, the only object we are left with is the printer object,
> <RKD> because now all operations are on the printer. For example, we
> <RKD> no longer provide the URI of the job and tell it to cancel itself.
> <RKD> We send the operation to the printer and tell it to cancel the job.
> <RKD> Ditto for querying job attributes. The operation goes to the printer.
> <RKD> In my mind, this very fundamental change forever dictates the way
> <RKD> IPP will deal with jobs. If we ever want to imagine the job as a
> <RKD> real object with a life of its own, that can be moved around the
> <RKD> network (whether it be for load balancing, recovery, etc.), queried,
> <RKD> cancelled, indepdendent of where it lives, then we ought not to
> <RKD> bind it now to a printer and lose it's identity as an object.
RGH: I see no reason why an object cannot be named by the pair
RGH: (printer-URI, job-Id). The name and the object are separate
RGH: concepts. The name is just a way to reference the object.
>
> <RKD> I think that Jay's suggestion to allow an implementation to create
> <RKD> job URI's by cleverly using the integer job id's currently supported
> <RKD> by existing system API's is a fine way to solve the problem for most
> <RKD> cases. The standard doesn't require URLs to be created that way,
> <RKD> but neither should it dis-allow it if it makes life easier for a
> <RKD> particular implementation.
> <RKD> does it
RGH: In Redmond, we considered and rejected the idea of having a Job-URI
RGH: that could be parsed into its constituent printer-URI and Job-Id.
RGH: It is certainly OK for a gateway to parse Job-URIs that it created,
RGH: but according to our decision, it is not OK for a client to parse
RGH: the job-URI from some server because they syntax of a Job-URI is
RGH: unspecified.
>
>
>
>
>
>