Subject: RE: IPP> Identifying jobs in requests

From: "Turner, Randy" <[email-masked]>
Date: Wed, 3 Jun 1998 10:34:56 -0700

It's a question of layering, and not a question of actual transport
capability. In our model we have a much more serious case of overlap
between transport and application addressing than do most other
applications. WEBDAV doesn't have to worry about this since they do not
have to be transport-independent. Most of the time, there is a
multiplexing/demultiplexing step involved when a transport layer has to
demultiplex something and send it to the right endpoint. In our case,
there is a one-to-one relationship between transport identifier (HTTP
URL) and IPP URL. Not that there has to be, its just that's the scenario
that everyone seems to be worried about. If you carved up a URI wherein
some portion was transport and some portion was IPP, then it might be a
little easier to deal with, in that it is much less likely that a
correctly chosen IPP URI-portion would be rewritten or modified in any
way from sender to receiver.

Randy

	-----Original Message-----
	From:	Carl Kugler [SMTP:[email-masked]]
	Sent:	Wednesday, June 03, 1998 9:39 AM
	To:	[email-masked]
	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 <[email-masked]>
	> > To: [email-masked]
	> > 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 <[email-masked]>
	> > > > To: [email-masked]
	> > > > 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 [email-masked] 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:[email-masked]]
	> > > > > > > > Sent: Thursday, July 17, 1997 5:05 PM
	> > > > > > > > To:   Paul Moore
	> > > > > > > > Cc:   'JK Martin'; [email-masked]
	> > > > > > > > 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:[email-masked]]
	> > > > > > > > > > Sent: Thursday, July 17, 1997 1:45 PM
	> > > > > > > > > > To:   Paul Moore
	> > > > > > > > > > Cc:   [email-masked]
	> > > > > > > > > > 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 -----
	> > > > > 
	> > > > > 
	> > > > > 
	> > > 
	> > > 
	> 
	>

---

From: "Carl Kugler" <[email-masked]>
Date: 3 Jun 1998 18:37:31 -0000

> way from sender to receiver.

Okay, to carve up URIs by layer, we should use Relative identifiers.  So the Request-URI identifies a Server within (relative to) a Host,
the "printer-uri" identifies a Printer within a Server,
the "job-uri" identifies a Job within a Printer.

All are Relative URIs defined within the context of the encapsulating entity.  There can't be overlap conflicts.