Subject: RE: IPP> Identifying jobs in requests

From: "Turner, Randy" <[email-masked]>
Date: Wed, 3 Jun 1998 11:50:42 -0700

I think Jay was talking about a lower-layer demux than what you are
talking about. The kind of demux that might be performed by a
CGI/NSAPI/ISAPI layer, or equivalent...prior to passing the data to a
core IPP processing component.

Randy

	-----Original Message-----
	From:	Carl Kugler [SMTP:[email-masked]]
	Sent:	Wednesday, June 03, 1998 11:21 AM
	To:	[email-masked]
	Subject:	Re: IPP> Identifying jobs in requests

	> 
	> The demultiplexing front-end is not IPP, and is therefore some
type of
	> "transport-helper". While the IPP protocol document must stand
on its own,
	> independent of any such transport, and therefore identifiers
within the
	> protocol would still be mandatory ( Of course, my argument is
entirely
	> based upon the WG's decision that IPP must be transport
independent ).
	> Randy

	Randy-

	If the demultiplexing front-end is not IPP, how is it able to
read IPP attributes?

	- Carl
	> 
	> ----------
	> > From: Jay Martin <[email-masked]>
	> > To: Randy Turner <[email-masked]>
	> > Cc: [email-masked]
	> > Subject: Re: IPP> Identifying jobs in requests
	> > Date: Wednesday, June 03, 1998 9:32 AM
	> > 
	> > Randy Turner wrote:
	> > > 
	> > > 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.
	> > 
	> > Not necessarily.  Sure, in the case of a demultiplexing
front-end,
	> > it would be necessary to have the target embedded in the
protocol
	> > message, but not necessary for single-Printer
implementations.
	> > 
	> > I don't have a problem with embedding the target URI in the
PDU,
	> > but if we get into a big mess with regard to reconciling a
similar
	> > target in the outer/lower transport level (eg, HTTP), then
we might
	> > want to consider pulling out the embedded target URI.
	> > 
	> > It would be nice to hear from others on this topic.
	> > 
	> > 	...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 21:50:16 -0000

> core IPP processing component.

How does placing a URI denoting the target of an IPP request inside our protocol (as an IPP attribute) facilitate this kind of demux?

---

From: Robert Herriot <[email-masked]>
Date: Wed, 03 Jun 1998 15:10:06 -0700

In my opinion the printer-uri inside application/ipp is of no use for demux 
in an HTTP context. We knew it was redundant when we put it in.  The 
argument in favor of having it for HTTP was that a gateway would not have to 
alter the application/ipp data when passing it on.  

That assumption may be false if the client believed that the gateway is the 
printer and the gateway has to change the target printer as it passes the 
operation onward.  Furthermore, the application/ipp encoding doesn't handle 
chunking of document data, so a gateway might still have to do some 
additional conversion.

You may well be correct that the presence of a redundant printer-uri in the 
application/ipp data causes more problems than it solves.

Bob Herriot

At 02:50 PM 6/3/98 , Carl Kugler wrote:
>How does placing a URI denoting the target of an IPP request inside our
protocol (as an IPP attribute) facilitate this kind of demux?

---

From: "Carl Kugler" <[email-masked]>
Date: 3 Jun 1998 22:47:56 -0000

Bob Herriot wrote:
> in an HTTP context. We knew it was redundant when we put it in.  

I think the printer-uri inside application/ipp is of no use at all, unless we add another IPP Object to the model, call it a "Server", which demuxes requests by printer-uri IPP attribute.  And then, I think printer-uri targets in requests should be Relative URIs, meaningful in the context of the Server.

The original proposal just asked for a way to identify Jobs inside requests.  That makes sense for implementations that can only address Printers, not Jobs.  But any implementation or transport layer should be able to address to the granularity of Printers, or else you have to invent IPP Servers.

The "job-id" is effectively a relative identifier, meaningful only in the context of the containing Printer.  "job-uri" could be a Relative URI, too, when embedded in an IPP request addressed to a Printer.

The

---

From: "Carl Kugler" <[email-masked]>
Date: 3 Jun 1998 22:54:56 -0000

The