Randy
-----Original Message-----
From: Paul Moore [SMTP:paulmo@microsoft.com]
Sent: Monday, June 01, 1998 3:41 PM
To: 'Scott Isaacson'; kugler@us.ibm.com
Cc: ipp@pwg.org
Subject: RE: IPP> URLs within IPP operations
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
>