>> -----Original Message-----
> From: Tom Hastings <hastings at cp10.es.xerox.com>
> To: ipp at pwg.org <ipp at pwg.org>
> Date: Wednesday, June 10, 1998 9:09 AM
> Subject: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute
> targets
>>> >In case we do get time to:
> >
> >At 07:43 06/10/1998 PDT, Carl-Uno Manros wrote:
> >>If we end up with time on our hands, we can always devote it to debate
> >>if we keep URLs in application/ipp :-)
> I'm not sure how/whether removing these "printer-uri" and "job-uri"
> >operation attribute targets from the application/ipp MIME type requests
> >affects client communication with proxies in which the http URIs get
> >changed from absolute to relative in the HTTP header. But it seems like
> >there might be no problem, since HTTP request headers are the province
> >of the transport, which includes proxies and they can do what ever they
> >like, including changing absolute URIs to relative URIs. Such changes
> >only affect getting the message to the recipient. The recipient only
> >looks at the application/ipp operation attributes to know which printer
> >or job is really the intended object instance.
>>> I was addressing this scenario in my previous e-mail today,
> The job-id will be an operation attribute, so job addressing within a
> printer should be
> taken care of.
> To address the printer, we would have to decide on one of two rules :
> 1) * the entity processing the request is representing only one printer and
> no additional attribute is necessary
> 2) * or as Tom mentions above, printer-name should assist in addressing the
> target
>> 2) seems more flexible.
>> Peter
>
With 2, were're back to having an IPP Server in the model. This Server receives a request, reads the application/ipp content, and forwards the request to the Printer specified by the "printer-name" IPP attribute. I'm not saying this is a bad thing, but I thought this decision was already made back in March of 1997.
>>>>