Subject: RE: RE: RE: RE: IPP> Identifying jobs in requests

From: Randy Turner <[email-masked]>
Date: Tue, 09 Jun 1998 20:13:26 -0700

At 06:13 PM 6/9/98 -0700, Paul Moore wrote:
>	I think that originally "printer-uri" was going to be a "virtual"
>attribute,
>	as you thought.  But later (last Fall?) we changed the Model and
>Protocol 
>	document so that the "printer-uri" attribute was required to be
>supplied 
>	by the client and include in the operation attribute group in the
>IPP packet
>	(which is defined by the application/ipp MIME type).  The thinking
>	was that we wanted the IPP packet and MIME type to be independent
>	of the transport.  So that we could send IPP over any transport,
>such
>	as SMTP or FTP, for examples.
>
>OK. So we are saying that the URIs IN the protocol are NOT to be used as
>transport adresses. They are in effect opaque cookies that the client must
>do nothing with except send them back to the printer. They are really
>job-name and printer-name. Either that or we explicitly state that these
>fields only make sense in an HTTP-enabled environment (they cannot therefore
>be mandatory for a universal protocol).
> 

No, the URI is actually a URL that is to be interpreted according to
"standard" rules for interpreting URLs (not sure if there is a "formal"
standard for this). These resource identifiers are not opaque to clients.
This does not mean that we are NOT transport independent, it only means we
are identifying resources that must be accessed via the transport (scheme)
that is specified in the URL. Since we have "modeled" IPP using URI/URL
resource identifiers, all transports used by IPP should have a URL scheme
defined. I don't think this is a negative constraint BTW. I consider our
selection of URL strings as resource identifiers one of the more compact
and powerful capabilities of the model (and protocol).

The only problem we have identified so far is what happens when "http" is
used as the scheme for IPP resources, and between the client and the
resource, there is one or more proxies involved. Note, that this is a
problem only in the case of HTTP as the transport.

For reference purposes, can someone restate the problem (actually the
scenario) with proxies that we are trying to address. I think some
solutions that have recently hit the list are bordering on "throwing the
baby out with the bath water". Any concrete scenario examples would be much
appreciated, as I am still on the learning curve with HTTP proxy behavior.

Thanks

Randy

---

From: "Carl Kugler" <[email-masked]>
Date: 10 Jun 1998 04:10:01 -0000

> problem only in the case of HTTP as the transport.
Another problem is that PRO requires the HTTP Request-URI and the target URI (embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1 clients aren't allowed to send absolute Request-URIs unless they're talking to a proxy.  And proxies rewrite the Request-URI.

---

From: Randy Turner <[email-masked]>
Date: Tue, 09 Jun 1998 22:27:03 -0700

Carl,

Concerning your earlier message about relative URIs...

I noticed in RFC 2068 the following text:

 To allow for transition to absoluteURIs in all requests in future
   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
   form in requests, even though HTTP/1.1 clients will only generate
   them in requests to proxies.

Is there any way we could use this to our advantage?

Randy

At 04:10 AM 6/10/98 +0000, Carl Kugler wrote:
>Another problem is that PRO requires the HTTP Request-URI and the target URI
(embedded in the application/ipp) to be the same (absolute) URIs, but HTTP/1.1
clients aren't allowed to send absolute Request-URIs unless they're talking to
a proxy.  And proxies rewrite the Request-URI.

---

From: "Carl Kugler" <[email-masked]>
Date: 10 Jun 1998 21:43:32 -0000

> Is there any way we could use this to our advantage?

No, I don't think so.  Even though servers MUST accept absoluteURI form Request-URIs, HTTP/1.1 clients MUST transmit abs_path Request-URIs when talking to an origin server:

"The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI...

I think you'll find that existing web servers will ACCEPT an absoluteURI Request-URI in an HTTP/1.1 request, but they will try to proxy that request to themselves.