IPP> Re: New IPP Scheme
Randy Turner
rturner at sharplabs.com
Thu Jul 16 00:38:06 EDT 1998
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.
>
>
More information about the Ipp
mailing list