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.
    job attributes:
     job-uri
     job-printer-uri
    printer attributes:
     printer-uri-supported
    operation attributes:
     job-uri
     printer-uri

Each of these the above attributes identifies a printer or job object. The 'ipp' scheme
ipp-URL is not intended
  for use in 'uri' valued as the value of the attributes not in this list.

     job attributes -
          job-uri
          job-printer-uri

     printer list, and for
no other attributes. All of these attributes -
          printer-uri-supported

     operation have a syntax type of
'uri', but there are attributes -
          job-uri
          printer-uri

  If the scheme with a syntax type of 'uri' that do not
use the target 'ipp' scheme, e.g. 'job-more-info'.

If a printer registers its URL in with a request (i.e. directory service, the value of
  "printer-uri" or "job-uri" operation attribute) is some scheme 'x',
  other than 'ipp', printer
MUST register an ipp-URL.

User interfaces are beyond the behavior scope of the IPP object is not defined by this document.  However, it is RECOMMENDED that But if an operation on an
  IPP object creates a new value for software
exposes the ipp-URL values of 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
  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
  RECOMMENDED that if software exposes the 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