I agree with Jay that this seems like a clean approach. However,
if I've understood all of the arguments, I thought that dictating the form
of the URL was a no-no. On the other hand, if a PARTICULAR IMPLEMENTATION,
such as NT, requires a 32-bit integer job ID to be consistent with its existing
APIs, then there should be no reason why THAT implementation could not
use the approach that Jay suggests to easily map to an internal integer job
identifier.
I know that this may not solve the problem for a gateway somwhere in the
middle, but it does seem to me that for a particular server implementation
this works fairly well.
Roger K deBry
Senior Technical Staff Member
Architecture and Technology
IBM Printing Systems
email: rdebry at us.ibm.com
phone: 1-303-924-4080
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 09/05/97 06:56
AM ---------------------------
ipp-owner @ pwg.org
09/04/97 10:06 PM
Please respond to ipp-owner at pwg.org @ internet
To: Robert.Herriot @ Eng.Sun.COM @ internet
cc: ipp @ pwg.org @ internet
Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?
Bob,
Thanks for the rebuttal info on this issue. You continually point
out this basic desire/premise/goal:
IPP job id == LPD job id
You gave lots of good examples, paying particular attention to
exposure issues with end users. In fact, my reading of your message
makes me come away believing that consistent end user visibility is
extremely high on the priority list...maybe even #1.
This may be. (I'm not sure, myself.) However, if the exposure of
job ids is so critical, then why don't we also insist on:
IPP printer name == LPD printer name
I've been assuming all along that an IPP printer name would appear
to an end user as something like:
http://host.domain/printer/<name>
(Or any one of five bazillion permutations on the URL theme.)
However, in LPD land, a "printer" is almost always a "simple" name,
such as: laser1, plot3, mkt, lp3, etc. Simple sequences of just
letters and numbers (usually), with possibly a sprinking of hyphens,
underscores, etc. However, almost never is the name constructed as
a series of sub-tokens assembled in a hierarchical fashion. (Sure,
it can be done...but it just *isn't* commonly done in real practice.)
Aren't you concerned with that kind of shift in visibility, too?
Of course, one can always assume some sort of standard (de facto)
mapping mechanism, whereby the "simple" name is always the last token
of the URL string:
http:://host.domain/printer/laser1 == laser1
If this is good enough, then why can't the same be true for job
ids, eg:
http://somewhere.net.domain/subsys/server3/345 == 345
If nothing else, then such a simple job id mapping mechanism can be
standardized for IPP "printers" front-ending LPD queues. Even in the
non-LPD case, this kind of job identification looks pretty clean:
http:://host.domain/printer/laser1/345
This kind of approach looks real clean to me, but maybe I'm just a
bit too close to the code, if you know what I mean.
I must be missing something, right? Thanks for your insights.
...jay
----------------------------------------------------------------------
-- JK Martin | Email: jkm at underscore.com --
-- Underscore, Inc. | Voice: (603) 889-7000 --
-- 41C Sagamore Park Road | Fax: (603) 889-2699 --
-- Hudson, NH 03051-4915 | Web: http://www.underscore.com --
----------------------------------------------------------------------
Robert Herriot wrote:
>> 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.
>>>