also using URLs to imply the job id means that we are tied to a specific
transport - something we tried to avoid. If we were to use , say, raw IP
then you would need to assign an IP port to each job or something like
that.
> -----Original Message-----
> From: Carl-Uno Manros [SMTP:carl at manros.com]
> Sent: Thursday, July 17, 1997 7:20 AM
> To: Paul Moore; 'ipp at pwg.org'
> Subject: Re: IPP> Identifying jobs in requests
>> At 05:11 PM 7/16/97 -0700, Paul Moore wrote:
> >This is to propose a change to the model based on reviewing the
> >protocol.
> >
> >At present the plan is that to cancel (for example) a job you send a
> >cancel operation to the job's URL.
> >
> >Bob Herroitt and I propose that this be changed: you send a cancel
> >operation to the printer URL giving a JobId as a parameter.
> >
> >This has the advantage that the client only needs to know one URL for
> >all operations on a given printer.
> >
> >This then carries through into GetJobs returning a set of Jobids
> instead
> >of a set of Job URLs. A jobid is just an opaque token, the client
> should
> >not attempt to use it except as a way of identifying a job back to
> the
> >server.
> >
>> Paul,
>> I am not too happy about this change. Going back to our earlier
> discussions,
> before you got involved, we determined to use URIs to identify Jobs
> because
> it gave us the flexibility to actually create the Jobs under a
> different
> server name (on the same or a different host), which might be useful
> in some
> bigger printing systems. Your solution seem to be optimized for the
> scenario
> where you have a generic Web server in combination with a Printer in
> the same
> host. Your solution seems to just complicate things a bit in scrnarios
> where
> you have an embedded or dedicated HTTP server that only does printing.
>> In summary, I think your solution introduces new restrictions in our
> design,
> which are not particularly desirable. Is there any other way that you
> can
> solve your design problem?
>> Carl-Uno
>