I agree. But, having job-uri does permit more flexibility in the implementation, for load-balancing, etc. For example, a Printer could hand off a Job to a different Printer and return a job-uri that actually addresses the new Printer.
>
> If the target is taken out of IPP layer and will be used only in the
> transport layer, not having job-uri
> as a possible target would probably make addressing possible for other
> transports, e.g.
> mailto:ipp@printingorg.com, where specification of arguments is not allowed
> (according to rfc1738).
The current model lets you do this with job-id.
>
>
> Regarding the message below, I don't understand:
> >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.
>
> In what respect are HTTP/1.1 clients not allowed to send absolute
> Request-URIs? I didn't see a mention of that in RFC2068.
>
Here's the quote:
"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...
abs_path is a form of Relative URI (as opposed to Absoluter URI).
If you send an absolute Request-URI to a web server it will probably try to proxy the request, which is not what you want if you're talking to the "origin" server.
>
> Peter
>
>
> -----Original Message-----
> From: Carl Kugler <kugler@us.ibm.com>
> To: ipp@pwg.org <ipp@pwg.org>
> Date: Tuesday, June 09, 1998 9:18 PM
> Subject: Re: RE: RE: RE: RE: IPP> Identifying jobs in requests
>
>
> >> 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
> >>
> >>
> >>
> >>
> >
> >
>
>
>