Subject: RE: IPP> Identifying jobs in requests

From: Paul Moore <[email-masked]>
Date: Thu, 17 Jul 1997 12:38:25 -0700

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:[email-masked]]
> Sent:	Thursday, July 17, 1997 7:20 AM
> To:	Paul Moore; [email-masked]'
> 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
>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 17 Jul 1997 15:17:17 PDT

> then you would need to assign an IP port to each job or something like

I thought it was the other way around: using URLs allows the protocol
used for cancel job to be different than the protocol used for creating
the job, because the URL scheme itself identifies the protocol.

Larry