Subject: Re: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets

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

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

---

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

> 2) * or as Tom mentions above, printer-name should assist in addressing the

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.