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 -
>=20
> Maybe we need to step back and define the requirements before we nail =
down the
> specification.
>=20
> Consider some high-level scenarios:
>=20
> 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.
>=20
> 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.
>=20
> 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