wdiff draft-ietf-ipp-ipp-scheme-00.txt draft-ietf-ipp-ipp-scheme-01.txt

INTERNET-DRAFT

<draft-ietf-ipp-ipp-scheme-00.txt>

<draft-ietf-ipp-ipp-scheme-01.txt>

Robert Herriot
Sun Microsystems
Carl-Uno Manros
Xerox Corporation

August 7,

November 16, 1998 Expires March 7, 1999

Internet Printing Protocol Protocol/NV: 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 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 ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).

Abstract

IPP

Internet Printing Protocol/NV (IPP/NV) is the next version of IPP, which
is an application level protocol that can be used for distributed printing on the
Internet. Related This document describes a new 'ipp' scheme, which is intended
to identify URLs that reference an IPP printing service.

IPP/1.0 is described by the following documents:

Design Goals for an Internet Printing Protocol

Internet Printing Protocol/1.0: Model and Semantics [IPP-MOD]

Internet Printing Protocol/1.0: Encoding and Transport [IPP-PRO]

Expires May 16, 1999

1 Introduction

This document decribes a possible solution to an IESG request for a
separate naming scheme for IPP. This is for further discussion, no
consensus is yet reached on this in the IPP WG.

Introduction

The quick summary is states that IPP should 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/1.1 HTTP [RFC2068][RFC2069] 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 '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 not defined by port
631.

In the remainder of this document.

Details
August 7, 1998 Expires March 7, 1999
Internet Printing Protocol document the term 'ipp-URL' means a URL whose
scheme is 'ipp' and whose implicit (default) port is 631. The term
'http-URL' means a URL whose scheme is 'http', and the term 'https-URL'
means a URL whose scheme is 'https',

2 IPP URL Scheme

A client and an IPP object (i.e. the server) SHOULD MUST support the 'ipp'
scheme ipp-URL
value 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 - attributes:
job-uri
job-printer-uri
printer attributes - attributes:
printer-uri-supported
operation attributes - attributes:
job-uri
printer-uri

If the scheme

Each of the target URL in above attributes identifies a request (i.e. the value of
"printer-uri" printer or "job-uri" operation attribute) job object. The
ipp-URL is some scheme 'x',
other than 'ipp', intended as the behavior value of the IPP object is not defined by attributes in this document. However, it is RECOMMENDED that if an operation on an
IPP object creates a new value list, and for any of the above attributes, that
attribute has the same scheme 'x'. It is also RECOMMENDED that if an
IPP object returns any
no other attributes. All of the seven these attributes above in the response,
that the IPP object returns those URL values as is, regardless have a syntax type of the
scheme
'uri', but there are attributes with a syntax type of 'uri' that do not
use the target URL. 'ipp' scheme, e.g. 'job-more-info'.

If the client obtains a target printer registers its URL from with 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 printer
MUST register an ipp-URL.

User interfaces are beyond the scope of this document, it is
RECOMMENDED that document. But if software
exposes the URL ipp-URL values of any of the above seven five attributes to a
human user, it is REQUIRED that the human see the URL ipp-URL as is.

When a client sends a request, it MUST convert an 'ipp' a target URL ipp-URL to
an 'http' 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 for does not contain an explicit
port. Note: port 631 is the IANA-reserved TCP port number.

The client MUST use the target http-URL in both the HTTP Request-Line
and HTTP
headers headers, as specified by HTTP/1.1. HTTP[RFC2068][RFC2069] . However, the 'ipp'
client must use the target URL
remains as is ipp-URL 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', within the behavior application/ipp body 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 request.

Expires May 16, 1999
For example, when an IPP client sends a request directly (i.e. no proxy)
to an
'ipp' URL such as ipp-URL "ipp://myhost.com/myprinter/myqueue", it MUST open opens 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) 631 (the ipp implicit port) on some the host ("myhost.com" in this example) with "myhost.com"
and sends the following
headers: data:

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

As another example, when an IPP client sends a the same request as above
via a proxy, such as proxy "myproxy.com", to an 'ipp' URL, such as
"ipp://myhost.com/myprinter/myqueue", it MUST open opens a TCP connection to some the proxy port (8080 in this example)
8080 on some the proxy ("myproxy.com" in
this example) with host "myproxy.com" and sends the following headers: data:

POST http://myhost.com:631/myprinter/myqueue HTTP/1.1
Host: myproxy.com:8080 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.

3 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 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]

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,
mod-11.txt, November, 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, draft-ietf-ipp-pro-07.txt,
November, 1998.

[IPP-REQ]

Wright, D., "Design Goals for an Internet Printing Protocol", draft-
ietf-ipp-req-02.txt, June,
ietf-ipp-req-03.txt, November, 1998.

August 7, 1998

Expires March 7, May 16, 1999
Internet Printing

[RFC2068]

R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
"Hypertext Transfer Protocol Scheme

Author's - 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
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
manros@cp10.es.xerox.com

Expires May 16, 1999