Please find a little pre-reading for our phone conference
tomorrow.
It includes our latest draft text for the IPP URL Scheme below:
There are also a few questions for you after the draft text.
--------
INTERNET-DRAFT
<draft-ietf-ipp-ipp-scheme-01.txt>
Robert Herriot
Sun Microsystems
Carl-Uno Manros
Xerox Corporation
November 11, 1998
Internet Printing Protocol/2.0: IPP URL Scheme
Status of this memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft documents valid
for a maximum of six months and may be updated, replaced, or obsoleted
by other documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work in
progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
1 Abstract
IPP is an application level protocol that can be used for distributed
printing on the Internet. Related IPP documents:
Internet Printing Protocol/1.0: Design Goals
Internet Printing Protocol/1.0: Rational for Structure and Model
Internet Printing Protocol/1.0: Requirements
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Encoding and Transport
This document describes a solution to an IESG request for a separate
naming scheme for IPP.
2 Introduction
This document states that IPP must 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 [RFC2068][RFC2069] rules
for constructing a Request-Line and HTTP headers. The IPP scheme
implies all of the same protocol semantics as that of the HTTP
scheme[RFC2068], except that it represents a print service and by
Herriot and Manros Expires May 10, 1999 Page 1
default, the port number used by clients to connect to the server is
port 631.
3 IPP URL Scheme
A client and an IPP object (i.e. the server) MUST support the 'ipp'
scheme in the following IPP attributes. Each of these attributes
identifies a printer or job object. The 'ipp' scheme is intended for use
in 'uri' valued attributes in this list, and for no other attributes.
job attributes:
job-uri
job-printer-uri
printer attributes:
printer-uri-supported
operation attributes:
job-uri
printer-uri
If a printer registers its URL with a directory service, the printer's
URL must contain the 'ipp' scheme.
Although user interfaces are beyond the scope of this document, it is
REQUIRED that if software exposes the URL values of any of the above
five 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[RFC2068][RFC2069] . However, the 'ipp' target URL
remains as is for the value of the "printer-uri" or "job-uri" attribute
in the message body.
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. Note: port 631 is the IANA-assigned TCP port number
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 (frequently 8080 ) on some proxy
("myproxy.com" in this example) with the following headers:
Herriot and Manros Expires May 10, 1999 Page 2
POST http://myhost.com:631/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)
...
The proxy then connects to the IPP origin server with headers that are
the same as the "no-proxy" example above.
4 Compatibility with IPP/1.0
For compatibility with IPP/1.0, clients and IPP objects (i.e. a server)
MUST support additional schemes as described in this section:
@ If a server receives a version 1.0 request, it MUST return a
version 1.0 response. That is, it MUST support the 'http' scheme
in the target "printer-uri" and "job-uri" operation attributes in a
request. If the server returns any of the 3 attributes, "job-uri",
"job-printer-uri" or "printer-uri-supported" in the response, the
scheme of these attributes MUST be 'http'. For security, a server
MAY support the 'https' scheme, in addition to 'http' in both
requests and responses. When the server returns the printer
attribute "printer-uri-supported", it MUST return all supported
values, independent of the version in the request (i.e., a version
1.0 "printer-uri-supported" response value MAY contain an ipp
scheme).
The table below shows the scheme that is returned for the "job-uri"
and "job-printer-uri" job attributes for all operations based on
how the job was created. The "or" in the table below indicates an
implementation option.
Operation Job created via
attributes for
a request ipp http https
http http http No object
returned
https https or http https or http No object
returned
https https or http https or http https
@ If a server registers a URL containing an IPP scheme with a name
service, then it MUST also register a URL with an http scheme. If a
printer supports a secure connection using SSL3, then it MUST
register a URL with an https scheme.
@ If a client receives a "version not supported" error message, it
must try to send a request in version 1.0, using the "http" scheme
in place of the "ipp" for the target "job-uri" and "printer-uri"
operations attributes in the request. An IPP/2.0 client MUST use an
ipp scheme for non-secure printers and an https scheme for secure
printers. An IPP/1.0 client MUST use an http scheme for non-secure
printers and an https scheme for secure printers.
Herriot and Manros Expires May 10, 1999 Page 3
5 Security
See the sections on security in the "Internet Printing Protocol/1.0:
Model and Semantics" [IPP-MOD] and "Internet Printing Protocol/1.0:
Encoding and Transport" [IPP-PRO].
6 References
[IPP-MOD]
Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P.
"Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp-
mod-10.txt, June, 1998.
[IPP-PRO]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt,
June, 1998.
[IPP-REQ]
Wright, D., "Design Goals for an Internet Printing Protocol", draft-
ietf-ipp-req-02.txt, June, 1998.
[RFC2068]
R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, January 1997
[RFC2069]
J. Franks, P. Hallam-Baker, J. Hostetler, P. Leach, A. Luotonen, E.
Sink, L. Stewart, "An Extension to HTTP: Digest Access
Authentication", RFC-2069, Jan 1997.
6.1 Authors' Address
Robert Herriot
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
robert.herriot@eng.sun.com
Carl-Uno Manros
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
manros@cp10.es.xerox.com
-----
Questions for Phone Conference on Thursday:
We have run into some question marks relating to Channel Security for IPP
1) Several current IPP implementations will support SSL3 over https://
scheme.
Can we mix ipp:// scheme with https:// for practical purposes?
2) Please check draft above to se if you like our thinking on how https://
scheme
works for backwards compatibillty. Do you agree to our solution?
3) Considering the potentially unsuitable mix between ipp:// scheme and
https://
scheme, should we wait to introduce the ipp:// scheme until we can combine
it
with TLS, which does not require a scheme on it's own. (However, we would
still need to interwork with SSL3 implementations).
Other questions:
4) Do you agree with the backwards compatibility rules for inter-working
with
existing implementations?
5) The WG members would like to hear directly from you the justification for
using the ipp:// scheme (again).
6) If we reach agreement on the ipp:// scheme issue, when could we expect a
decision from the IESG on the IPP Proposed Standards documents?
Speak to you tomorrow,
Carl-Uno
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