IPP> Identifying jobs in requests

IPP> Identifying jobs in requests

IPP> Identifying jobs in requests

Paul Moore paulmo at microsoft.com
Thu Jul 17 15:38:25 EDT 1997


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
> 



More information about the Ipp mailing list