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@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"
I agree with what Carl stated below.
--=====================_2785945==_.ALT--
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.
>>
>>
>>
>>
----------------------------------------------------------------------
>> -- 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
--
>>
----------------------------------------------------------------------
>>
>>
>