Subject: IPP> URLs within IPP operations

From: "Scott Isaacson" <[email-masked]>
Date: Mon, 01 Jun 1998 15:40:42 -0600

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

---

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

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
> 
> 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?
>

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 1 Jun 1998 15:49:00 -0700

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.

	> Summary, why do we have a solution waiting for a problem that
is causing a
	> different problem?
	> > Maybe we need to step back and define the requirements
before we nail
	> down the
	> > 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,
	> > 2) IPP over non-HTTP transport (e.g., IPP over SMTP):  In
this scenario,
	> any
	> > 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
	> > 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
	> > 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

---

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.

> From:	Turner, Randy [SMTP:[email-masked]]
> Sent:	Monday, June 01, 1998 3:49 PM
> To:	Paul Moore; 'Scott Isaacson'; [email-masked]
> Cc:	[email-masked]

---

From: "Turner, Randy" <[email-masked]>
Date: Mon, 1 Jun 1998 16:23:44 -0700

That's true, but I was questioning whether or not it needed to know "its
place" in the transport domain. And also, an IPP implementation may
"ask" the transport layer to map a new URI to use, or to translate an
IPP object name into a suitable transport URI. I agree that there is a
linkage, but there are a lot of ways to make this linkage more loosely
coupled.

Randy

	-----Original Message-----
	From:	Paul Moore [SMTP:[email-masked]]
	Sent:	Monday, June 01, 1998 3:54 PM
	To:	'Turner, Randy'; 'Scott Isaacson'; [email-masked]
	Cc:	[email-masked]
	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.

	> 	> be independent of payload.  With URLs embedded within
IPP
	> operations, we
	> 	> 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
	> 	> 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
	> 	> 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
	> 	> > we know that IPP/HTTP can work without IPP embedded
target
	> URIs.
	> 	> > entity in a position to read the IPP embedded target
URI
	> attributes is
	> 	> > target URI would identify a resource relative to
that
	> Printer.

---

From: Carl Kugler <[email-masked]>
Date: Mon, 01 Jun 1998 17:46:36 -0600

> addressing scheme of he underlying transport.
But it doesn't necessarily have to get that knowledge from the request
message.

http://www.pwg.org/hypermail/ipp/0541.html
RE: IPP> URLs within IPP operations

Paul Moore ([email-masked])

Mon, 1 Jun 1998 15:41:14 -0700

Messages sorted by: [ date ][ thread ][ subject ][ author ]

Next message: Turner, Randy: "RE: IPP> URLs within IPP operations"

Previous message: Scott Isaacson: "IPP> URLs within IPP operations"

> Summary, why do we have a solution waiting for a problem that is causing a

> > Maybe we need to step back and define the requirements before we nail

> > 1) IPP over HTTP: the simplest approach here, I think, would be to

> > Request-URI take precedence. In this scenario, the IPP embedded target

> > (printer-uri, job-uri, etc.) is essentially meaningless, since any

> > position to read it has already been identified as the resource

> > receive this request by the HTTP Request-URI. But this scenario

> > isn't the reason that the target URI was added to the IPP protocol. In

> > 2) IPP over non-HTTP transport (e.g., IPP over SMTP): In this scenario,

> > presumably an IPP Object. Therefore, the addressing of the request to

> > appropriate IPP Object is the responsibility of the transport layer

> > email address). The IPP embedded target URI is used to identify a

> > relative to the receiving IPP Object (e.g., a Job within the context of

> > 3) IPP Router: Apparently there are other scenarios involving some

> > IPP router capable of parsing an IPP request and retransmitting it to

> > resource identified by the embedded target URI. I haven't seen any of

> > re-route scenarios, but I think that only by working through some of

> > we come to understand what the real requirements are. Maybe we need a

> > embedded target URI attribute, of Absolute form, to identifiy the

> > Scenario 1) could be modified to fit the general case of 2). Then the

> > Request-URI would identify a Printer relative to a host, and the IPP

Next message: Turner, Randy: "RE: IPP> URLs within IPP operations"

Previous message: Scott Isaacson: "IPP> URLs within IPP operations"