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