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
>
>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
>>
>>
>>
>
>
>
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: manros@cp10.es.xerox.com