I will try to explain why the Job-URI is harder to support than the
Job-Id for an LPD gateway. I will also explain why the requirements
that call for a Job-URI are not well enough understood to be
requirements.
ANALYSIS OF JOB-URI VS JOB-ID
For the gateway, there are two directions: IPP-to-LPD and LPD-to-IPP.
I have two goals for these gateways. They should
1) be stateless: which means that gateways get all their information
from the downstream server rather than storing information about
jobs in the gateway.
2) provide values to the client that are the same (possibly after a
conversion algorithm) as the client could get from bypassing the
gateway, which means gateways pass information without converting
it or converting it in an algorithmic fashion that a client can
apply an inverse function to. This provision is important because
some applications on a client may use the gateway and others may
bypass it.
The Job-URI is hardest to support in the LPD-to-IPP direction because
it fails to meet goal #1 above (it requires state). There is no simple
way to algorithmically map the IPP Job-URI to an LPD Job-Id because the
Job-URI is opaque.
The Job-URI solution for both directions fails to meet goal #2 because
it has the problem of exposing both Job-Ids and Job-URIs to a user for
the same set of jobs and there is no conversion algorithm.
Now for the two gateway directions for both Job-Id and Job-URI.
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.
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.
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. 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.
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. 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. 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.
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.
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.
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.