--=====================_2785945==_.ALT
Content-Type: text/plain; charset="us-ascii"
I agree with what Carl stated below.
One way of implementing IPP is to have requests for all printers go to a
single servlet which mulitplexes several printers. The servlet determines
the printer by querying the URL.
Another way of implementing IPP (which I haven't tried) is to have a
separate Servlet for each printer (e.g. /servlet/IPPServletFoo and
/servlet/IPPServletBar). I think that the first solution is best.
In any case the URL in the HTTP request line is the easiest place for a
server to determine the target printer and the printer-uri in the
application/ipp is at most checked for consistency.
Bob Herriot
At 11:14 AM 6/3/98 , Carl Kugler wrote:
>JK Martin wrote:
>> Carl Kugler wrote:
>>>> > At one time, people were proposing some kind of dispatching or routing IPP
>> > Object that would receive IPP requests and route them based on the
embedded
>> > "printer-uri".
>>>> I was one of those people suggesting demultiplexing/dispatching,
>> but only within an HTTP server environment. As such, the server-
>> side component (CGI script, servlet, etc) would use the HTTP
>> header component to discriminate the real target.
>>>If I understand what you're saying, this works fine today, with the existing
model. For example, in our implemenation, these two Request-URIs sent to Host
carlk:
>> /servlet/IPPServlet/vega-lp
> /servlet/IPPServlet/pp4019
>>both cause the web server on carlk to invoke servlet IPPServlet. IPPServlet
uses the path info from the Request-URI to determine if the target output
device is "vega-lp" or "pp4019".
>>>>> > But the final decision was that the HTTP Request-URI and the embedded
>> > "printer-uri" MUST be the SAME. Therefore the IPP Object that receives
>> > the request must be the target.
>>>> Did we actually come to a final decision? I didn't read that we had.
>> (Maybe I'm missing a message or two on this subject?)
>>>In http://www.findmail.com/list/ipp/mg771994797.html, Robert Herriot wrote:
>>> Randy suggests that the value of job-uri/printer-uri could differ from the
request-uri on the HTTP Request-Line, but the model has no such concept. So
unless there are strong arguments to the contrary, the protocol document will
state that the request-uri has the same value as the printer-uri/job-uri in the
operation.
>>Then Randy agreed, and the thread ended.
>>>>>>> > There could be a problem if a proxy rewrites the Request-URI in any way.
>>>> Yeah, this worries me, too. We definitely need some serious
>> implementation experience to better understand the ramifications
>> of this situation.
>>>> ...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 --
>> ----------------------------------------------------------------------
>>>>>
--=====================_2785945==_.ALT
Content-Type: text/html; charset="us-ascii"
<html>
<font size=3>I agree with what Carl stated below.
One way of implementing IPP is to have requests for all printers go to a
single servlet which mulitplexes several printers. The servlet determines
the printer by querying the URL.
Another way of implementing IPP (which I haven't tried) is to have a
separate Servlet for each printer (e.g. /servlet/IPPServletFoo and
/servlet/IPPServletBar). I think that the first solution is
best.
In any case the URL in the HTTP request line is the easiest place for a
server to determine the target printer and the printer-uri in the
application/ipp is at most checked for consistency.
Bob Herriot
At 11:14 AM 6/3/98 , Carl Kugler wrote:
>JK Martin
wrote:
>> Carl Kugler wrote:
>>>> > At one time, people were proposing some kind of dispatching
or routing IPP
>> > Object that would receive IPP requests and route them based
on the embedded
>> > "printer-uri".
>>>> I was one of those people suggesting
demultiplexing/dispatching,
>> but only within an HTTP server environment. As such, the
server-
>> side component (CGI script, servlet, etc) would use the
HTTP
>> header component to discriminate the real target.
>>>If I understand what you're saying, this works fine today, with the
existing model. For example, in our implemenation, these two
Request-URIs sent to Host carlk:
>> /servlet/IPPServlet/vega-lp
> /servlet/IPPServlet/pp4019
>>both cause the web server on carlk to invoke servlet
IPPServlet. IPPServlet uses the path info from the Request-URI to
determine if the target output device is "vega-lp" or
"pp4019".
>>>>> > But the final decision was that the HTTP Request-URI and
the embedded
>> > "printer-uri" MUST be the SAME. Therefore the IPP
Object that receives
>> > the request must be the target.
>>>> Did we actually come to a final decision? I didn't read
that we had.
>> (Maybe I'm missing a message or two on this subject?)
>>>In
<a href="http://www.findmail.com/list/ipp/mg771994797.html" eudora="autourl"><font size=3>http://www.findmail.com/list/ipp/mg771994797.html</a><font size=3>,
Robert Herriot wrote:
>>> Randy suggests that the value of job-uri/printer-uri could
differ from the request-uri on the HTTP Request-Line, but the model has
no such concept. So unless there are strong arguments to the contrary,
the protocol document will state that the request-uri has the same value
as the printer-uri/job-uri in the operation.
>>Then Randy agreed, and the thread ended.
>>>>>>> > There could be a problem if a proxy rewrites the
Request-URI in any way.
>>>> Yeah, this worries me, too. We definitely need some
serious
>> implementation experience to better understand the
ramifications
>> of this situation.
>>>> <x-tab> </x-tab>...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:
<a href="http://www.underscore.com/" eudora="autourl"><font size=3>http://www.underscore.com</a><font size=3>
--
>>----------------------------------------------------------------------
>>>>> </font>
</html>
--=====================_2785945==_.ALT--