IPP Mail Archive: RE: RE: RE: RE: IPP> Identifying jobs in requests

IPP Mail Archive: RE: RE: RE: RE: IPP> Identifying jobs in requests

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

Randy Turner (rturner@sharplabs.com)
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