------ =_NextPart_000_01BDBB21.8986E1B8
Content-Type: text/plain
During today's phone conference it turned out that some people were
unclear about the latest draft version of the ipp scheme proposal. It
turns out that it was included as part of a message sent out by Bob
Herriot. To make it a bit easier, I have now put that text into a
separate TXT document, which is attached to this message. I will also
put it up on the server, but it seems to be inaccessible right now.
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
------ =_NextPart_000_01BDBB21.8986E1B8
Content-Type: text/plain;
name="IPPSchemePostMonterey.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="IPPSchemePostMonterey.txt"
Post-Monterey Proposal for an ipp scheme after discussion with Keith =
Moore
July 1998
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Summary:
The quick summary is that IPP should support a new scheme 'ipp', which=20
clients and servers use in IPP attributes. Such attributes are in a =
message=20
body whose Content-Type is application/ipp. A client maps 'ipp' URLs =
to=20
'http' URLs, and then follows the HTTP/1.1 rules for constructing a=20
Request-Line and HTTP headers. The IPP document will not prohibit=20
implementations from supporting other schemes in IPP attributes, but =
such=20
support is not defined by this document. =20
Now for the details.
A client and an IPP object (i.e. the server) SHOULD support the 'ipp' =
scheme=20
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'=20
valued attributes not in this list.
job attributes -=20
job-uri=20
job-printer-uri
printer attributes -=20
printer-uri-supported
operation attributes -=20
job-uri=20
printer-uri
If the scheme of the target URL in a request (i.e. the value of =20
"printer-uri" or "job-uri" operation attribute) is some scheme 'x', =
other=20
than 'ipp', the behavior of the IPP object is not defined by this =
document. =20
However, it is RECOMMENDED that if an operation on an IPP object =
creates a=20
new value for any of the above attributes, that attribute has the same=20
scheme 'x'. It is also RECOMMENDED that if an IPP object returns any of =
the=20
seven attributes above in the response, that the IPP object returns =
those=20
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=20
the target URL SHOULD be 'ipp'. If the scheme is not 'ipp', the =
behavior of=20
the client is not defined by this document, but it is RECOMMENDED that =
the=20
client use the URL as is as the target URL.
Although user interfaces are beyond the scope of this document, it is=20
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. =20
When a client sends a request, it MUST convert an 'ipp' target URL to =
an=20
'http' target URL for use in the HTTP Request-Line and HTTP headers as=20
specified by HTTP/1.1. However, the 'ipp' target URL remains as is for =
the=20
value of the "printer-uri" or "job-uri" attribute in the message body. =
If=20
the scheme of the target URL is not 'ipp', the behavior of the client =
is not=20
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=20
1) replacing the 'ipp' scheme by 'http'=20
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 =
=91ipp=92 URL=20
such as "ipp://myhost.com/myprinter/myqueue", it MUST open a TCP =
connection=20
to some port (this example uses the IPP default port 631) on some host=20
("myhost.com" in this example) with the following headers:
POST /myprinter/myqueue HTTP/1.1=20
Host: myhost.com:631=20
Content-type: application/ipp=20
Transfer-Encoding: chunked=20
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"=20
(encoded in application/ipp message body)=20
...
When an IPP client sends a request via a proxy, such as "myproxy.com", =
to an=20
=91ipp=92 URL, such as "ipp://myhost.com/myprinter/myqueue", it MUST =
open a TCP=20
connection to some port (8080 in this example) on some proxy =
("myproxy.com"=20
in this example) with the following headers:
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1=20
Host: myproxy.com:8080=20
Content-type: application/ipp=20
Transfer-Encoding: chunked=20
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"=20
(encoded in application/ipp message body)=20
...
The proxy then connects to the IPP origin server with headers that are =
the=20
same as the "no-proxy" example above.
------ =_NextPart_000_01BDBB21.8986E1B8--