IPP Mail Archive: Re: IPP> MOD&PRO - Removing printer-uri & job-uri operation

IPP Mail Archive: Re: IPP> MOD&PRO - Removing printer-uri & job-uri operation

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

Tom Hastings (hastings@cp10.es.xerox.com)
Wed, 10 Jun 1998 09:50:21 PDT

A simpler way of understanding this proposal is:

1. We remove the choice of supplying a "job-uri" operation attribute target
in application/ipp requests in operations on jobs (Send-Document, Send-URI,
Cancel-Job, Get-Job-Attributes).

2. We replace the "printer-uri" operation attribute target in application/ipp
requests in operations on jobs and printers with the "printer-name"
Printer attribute. So operation requests for printers would have:
and operations for jobs would have both:
in that order (after "attributes-charset" and "attribute-natural-language".

Now that we have made "printer-name" MANDATORY in a directory entry,
the client knows what "printer-name" to put into every request.


At 08:49 06/10/1998 PDT, Tom Hastings wrote:
>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 :-)
>There seems to be a growing consensus that we should remove the (redundant)
>printer-uri and job-uri operation attribute targets from the operation
>attributes group in IPP requests. This would be a change to sections
>3.1.3 (in 1/16/98 version which was renumberd 3.1.4 in 5/29/98 version)
>and section Then we would be depending on the transport
>to get the request to the right place. There would be no other changes
>to the application/ipp part of requests and no changes to responses at all.
>For operations on jobs, the only form would be the "job-id" (integer) in the
>Operation attribute group in the request, so this change would be
>one of the two repsentations for operations on jobs (a good simplification).
>Recall that the reason that we added the printer-uri and job-uri targets
>to the operation attribute group in requests was in the "name of
>transport independence" (a good thing). But what do we really mean by
>application/ipp "transport independent"? One could argue that by removing
>the "printer-uri" and "job-uri" targets operation attributes that we are
>making the application/ipp MIME media type more transport independent
>and we are depending on the transport to get the request to the intended
>To understand better what transport-independence really means, imagine
>that we are trying to sent IPP requests over other transports, such as
>SMTP, FTP, and TCP/IP. We would depend on those transports to get the
>request to some destination that knows what to do with the request.
>For requests on jobs (Send-Document, Send-URI, Cancel-Job,
>Get-Job-Attributes), the "job-id" in the application/ipp tells the
>recipient which job the operations is upon. We don't have a similar
>operation attribute for operations on printers (Print-Job, Print-URI,
>Validate-Job, Create-Job, Get-Printer-Attributes, Get-Jobs).
>We could add the existing "printer-name" Printer attribute as an
>Operation attribute for operations on Printers. Then the
>transport-independent recipient (SMTP, FTP, TCP/IP, HTTP) of any
>IPP request knows which Printer or Job object the operation is intended
>by simply looking at the "printer-name" or "job-id" operation attribute
>and can ignore any transport request URI.
>Extending Scott's home mail delivery analogy, the U.S. Postal service
>is a transport that delivers to your house any mail addressed to your house
>without looking at the name of the addressee. The recipient (familiy) then
>looks at the name and knows for whom the mail is really for (including
>someone who no longer lives there - return to sender).
>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.