[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
INTERNET-DRAFT

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

                                                          Robert Herriot
                                                        Sun Microsystems
                                                         Carl-Uno Manros
                                                       Xerox Corporation

                                                       November 16, 1998


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


Abstract


Internet Printing Protocol/NV (IPP/NV) is the next version of IPP, which
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.

IPP/1.0 is described by the following documents:

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

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











Herriot and Manros                                               Page 1
                         Expires May 16, 1999


INTERNET-DRAFT         IPP/NV:  IPP URL Scheme        November 16, 1998


1  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 the implicit
(default) port number that clients use to connect to a server is port
631.

In the remainder of this 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) MUST support the ipp-URL
value in the following IPP attributes.
    job attributes:
     job-uri
     job-printer-uri
    printer attributes:
     printer-uri-supported
    operation attributes:
     job-uri
     printer-uri

Each of the above attributes identifies a printer or job object. The
ipp-URL is intended as the value of the attributes in this list, and for
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 a printer registers its URL with a directory service, the printer
MUST register an ipp-URL.

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

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.

The client  MUST use the target http-URL in both the HTTP Request-Line
and HTTP headers, as specified by HTTP[RFC2068][RFC2069] . However, the
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.



Herriot and Manros                                               Page 2
                         Expires May 16, 1999


INTERNET-DRAFT         IPP/NV:  IPP URL Scheme        November 16, 1998


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:

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)
...

As another example, when an IPP client sends the same request as above
via a proxy  "myproxy.com", it opens a TCP connection to the proxy port
8080 on the proxy host "myproxy.com" and sends the following data:

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.

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.




Herriot and Manros                                               Page 3
                         Expires May 16, 1999


INTERNET-DRAFT         IPP/NV:  IPP URL Scheme        November 16, 1998



       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-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-07.txt,
  November, 1998.


[IPP-REQ]

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



Herriot and Manros                                               Page 4
                         Expires May 16, 1999


INTERNET-DRAFT         IPP/NV:  IPP URL Scheme        November 16, 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.


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
































Herriot and Manros                                               Page 5
                         Expires May 16, 1999