IPP Mail Archive: RE: IPP> URLs within IPP operations

RE: IPP> URLs within IPP operations

Carl Kugler (kugler@us.ibm.com)
Mon, 01 Jun 1998 17:46:36 -0600

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: Carl-Uno Manros: "IPP> Re: Fw: compression"
Previous message: Turner, Randy: "RE: IPP> URLs within IPP operations"

This is a multi-part message in MIME format.
--------------9233C429104D40AEF3E2F6F9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> You forget one thing, the IPP recipient must generate and give out addresses
> for new objects (Job-URI). it must therefore know its place in the
> addressing scheme of he underlying transport.
>
But it doesn't necessarily have to get that knowledge from the request
message.

http://www.pwg.org/hypermail/ipp/0541.html

--------------9233C429104D40AEF3E2F6F9
Content-Type: text/html; charset=us-ascii; name="0541.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="0541.html"
Content-Base: "http://www.pwg.org/hypermail/ipp/0541.
html"

<title>IPP Mail Archive: RE: IPP> URLs within IPP operations</title>
<h1>RE: IPP> URLs within IPP operations</h1>
Paul Moore (paulmo@microsoft.com) 
Mon, 1 Jun 1998 15:41:14 -0700 

<ul>
<li> Messages sorted by: <a href="date.html#541">[ date ]</a><a href="index.html#541">[ thread ]</a><a href="subject.html#541">[ subject ]</a><a href="author.html#541">[ author ]</a>

<li> Next message: <a href="0542.html">Turner, Randy: "RE: IPP> URLs within IPP operations"</a>
<li> Previous message: <a href="0540.html">Scott Isaacson: "IPP> URLs within IPP operations"</a>

</ul>

You forget one thing, the IPP recipient must generate and give out addresses 
for new objects (Job-URI). it must therefore know its place in the 
addressing scheme of he underlying transport. 

> -----Original Message----- 
> From: Scott Isaacson [SMTP:SISAACSON@novell.com] 
> Sent: Monday, June 01, 1998 2:41 PM 
> To: kugler@us.ibm.com 
> Cc: ipp@pwg.org 
> Subject: IPP> URLs within IPP operations 
> 
> I changed the subject line. 
> 
> We do so seem to be confusing addressing vs payload. Addressing should 
> be independent of payload. With URLs embedded within IPP operations, we 
> are mixing addressing and payload. 
> 
> Since we chose HTTP for IPP we should rely on it for all of our addressing 
> and routing, so we all seem to agree that for High Level Scenario 1 the 
> URLs in the IPP operation are as you say "meaningless" In fact they were 
> never there until late in the game and were added "just in case there is a 
> mapping to some other transport other than HTTP" When that happens, no 
> longer will IPP objects be identified with "http:" URLs, but some other 
> type of addressing/naming scheme. In that case, we ought to make sure 
> that there is enough info in that URL (URI, URN whatever) to get to the 
> IPP printer object and not worry so much about including in the operation 
> itself. 
> 
> I am becoming more and more convinced that it as a bad idea to put the 
> URLs in there at all. We should rely on the addressing in the layer upon 
> which IPP is mapped to solve the problem. I think we all agree that the 
> URLs within IPP operations are not needed for HTTP. Then we try to guess 
> if they are needed for other mappings? You suggest in scenarios 2 and 3 
> that the embedded info might be needed for identifying a resource 
> "underneath" or "behind" the IPP object. However, I wonder if this is 
> true. The only addressable IPP objects are Printers and Jobs. Once a 
> Printer gets a Printer request it should handle it as if it were supposed 
> to get that request, and not have to check "is this really for me" That 
> should be handled at a different layer. Same for a Job object. The HTTP 
> level URL is all that is needed to route to the correct Job or Printer. 
> So to me, scenarios 2 and 3 either collapse into one called "other" or 
> expand into possibly many unexplored options. Let's not solve that 
> problem now. 
> 
> Consider this example: 
> 
> If I get a postal service letter in my mail box, I open the evenlope and 
> read it assuming it is for me. If I am at home, the address on the 
> envelope is perhaps much simpler than if I am at work. If I am at home, 
> it probably just has my name and street address. If I am at work, it 
> probably has a street address, company name, mail/stop, building number, 
> and my name. NOTE: **** In either case, the letter in the envelope can 
> be exactly the same. **** 
> 
> What if the letter happens to have the address that was used at the top of 
> the page? I usually just ignore it and read the letter, I don't care how 
> it got to me. What if the letter happens to have the wrong address? ( 
> the proxy case), I still ignore it and read the letter - the letter got to 
> me, it must be for me. In the proxy case, who cares what the address 
> printed at the top of the page is? 
> 
> Summary, why do we have a solution waiting for a problem that is causing a 
> different problem? 
> 
> Scott 
> 
> >>> Carl Kugler <kugler@us.ibm.com> 06/01 2:53 PM >>> 
> > Scott - 
> > 
> > Maybe we need to step back and define the requirements before we nail 
> down the 
> > specification. 
> > 
> > Consider some high-level scenarios: 
> > 
> > 1) IPP over HTTP: the simplest approach here, I think, would be to 
> let the 
> > Request-URI take precedence. In this scenario, the IPP embedded target 
> URI 
> > (printer-uri, job-uri, etc.) is essentially meaningless, since any 
> entity in a 
> > position to read it has already been identified as the resource 
> designated to 
> > receive this request by the HTTP Request-URI. But this scenario 
> (IPP/HTTP) 
> > isn't the reason that the target URI was added to the IPP protocol. In 
> fact, 
> > we know that IPP/HTTP can work without IPP embedded target URIs. 
> > 
> > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario, 
> any 
> > entity in a position to read the IPP embedded target URI attributes is 
> > presumably an IPP Object. Therefore, the addressing of the request to 
> the 
> > appropriate IPP Object is the responsibility of the transport layer 
> (e.g., by 
> > email address). The IPP embedded target URI is used to identify a 
> resource 
> > relative to the receiving IPP Object (e.g., a Job within the context of 
> a 
> > Printer). So it is a Relative URI. 
> > 
> > 3) IPP Router: Apparently there are other scenarios involving some 
> kind of 
> > IPP router capable of parsing an IPP request and retransmitting it to 
> the 
> > resource identified by the embedded target URI. I haven't seen any of 
> these 
> > re-route scenarios, but I think that only by working through some of 
> them will 
> > we come to understand what the real requirements are. Maybe we need a 
> new IPP 
> > embedded target URI attribute, of Absolute form, to identifiy the 
> destination 
> > IPP Object in a router scenario. 
> > Scenario 1) could be modified to fit the general case of 2). Then the 
> HTTP 
> > Request-URI would identify a Printer relative to a host, and the IPP 
> embedded 
> > target URI would identify a resource relative to that Printer. 
> > 
> > - Carl 
> 


<ul>

<li> Next message: <a href="0542.html">Turner, Randy: "RE: IPP> URLs within IPP operations"</a>
<li> Previous message: <a href="0540.html">Scott Isaacson: "IPP> URLs within IPP operations"</a>

</ul>

--------------9233C429104D40AEF3E2F6F9--

Next message: Carl-Uno Manros: "IPP> Re: Fw: compression"
Previous message: Turner, Randy: "RE: IPP> URLs within IPP operations"