Its just in the current case of HTTP, the information is redundant in some
cases, and could be misleading for some implementations.
What we need is some method or algorithm that recognizes the relationship
between transport and IPP URIs, but at the same time provides a
transport-independent naming scope (still a URI), that is independent of
the HTTP transport's treatment of the HTTP URI. At the moment, it seems
like our current specs are the least vulnerable to problems resulting from
HTTP intermediaries.
Also, my TLS proposal did specify redirects as one way of accomplishing
secure IPP. The other way was only publishing the secure form of the URI.
Also, there is a third way that has been proposed, using in-band SASL
negotiation ( which I think is probably best for a server that supports
both secure and non-secure IPP ).
Randy
----------
> From: Carl Kugler <kugler@us.ibm.com>
> To: ipp@pwg.org
> Subject: Re: IPP> Identifying jobs in requests
> Date: Wednesday, June 03, 1998 8:41 AM
>
> >
> > The reason we have URIs in the message body is that from very early on
we
> > decided to rely on URIs as object identifiers WITHIN the core IPP
protocol.
>
> But there is no reason to put a Printer identifier inside a request that
is addressed to the Printer that reads the request.
>
> At one time, people were proposing some kind of dispatching or routing
IPP Object that would receive IPP requests and route them based on the
embedded "printer-uri". But the final decision was that the HTTP
Request-URI and the embedded "printer-uri" MUST be the SAME. Therefore the
IPP Object that receives the request must be the target.
>
> > 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 -----
> > > >
> > > >
> > > >
> >
> >