I read the action items below and it appears very close to our previous usage
model. Except below, this
version says the IPP server "SHOULD" accept "ipp:" URLs wherein I would think
this would be a "MUST",
since later on it mentions that this document does not discuss what a server
does with any other URL
scheme it sees.
(?)
Randy
At 06:41 PM 7/15/98 -0700, Robert Herriot wrote:
>> Action item from Robert Herriot and Tom Hastings:
>> The IPP working group reached an agreement with Keith Moore in this
> morning's teleconference. This document is our best understanding of the
> details of this agreement.
>> Summary:
>> The quick summary is that IPP should support a new scheme 'ipp', which
> clients and servers use in IPP attributes. Such attributes are in a message
> body whose Content-Type is application/ipp. A client maps 'ipp' URLs to
> 'http' URLs, and then follows the HTTP/1.1 rules for constructing a
> Request-Line and HTTP headers. The IPP document will not prohibit
> implementations from supporting other schemes in IPP attributes, but such
> support is not defined by this document.
>> Now for the details.
>> A client and an IPP object (i.e. the server) SHOULD support the 'ipp'
scheme
> in the following IPP attributes. Each of these attributes identifies a
> printer or job object. The 'ipp' scheme is not intended for use in 'uri'
> valued attributes not in this list.
>> job attributes -
> job-uri
> job-printer-uri
> printer attributes -
> printer-uri-supported
> operation attributes -
> job-uri
> printer-uri
>> If the scheme of the target URL in a request (i.e. the value of
> "printer-uri" or "job-uri" operation attribute) is some scheme 'x', other
> than 'ipp', the behavior of the IPP object is not defined by this
document.
> However, it is RECOMMENDED that if an operation on an IPP object creates a
> new value for any of the above attributes, that attribute has the same
> scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of the
> seven attributes above in the response, that the IPP object returns those
> URL values as is, regardless of the scheme of the target URL.
>> If the client obtains a target URL from a directory service, the scheme of
> the target URL SHOULD be 'ipp'. If the scheme is not 'ipp', the behavior
of
> the client is not defined by this document, but it is RECOMMENDED that the
> client use the URL as is as the target URL.
>> Although user interfaces are beyond the scope of this document, it is
> RECOMMENDED that if software exposes the URL values of any of the above
> seven attributes to a human user, that the human see the URL as is.
>> When a client sends a request, it MUST convert an 'ipp' target URL to an
> 'http' target URL for use in the HTTP Request-Line and HTTP headers as
> specified by HTTP/1.1. However, the 'ipp' target URL remains as is for the
> value of the "printer-uri" or "job-uri" attribute in the message body. If
> the scheme of the target URL is not 'ipp', the behavior of the client is
not
> defined by this document, but it is RECOMMENDED that the client use the
> target URL as is in the Request-Line and HTTP headers.
>> A client converts an 'ipp' URL to an 'http' URL by
> 1) replacing the 'ipp' scheme by 'http'
> 2) adding an explicit port 631 if the URL does not contain an explicit
> port.
>> When an IPP client sends a request directly (i.e. no proxy) to an ‘ipp’ URL
> such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a TCP connection
> to some port (this example uses the IPP default port 631) on some host
> (“myhost.com” in this example) with the following headers:
>> POST /myprinter/myqueue HTTP/1.1
> Host: myhost.com:631
> Content-type: application/ipp
> Transfer-Encoding: chunked
> ...
> "printer-uri" "ipp://myhost.com/myprinter/myqueue"> (encoded in application/ipp message body)
> ...
>> When an IPP client sends a request via a proxy, such as “myproxy.com”, to
an
> ‘ipp’ URL, such as “ipp://myhost.com/myprinter/myqueue”, it MUST open a
TCP
> connection to some port (8080 in this example) on some proxy (“myproxy.com”
> in this example) with the following headers:
>>> POST
> <http://myhost.com:631/myprinter/myqueue>http://myhost.com:631/myprinter/m> yqueue HTTP/1.1
> Host: myproxy.com:8080
> Content-type: application/ipp
> Transfer-Encoding: chunked
> ...
> "printer-uri" "ipp://myhost.com/myprinter/myqueue"> (encoded in application/ipp message body)
> ...
>> The proxy then connects to the IPP origin server with headers that are the
> same as the "no-proxy" example above.
>>