IPP> Identifying jobs in requests

[Jay Martin]

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


	...jay




Turner, Randy wrote:
> 
> 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:kugler at us.ibm.com]
>         Sent:   Wednesday, June 03, 1998 2:50 PM
>         To:     ipp at pwg.org
>         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:kugler at us.ibm.com]
>         >       Sent:   Wednesday, June 03, 1998 11:21 AM
>         >       To:     ipp at pwg.org
>         >       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 <jkm at underscore.com>
>         >       > > To: Randy Turner <rturner at sharplabs.com>
>         >       > > Cc: ipp at pwg.org
>         >       > > 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:
> jkm at underscore.com
>         > --
>         >       > > --  Underscore, Inc.        |  Voice:   (603)
> 889-7000
>         > --
>         >       > > --  41C Sagamore Park Road  |  Fax:     (603)
> 889-2699
>         > --
>         >       > > --  Hudson, NH 03051-4915   |  Web:
>         > http://www.underscore.com   --
>         >       > >
>         >
> ----------------------------------------------------------------------
>         >       >
>         >       >
>         >
>         >