Randy
-----Original Message-----
From: Paul Moore [SMTP:paulmo@microsoft.com]
Sent: Monday, June 01, 1998 3:54 PM
To: 'Turner, Randy'; 'Scott Isaacson'; kugler@us.ibm.com
Cc: ipp@pwg.org
Subject: RE: IPP> URLs within IPP operations
Not so, the person that receives the 'output-URI' expects to be
able to give
it to the transport layer as a valid endpoint. The receiver may
not look at
the URI to obtain any meaning but it is assumed that the URI
makes sense to
the transport.
> -----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
> >