Subject: RE: IPP> Identifying jobs in requests

From: "Peter Michalek" <[email-masked]>
Date: Wed, 10 Jun 1998 09:18:54 -0700

>From Carl Kugler's response to my message from last week, I realized that
having
urls denoting jobs without requiring an extra cgi to serve them is trivial:
http://ipp.cgi?jobId=2 (as opposed to http://ipp.cgi/2).

It brings a question whether job is not an "artificial" target, since
usually, a request
to cancel a job or get job attributes will be served by a cgi representing
the printer where
the job was created.

Whether the target (job-uri or printer-uri or printer-uri + job-id) is taken
out of IPP layer or not,
it would be more simple to have just one possible kind of target:
printer-uri, where job-id would
be considered an operation attribute.

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:[email-masked], where specification of arguments is not allowed
(according to rfc1738).

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.

Peter

-----Original Message-----
From: Carl Kugler <[email-masked]>
To: [email-masked] <[email-masked]>
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

---

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

> be considered an operation attribute.

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.

> mailto:[email-masked], where specification of arguments is not allowed

The current model lets you do this with job-id.

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