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