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/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.
--=====================_97913321==_.ALT
Content-Type: text/html; charset="us-ascii"
Action item from Robert Herriot and Tom Hastings:
--=====================_97913321==_.ALT--
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 -
printer attributes -
operation attributes -
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"
...
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/1.1
Host: myproxy.com:8080
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
...
The proxy then connects to the IPP origin server with headers that are
the
same as the "no-proxy" example above.