Subject: IPP> MOD&PRO - Removing printer-uri & job-uri operation attribute targets

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Jun 1998 08:49:12 PDT

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

---

From: Tom Hastings <[email-masked]>
Date: 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:
  "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

---

From: Tom Hastings <[email-masked]>
Date: Wed, 10 Jun 1998 09:50:21 PDT

Tom

---

From: "Carl Kugler" <[email-masked]>
Date: 10 Jun 1998 22:40:51 -0000

Can't we depend on the transport to get the request all the way to the appropriate Printer?  For example, couldn't each Printer on a host have a unique email address, e.g.  [email-masked], [email-masked], etc.?  For FTP, couldn't each printer have a unique directory?  TCP/IP a unique port? HTTP a unique abs_path segment? Why do we need the extra level of indirection provided by "printer-name"?

---

From: Carl-Uno Manros <[email-masked]>
Date: Wed, 10 Jun 1998 16:12:44 PDT

At 03:40 PM 6/10/98 PDT, Carl Kugler wrote:
>
>Can't we depend on the transport to get the request all the way to the
appropriate Printer?  For example, couldn't each Printer on a host have a
unique email address, e.g.  [email-masked], [email-masked], etc.?
For FTP, couldn't each printer have a unique directory?  TCP/IP a unique
port? HTTP a unique abs_path segment? Why do we need the extra level of
indirection provided by "printer-name"?

Carl,

I agree with you. I do not think that we need another level of addressing;
the URI can be extended to any level within a print server to address
individual printers, if needed.

Carl-Uno
  
>> or job is really the intended object instance.
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: [email-masked]