Randy
-----Original Message-----
From: Carl Kugler [SMTP:kugler@us.ibm.com]
Sent: Wednesday, June 03, 1998 9:39 AM
To: ipp@pwg.org
Subject: Re: IPP> Identifying jobs in requests
>
> We use URIs to identify IPP objects. If we want IPP to
maintain
> transport-independence, then we will always need to have some
type of valid
> URI denoting the target of an IPP request inside our protocol.
>
I don't think it's asking too much of a transport layer to
require that it be capable of addressing a request to the target object.
Without that capability, we'd have to invent our own IPP routers and
multiplexors; IPP Objects that retransmit requests based on embedded
addressing information.
> 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 -----
> > > > >
> > > > >
> > > > >
> > >
> > >
>
>