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:
"printer-name"
and operations for jobs would have both:
"printer-name"
"job-id"
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.
Tom
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 15.3.4.3. 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
eliminating
>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
making
>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
>target.
>>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.
>>Tom
>>>