Subject: RE: IPP> Identifying jobs in requests

From: Paul Moore <[email-masked]>
Date: Thu, 17 Jul 1997 13:49:05 -0700

I mean that not using jobids at all (which is what we do at present)
ties us to HTTP.

In the current model a cancel job is done by posting a cancel operation
to the job URL. No job id is sent, it is implied in the transport
endpoint.

> -----Original Message-----
> From:	JK Martin [SMTP:[email-masked]]
> Sent:	Thursday, July 17, 1997 1:45 PM
> To:	Paul Moore
> Cc:	[email-masked]
> Subject:	RE: IPP> Identifying jobs in requests
> 
> > 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.
> 
> 
> Is this really true?  Do you mean we would be tying ourselves to HTTP
> by using a URL as a job ID?
> 
> It would seem that just because we choose the use the syntax and
> semantics of a URL doesn't mean we necessarily tie ourselves to HTTP,
> right?
> 
> 	...jay

---

From: Randy Turner <[email-masked]>
Date: Thu, 17 Jul 1997 17:05:13 -0700

> I mean that not using jobids at all (which is what we do at present)

In the model document, job identifiers are URLs. If we have pushed URLs
out of themain body of the protocol up into the transport layer, then
this is a mistake. Job identifiers
belong within the application/ipp body, and, according to the model
document, object
identifiers are in URL format. Also, the use of URL/URI strings as
object identifiers in
and of itself does not tie us to any one transport mechanism.

Randy