> -----Original Message-----
> From: Turner, Randy [SMTP:rturner@sharplabs.com]
> Sent: Monday, June 01, 1998 3:49 PM
> To: Paul Moore; 'Scott Isaacson'; kugler@us.ibm.com
> Cc: ipp@pwg.org
> Subject: RE: IPP> URLs within IPP operations
>
>
> I think its implementation-dependent how it derives "output URIs". I
> don't think they are "by necessity" tightly coupled.
>
> 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
> >