draft-ietf-ipp-ipp-scheme-00.txt   draft-ietf-ipp-ipp-scheme-01.txt 
INTERNET-DRAFT INTERNET-DRAFT
<draft-ietf-ipp-ipp-scheme-00.txt> Carl-Uno Manros <draft-ietf-ipp-ipp-scheme-01.txt>
Robert Herriot
Sun Microsystems
Carl-Uno Manros
Xerox Corporation Xerox Corporation
August 7, 1998 Expires March 7, 1999 November 16, 1998
Internet Printing Protocol Scheme Internet Printing Protocol/NV: IPP URL Scheme
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas, and
and its working groups. Note that other groups may also distribute its working groups. Note that other groups may also distribute working
working documents as Internet-Drafts. Internet-Drafts are draft documents as Internet-Drafts. Internet-Drafts are draft documents valid
documents valid for a maximum of six months and may be updated, for a maximum of six months and may be updated, replaced, or obsoleted
replaced, or obsoleted by other documents at any time. It is by other documents at any time. It is inappropriate to use Internet-
inappropriate to use Internet-Drafts as reference material or to cite Drafts as reference material or to cite them other than as "work in
them other than as "work in progress." progress."
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
Abstract Abstract
IPP is an application level protocol that can be used for distributed Internet Printing Protocol/NV (IPP/NV) is the next version of IPP, which
printing on the Internet. Related IPP documents: is an application level protocol for distributed printing on the
Internet. This document describes a new 'ipp' scheme, which is intended
to identify URLs that reference an IPP printing service.
Design Goals for an Internet Printing Protocol IPP/1.0 is described by the following documents:
Internet Printing Protocol/1.0: Model and Semantics
Internet Printing Protocol/1.0: Encoding and Transport
This document decribes a possible solution to an IESG request for a Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD]
separate naming scheme for IPP. This is for further discussion, no
consensus is yet reached on this in the IPP WG.
Introduction Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]
The quick summary is that IPP should support a new scheme 'ipp', Expires May 16, 1999
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 1 Introduction
other schemes in IPP attributes, but such support is not defined by
this document.
Details This document states that IPP must support a new scheme 'ipp', which
August 7, 1998 Expires March 7, 1999 clients and servers use in IPP attributes. Such attributes are in a
Internet Printing Protocol Scheme 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 the implicit
(default) port number that clients use to connect to a server is port
631.
A client and an IPP object (i.e. the server) SHOULD support the 'ipp' In the remainder of this document the term 'ipp-URL' means a URL whose
scheme in the following IPP attributes. Each of these attributes scheme is 'ipp' and whose implicit (default) port is 631. The term
identifies a printer or job object. The 'ipp' scheme is not intended 'http-URL' means a URL whose scheme is 'http', and the term 'https-URL'
for use in 'uri' valued attributes not in this list. means a URL whose scheme is 'https',
job attributes - 2 IPP URL Scheme
A client and an IPP object (i.e. the server) MUST support the ipp-URL
value in the following IPP attributes.
job attributes:
job-uri job-uri
job-printer-uri job-printer-uri
printer attributes:
printer attributes -
printer-uri-supported printer-uri-supported
operation attributes:
operation attributes -
job-uri job-uri
printer-uri printer-uri
If the scheme of the target URL in a request (i.e. the value of Each of the above attributes identifies a printer or job object. The
"printer-uri" or "job-uri" operation attribute) is some scheme 'x', ipp-URL is intended as the value of the attributes in this list, and for
other than 'ipp', the behavior of the IPP object is not defined by no other attributes. All of these attributes have a syntax type of
this document. However, it is RECOMMENDED that if an operation on an 'uri', but there are attributes with a syntax type of 'uri' that do not
IPP object creates a new value for any of the above attributes, that use the 'ipp' scheme, e.g. 'job-more-info'.
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 If a printer registers its URL with a directory service, the printer
RECOMMENDED that if software exposes the URL values of any of the MUST register an ipp-URL.
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 User interfaces are beyond the scope of this document. But if software
an 'http' target URL for use in the HTTP Request-Line and HTTP exposes the ipp-URL values of any of the above five attributes to a
headers as specified by HTTP/1.1. However, the 'ipp' target URL human user, it is REQUIRED that the human see the ipp-URL as is.
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: When a client sends a request, it MUST convert a target ipp-URL to a
target http-URL according to the following rules:
1. change the 'ipp' scheme to 'http'
2. add an explicit port 631 if the URL does not contain an explicit
port. Note: port 631 is the IANA-reserved TCP port number.
1) replacing the 'ipp' scheme by 'http' The client MUST use the target http-URL in both the HTTP Request-Line
2) adding an explicit port 631 if the URL does not contain an and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the
explicit port. client must use the target ipp-URL for the value of the "printer-uri" or
"job-uri" attribute within the application/ipp body of the request.
When an IPP client sends a request directly (i.e. no proxy) to an Expires May 16, 1999
'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
August 7, 1998 Expires March 7, 1999
Internet Printing Protocol Scheme
631) on some host ("myhost.com" in this example) with the following For example, when an IPP client sends a request directly (i.e. no proxy)
headers: to an ipp-URL "ipp://myhost.com/myprinter/myqueue", it opens a TCP
connection to port 631 (the ipp implicit port) on the host "myhost.com"
and sends the following data:
POST /myprinter/myqueue HTTP/1.1 POST /myprinter/myqueue HTTP/1.1
Host: myhost.com:631 Host: myhost.com:631
Content-type: application/ipp Content-type: application/ipp
Transfer-Encoding: chunked Transfer-Encoding: chunked
... ...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
"printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in (encoded in application/ipp message body)
application/ipp message body)
... ...
When an IPP client sends a request via a proxy, such as As another example, when an IPP client sends the same request as above
"myproxy.com", to an 'ipp' URL, such as via a proxy "myproxy.com", it opens a TCP connection to the proxy port
"ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection 8080 on the proxy host "myproxy.com" and sends the following data:
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 POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myproxy.com:8080 Host: myhost.com:631
Content-type: application/ipp Content-type: application/ipp
Transfer-Encoding: chunked Transfer-Encoding: chunked
... ...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in The proxy then connects to the IPP origin server with headers that are
application/ipp message body) the same as the "no-proxy" example above.
... 3 Compatibility with IPP/1.0
The proxy then connects to the IPP origin server with headers that For compatibility with IPP/1.0, clients and IPP objects (i.e. a server)
are the same as the "no-proxy" example above. MUST support additional schemes as described in this section:
References @ If a server receives an IPP/1.0 request, it MUST return an IPP/1.0
response. That is, it MUST support an http-URL 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 value
of these attributes MUST be http-URLs. For security, a server MAY
also support https-URLs.
@ When a server returns the printer attribute "printer-uri-
supported", it MUST return all supported values for an IPP/NV
request. For an IPP/1.0 request, a server MUST NOT return values
that are ipp-URLs, i.e. it MUST return only the http-URLs and
https-URLs.
@ The table below shows the type of URL that a server returns 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.
Expires May 16, 1999
Operation Job created via
attribute
ipp http https
s for a
request
ipp ipp ipp No URL
returned
http http http No URL
returned
https https https or https
or http http
@ If a server registers an ipp-URL with a name service, then it MUST
also register an http-URL. If a printer supports a secure
connection using SSL3, then it MUST register an https-URL.
@ An IPP/NV client MUST use an ipp-URL for non-secure printers unless
it receives a "version not supported" error message. Then it MUST
try to send a request in version 1.0, using the http-URL in place
of the ipp-URL for the target "job-uri" and "printer-uri" operation
attributes in the request. For secure printers, an IPP/NV client
must operate as an IPP/1.0 client and use an https-URL. An IPP/1.0
client MUST use an http-URL for non-secure printers and an https-
URL for secure printers.
4 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].
5 References
[IPP-MOD] [IPP-MOD]
Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P. Isaacson, S., deBry, R., Hastings, T., Herriot, R., Powell, P.
"Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp- "Internet Printing Protocol/1.0: Model and Semantics" draft-ietf-ipp-
mod-10.txt, June, 1998. mod-11.txt, November, 1998.
[IPP-PRO] [IPP-PRO]
Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing Herriot, R., Butler, S., Moore, P., Tuner, R., "Internet Printing
Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-06.txt, Protocol/1.0: Encoding and Transport", draft-ietf-ipp-pro-07.txt,
June, 1998. November, 1998.
[IPP-REQ] [IPP-REQ]
Wright, D., "Design Goals for an Internet Printing Protocol", draft- Wright, D., "Design Goals for an Internet Printing Protocol", draft-
ietf-ipp-req-02.txt, June, 1998. ietf-ipp-req-03.txt, November, 1998.
August 7, 1998 Expires March 7, 1999 Expires May 16, 1999
Internet Printing Protocol Scheme
Author's Address [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.
5.1 Authors' Address
Robert Herriot
Sun Microsystems
901 San Antonio Road, MPK-17
Palo Alto, CA 94303
robert.herriot@eng.sun.com
Carl-Uno Manros Carl-Uno Manros
Xerox Corporation Xerox Corporation
701 Aviation Blvd. 701 Aviation Blvd.
El Segundo, CA 90245 El Segundo, CA 90245
manros@cp10.es.xerox.com manros@cp10.es.xerox.com
Expires May 16, 1999
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/