Yes, it does appear that we have been in violent agreement all along,
that everyone now believes the target job URI must be specified at the
IPP protocol layer, regardless of the transport used.
It also sounds like we have consensus in support of the proposal
by Paul/Bob (that launched this interesting thread).
If we could only resolve all IPP issues this quickly!
...jay
----- Begin Included Message -----
Date: Thu, 17 Jul 1997 18:11:41 -0700
From: Robert.Herriot at Eng.Sun.COM (Robert Herriot)
To: paulmo at microsoft.com, rturner at sharplabs.com
Subject: Re: IPP> Identifying jobs in requests
Cc: jkm at underscore.com, ipp at pwg.org
I think that we are finally getting to the heart of this issue, namely
that the protocol currently puts the URI of the operation's target object
in the Request-Line of the HTTP operation, and it is not in the
application/ipp message body.
I think that I am hearing both Randy and Paul say that they think that
the target job or printer URI should be a parameter in the application/ipp
message body. Am I right in my understanding?
Bob Herriot
> From rturner at sharplabs.com Thu Jul 17 17:35:23 1997
>> 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
> > >
> > >
>>>>
----- End Included Message -----