We discussed this at the august meeting. You cannot extract the jobid
from the job-URI. Remember a 'particluar implmentation' has no meaning
for things visible in a wire protocol. There is both the client and the
server - if the url is to be in a specifc format then both sides must
agree to this. The only way that this would work is if we mandated the
url format (which we discussed doing and voted against)
> -----Original Message-----
> From: Roger K Debry [SMTP:rdebry at us.ibm.com]
> Sent: Friday, September 05, 1997 6:07 AM
> To: ipp at pwg.org> Subject: Re: IPP>MOD Why use Job-Id instead of Job-URI for Jobs?
>> 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.
> >
> >
> >
>