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