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:
>>
>> 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@us.ibm.com]
>> Sent: Wednesday, June 03, 1998 11:21 AM
>> To: ipp@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@underscore.com>
>> > > To: Randy Turner <rturner@sharplabs.com>
>> > > Cc: ipp@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@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 --
>> > >
>> ----------------------------------------------------------------------
>> >
>> >
>>
>>
>
--=====================_7346073==_.ALT
Content-Type: text/html; charset="us-ascii"
In my opinion the printer-uri inside application/ipp is of
no use for demux
--=====================_7346073==_.ALT--
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:
>>
>> 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?
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> type of
>>
>> on its own,
>>
>> within the
>>
>> entirely
>>
>> independent ).
>>
>>
>>
>>
>>
>>
>>
>> read IPP attributes?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> maintain
>>
>> some type of
>>
>>
>> protocol.
>>
>>
>> front-end,
>>
>> protocol
>>
>> implementations.
>>
>>
>> PDU,
>>
>> similar
>>
>> we might
>>
>>
>>
>>
>>
>>
>>
>>
----------------------------------------------------------------------
>>
>> --
>>
>> --
>>
>> --
>>
>>
http://www.underscore.com
--
>>
>>
----------------------------------------------------------------------
>>
>>
>>
>>
>