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

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

Tom Hastings hastings at cp10.es.xerox.com
Wed Jun 10 12:50:21 EDT 1998


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



More information about the Ipp mailing list