IPP> Identifying jobs in requests

IPP> Identifying jobs in requests

Robert Herriot robert.herriot at Eng.Sun.COM
Wed Jun 3 16:54:05 EDT 1998


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



More information about the Ipp mailing list