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

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

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"

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

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