> From rdebry at us.ibm.com Fri Sep 5 08:31:46 1997
>> Bob, can you clarify a few things for me please? It would help me understand
> your write-up.
>> My questions noted with <RKD>
>> First let's examine the IPP-to-LPD gateway where the gateway returns a
> Job-Id. The gateway creates the job-Id for LPD when it receives a
> Print-Job operation. It then returns the LPD job-Id to the IPP client
> as the value of the Job-Id. This Job-Id is the same one that Cancel-Job
> uses to specify the job to cancel. When a client performs Get-Jobs,
> the Job-Ids in the lpq reply to the gateway become the values of the
> Job-Id attribute in the Get-Jobs response. If the client sends an lpq
> directly to the printer, bypassing the gateway, it sees the same
> values for Job-Ids.
>> <RKD> Why would the IPP client bypass the gateway and send an lpq
> <RKD> directly to the printer? It seems to me that an IPP client
> <RKD> would always use IPP. Are you describing a pathological case
> <RKD> here? Why would an IPP client (or and end user for that matter)
> <RKD> even suspect that the real printer would even understand lpq?
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.
>>>>>>