I should point out that the same argument applies to "job-uri". The only exceptional case is that of a Job being accessed by "job-id" through its containing Printer. In that case, the target is the Job, identified by "job-id", but the Object receiving the request is the Printer.
>
> > The problem we are having at the moment is reconciling this decision with
> > the fact that our lower layer transport protocol also uses the same
> > identifier (in some circumstances), and we wanted our core IPP to be
> > transport independent.
> >
> > By the way, concerning Paul's earlier comment about proxies being the
> > issue, I'm assuming that if we make NO changes to the current specs, that
> > proxies are NOT an issue. Proxies rang the warning bell when it was
> > suggested we mandate other port numbers and/or HTTP methods. Is this not
> > the case?
> >
>
> There could be a problem if a proxy rewrites the Request-URI in any way. Certainly he final proxy in the chain will translate the Request-URI from absolute to relative form. Whether or not these forms are considered the same for purposes of comparison with "printer-uri" is something we haven't worked out yet.
>
> Also, doesn't your TLS for IPP proposal require server redirects for server-initiated security? Won't that involve rewriting the Request-URI?
>
> > Randy
> >
>
> Carl
>
> >
> > ----------
> > > From: Carl Kugler <kugler@us.ibm.com>
> > > To: ipp@pwg.org
> > > Subject: Re: IPP> Identifying jobs in requests
> > > Date: Tuesday, June 02, 1998 4:50 PM
> > >
> > > I agreee with Scott in "URLs within IPP operations",
> > > http://www.findmail.com/list/ipp/3695.html
> > > that it as a bad idea to embed "printer-uri" in the ipp message body. I
> > went back through the archives to see why "printer-uri" was added to IPP in
> > the first place.
> > >
> > > > 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
> > >
> > > I think this is actually a bit of a jump from the original proposal in
> > > "Identifying jobs in requests",
> > > http://www.findmail.com/list/ipp/1700.html
> > > which only asked for an embedded Job identifier, not an embedded Printer
> > identifier, with the rationale that in some implementations a Job is not
> > directly addressable and must be accessed through its containing Printer.
> > >
> > > If we accept that Printers are always directly addressable, then there's
> > no reason to put the target printer-uri in the application/ipp message
> > body.
> > >
> > > -Carl
> > >
> > > >
> > > > > From rturner@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@sharplabs.com]
> > > > > > > Sent: Thursday, July 17, 1997 5:05 PM
> > > > > > > To: Paul Moore
> > > > > > > Cc: 'JK Martin'; ipp@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@underscore.com]
> > > > > > > > > Sent: Thursday, July 17, 1997 1:45 PM
> > > > > > > > > To: Paul Moore
> > > > > > > > > Cc: ipp@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 -----
> > > >
> > > >
> > > >
> >
> >
>
>
>