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

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

Carl Kugler (kugler@us.ibm.com)
10 Jun 1998 04:10:01 -0000

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

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