Subject: RE: RE: IPP> Identifying jobs in requests

From: "Turner, Randy" <[email-masked]>
Date: Wed, 3 Jun 1998 14:59:32 -0700

The demux wasn't my idea, I was just clarifying what I thought Jay was
suggesting...however, the URI itself is self-demux'ing. As you move left
to right parsing a URI, you are basically performing a kind of
demultiplexing, with one or more layers each handling a portion of the
URI string. Its not hard to envision any number of demux'ing techniques
using URIs in both HTTP and IPP headers.

Sorry I missed the carnage at the teleconference ;)...hope to see the
minutes.

Randy

	-----Original Message-----
	From:	Carl Kugler [SMTP:[email-masked]]
	Sent:	Wednesday, June 03, 1998 2:50 PM
	To:	[email-masked]
	Subject:	Re: RE: IPP> Identifying jobs in requests

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

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

	> 
	> 	-----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: Jay Martin <[email-masked]>
Date: Wed, 03 Jun 1998 18:25:00 -0400

Yes, this is what I was envisioning.  Thanks, Randy.

	...jay