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