Paul Moore wrote:
> Not the issue. I do not object to using URI as job identifiers - I
> object to not giving the job identifier in a job specifc request.
>> To restate - when I do a canceljob operation I do not supply a job
> identifier - the target job is implicit in the transport endpoint -
> this
> ties us to a transport.
Ok, I think we're in violent agreement here....I agree that the
operandsof an IPP operation should not be implied by any transport-level
information;
especially if we plan on moving IPP to other transports...
Randy
>>> > -----Original Message-----
> > From: Randy Turner [SMTP:rturner at sharplabs.com]
> > Sent: Thursday, July 17, 1997 5:05 PM
> > To: Paul Moore
> > Cc: 'JK Martin'; ipp at pwg.org> > Subject: Re: IPP> Identifying jobs in requests
> >
> > Paul Moore wrote:
> >
> > > I mean that not using jobids at all (which is what we do at
> present)
> > > ties us to HTTP.
> >
> > 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
> >
> >
> > >
> > >
> > > 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:jkm at underscore.com]
> > > > Sent: Thursday, July 17, 1997 1:45 PM
> > > > To: Paul Moore
> > > > Cc: ipp at pwg.org> > > > 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
> >
> >