Subject: Re: IPP> Identifying jobs in requests

From: "Randy Turner" <[email-masked]>
Date: Tue, 2 Jun 1998 18:55:04 -0700

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.
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?

Randy

----------
> 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 15:41:51 -0000

> 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.

> suggested we mandate other port numbers and/or HTTP methods. Is this not

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: Jay Martin <[email-masked]>
Date: Wed, 03 Jun 1998 12:24:51 -0400

Carl Kugler wrote:

> 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".

I was one of those people suggesting demultiplexing/dispatching,
but only within an HTTP server environment.  As such, the server-
side component (CGI script, servlet, etc) would use the HTTP
header component to discriminate the real target.

> 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.

Did we actually come to a final decision?  I didn't read that we had.
(Maybe I'm missing a message or two on this subject?)

> There could be a problem if a proxy rewrites the Request-URI in any way.

Yeah, this worries me, too.  We definitely need some serious
implementation experience to better understand the ramifications
of this situation.

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

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

> 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 tha…

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.

---

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

> header component to discriminate the real target.
If I understand what you're saying, this works fine today, with the existing model.  For example, in our implemenation, these two Request-URIs sent to Host carlk:

    /servlet/IPPServlet/vega-lp
    /servlet/IPPServlet/pp4019

both cause the web server on carlk to invoke servlet IPPServlet.  IPPServlet uses the path info from the Request-URI to determine if the target output device is "vega-lp" or "pp4019".

In http://www.findmail.com/list/ipp/mg771994797.html, Robert Herriot wrote:

> Randy suggests that the value of job-uri/printer-uri could differ from the request-uri on the HTTP Request-Line, but the model has no such concept. So unless there are strong arguments to the contrary, the protocol document will state that the request-uri has the same value as the printer-uri/job-uri in the operation.

Then Randy agreed, and the thread ended.

---

From: Jay Martin <[email-masked]>
Date: Wed, 03 Jun 1998 14:34:41 -0400

I've changed the thread name to improve tracking in the IPP
Hypermail archives for this topic.

Carl Kugler wrote:
> Jay Martin wrote:
> > Randy suggests that the value of job-uri/printer-uri could differ from
> > the request-uri on the HTTP Request-Line, but the model has no such concept.
> > So unless there are strong arguments to the contrary, the protocol document
> > will state that the request-uri has the same value as the printer-uri/job-uri
> > in the operation.
> 

Ok, since no one followed up after that, I guess Herriot's
statement stands.  No problem.

But what happens if the two URIs *do* differ?
I think we need some language in the document
so developers can do the right thing.

All of the recent talk about proxies rewriting
the request-uri has me concerned whether we will
indeed see quite a few cases in which the two
URIs are not the same (and then what?).

	...jay

---

From: Robert Herriot <[email-masked]>
Date: Wed, 03 Jun 1998 13:54:05 -0700

I agree with what Carl stated below.

One way of implementing IPP is to have requests for all printers go to a 
single servlet which mulitplexes several printers. The servlet determines 
the printer by querying the URL.

Another way of implementing IPP (which I haven't tried) is to have a 
separate Servlet for each printer (e.g. /servlet/IPPServletFoo and 
/servlet/IPPServletBar).  I think that the first solution is best.

In any case the URL in the HTTP request line is the easiest place for a 
server to determine the target printer and the printer-uri in the 
application/ipp is at most checked for consistency.

Bob Herriot

At 11:14 AM 6/3/98 , Carl Kugler wrote:
>If I understand what you're saying, this works fine today, with the existing
model.  For example, in our implemenation, these two Request-URIs sent to Host
carlk:
>both cause the web server on carlk to invoke servlet IPPServlet.  IPPServlet
uses the path info from the Request-URI to determine if the target output
device is "vega-lp" or "pp4019".
>> Randy suggests that the value of job-uri/printer-uri could differ from the
request-uri on the HTTP Request-Line, but the model has no such concept. So
unless there are strong arguments to the contrary, the protocol document will
state that the request-uri has the same value as the printer-uri/job-uri in the
operation.