< 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
job-uri
job-printer-uri
printer attributes - A client and an IPP object (i.e. the server) MUST support the ipp-URL
printer-uri-supported value in the following IPP attributes.
job attributes:
job-uri
job-printer-uri
printer attributes:
printer-uri-supported
operation attributes:
job-uri
printer-uri
operation attributes - Each of the above attributes identifies a printer or job object. The
job-uri ipp-URL is intended as the value of the attributes in this list, and for
printer-uri no other attributes. All of these attributes have a syntax type of
'uri', but there are attributes with a syntax type of 'uri' that do not
use the 'ipp' scheme, e.g. 'job-more-info'.
If the scheme of the target URL in a request (i.e. the value of If a printer registers its URL with a directory service, the printer
"printer-uri" or "job-uri" operation attribute) is some scheme 'x', MUST register an ipp-URL.
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 User interfaces are beyond the scope of this document. But if software
scheme of the target URL SHOULD be 'ipp'. If the scheme is not exposes the ipp-URL values of any of the above five attributes to a
'ipp', the behavior of the client is not defined by this document, human user, it is REQUIRED that the human see the ipp-URL as is.
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 When a client sends a request, it MUST convert a target ipp-URL to a
RECOMMENDED that if software exposes the URL values of any of the target http-URL according to the following rules:
above seven attributes to a human user, that the human see the URL as 1. change the 'ipp' scheme to 'http'
is. 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.
When a client sends a request, it MUST convert an 'ipp' target URL to The client MUST use the target http-URL in both the HTTP Request-Line
an 'http' target URL for use in the HTTP Request-Line and HTTP and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the
headers as specified by HTTP/1.1. However, the 'ipp' target URL client must use the target ipp-URL for the value of the "printer-uri" or
remains as is for the value of the "printer-uri" or "job-uri" "job-uri" attribute within the application/ipp body of the request.
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: Expires May 16, 1999
For example, when an IPP client sends a request directly (i.e. no proxy)
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:
1) replacing the 'ipp' scheme by 'http' POST /myprinter/myqueue HTTP/1.1
2) adding an explicit port 631 if the URL does not contain an Host: myhost.com:631
explicit port. 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 directly (i.e. no proxy) to an As another example, when an IPP client sends the same request as above
'ipp' URL such as "ipp://myhost.com/myprinter/myqueue", it MUST open via a proxy "myproxy.com", it opens a TCP connection to the proxy port
a TCP connection to some port (this example uses the IPP default port 8080 on the proxy host "myproxy.com" and sends the following data:
August 7, 1998 Expires March 7, 1999
Internet Printing Protocol Scheme
631) on some host ("myhost.com" in this example) with the following POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
headers: Host: myhost.com:631
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue"
(encoded in application/ipp message body)
...
POST /myprinter/myqueue HTTP/1.1 The proxy then connects to the IPP origin server with headers that are
Host: myhost.com:631 the same as the "no-proxy" example above.
Content-type: application/ipp
Transfer-Encoding: chunked
...
"printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in 3 Compatibility with IPP/1.0
application/ipp message body)
... For compatibility with IPP/1.0, clients and IPP objects (i.e. a server)
MUST support additional schemes as described in this section:
When an IPP client sends a request via a proxy, such as @ If a server receives an IPP/1.0 request, it MUST return an IPP/1.0
"myproxy.com", to an 'ipp' URL, such as response. That is, it MUST support an http-URL in the target
"ipp://myhost.com/myprinter/myqueue", it MUST open a TCP connection "printer-uri" and "job-uri" operation attributes in a request. If
to some port (8080 in this example) on some proxy ("myproxy.com" in the server returns any of the 3 attributes, "job-uri", "job-
this example) with the following headers: 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.
POST http://myhost.com:631/myprinter/myqueue HTTP/1.1 @ When a server returns the printer attribute "printer-uri-
Host: myproxy.com:8080 supported", it MUST return all supported values for an IPP/NV
Content-type: application/ipp request. For an IPP/1.0 request, a server MUST NOT return values
Transfer-Encoding: chunked that are ipp-URLs, i.e. it MUST return only the http-URLs and
... https-URLs.
"printer-uri" "ipp://myhost.com/myprinter/myqueue" (encoded in @ The table below shows the type of URL that a server returns for the
application/ipp message body) "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
The proxy then connects to the IPP origin server with headers that ipp ipp ipp No URL
are the same as the "no-proxy" example above. returned
References http http http No URL
returned
[IPP-MOD] 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]
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]
Carl-Uno Manros R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
Xerox Corporation "Hypertext Transfer Protocol - HTTP/1.1", RFC 2068, January 1997
701 Aviation Blvd.
El Segundo, CA 90245 [RFC2069]
manros@cp10.es.xerox.com
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
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
manros@cp10.es.xerox.com
Expires May 16, 1999
 End of changes. 43 change blocks. 
120 lines changed or deleted 161 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/