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?
Next, let's examine the IPP-to-LPD gateway where the gateway returns a
Job-URI. The gateway creates the job-Id for LPD when it receives a
Print-Job operation. It then returns to the IPP client the Job-URI
which consists of the printer-URI and the LPD Job-Id. This Job-URI is
the same one that Cancel-Job uses to specify the job to cancel. Because
the gateway composed the Job-URI, it can parse it into the printer-URI
and job-URI. When a client performs Get-Jobs, the Job-Ids in the lpq
response to the gateway are composed with the printer-URI to form the
value of each Job-URI in the Get-Jobs response. If the client sends an
lpq directly to the printer, bypassing the gateway, it sees the job's
Job-Ids rather than their Job-URIs. So the client gets different values
for identifying the jobs and the client cannot convert between Job-URI
values and Job-Id values because the rules for composing Job-URIs are
not specified.
<RKD> ditto the above question.
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?
<RKD> How does the client know whether or not the id it assigned
<RKD> is valid? What happens if it cnacels the job with the client
<RKD> assigned id? Does it get told that the id is invalid? This
<RKD> seems pretty flaky to me.
The client must use the lpq command to get Job-Ids. When a client performs
an lpq, the Job-Ids in the Get-Jobs reply to the gateway become the
values of the lpq response. This Job-Id from lpq is the same one that lprm
command uses to specify the job to cancel. If the client sends a
Get-Jobs directly to the printer, bypassing the gateway, it sees the
same values for Job-Ids.
<RKD> Again, I don't understand this mixed mode of operation. Why
<RKD> would an lpr client assume that the printer on the other end
<RKD> would understand IPP? For that matter, why would the client
<RKD> speak IPP? For that matter, if it did speak IPP, why would
<RKD> it need a gateway?
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?
When a client performs an lpq, the Job-URIs in the
Get-Jobs reply to the gateway must be mapped to the Job-Id for the lpq
response. When the gateway receives an lprm command, it must map the
received Job-Id to the IPP Job-URI required for Cancel-Job. If the
client sends a Get-Jobs directly to the printer, bypassing the gateway,
it sees Job-URIs which have no relation to the Job-Id's that it sees via
the gateway.
<RKD> Once again I question why a client would operate in this mixed
<RKD> mode. Why would an lpr client EVER use an IPP Get-Jobs???
There are two ways to handle the mapping. Either the
gateway maintains its own internal table which it must update when jobs
complete or it needs a scratch-pad attribute in the job where it can store
the Job-Id. The latter case would require that servers not throw away
unsupported attributes and a search of the mapping would require that the
gateway perform a Get-Jobs.
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.
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?
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.
<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