Subject: RE: IPP> URLs within IPP operations

From: Paul Moore <[email-masked]>
Date: Mon, 1 Jun 1998 15:54:07 -0700

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:[email-masked]]
> Sent:	Monday, June 01, 1998 3:49 PM
> To:	Paul Moore; 'Scott Isaacson'; [email-masked]
> Cc:	[email-masked]
> 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:[email-masked]]
> 	Sent:	Monday, June 01, 1998 3:41 PM
> 	To:	'Scott Isaacson'; [email-masked]
> 	Cc:	[email-masked]
> 	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:[email-masked]]
> 	> Sent:	Monday, June 01, 1998 2:41 PM
> 	> To:	[email-masked]
> 	> Cc:	[email-masked]
> 	> 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 <[email-masked]> 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
> 	>