IPP> IPP Meeting Discussion about IPP URL Scheme, including latest int ermediate draft

IPP> IPP Meeting Discussion about IPP URL Scheme, including latest int ermediate draft

IPP> IPP Meeting Discussion about IPP URL Scheme, including latest int ermediate draft

Manros, Carl-Uno B cmanros at cp10.es.xerox.com
Thu Nov 12 00:21:05 EST 1998


Keith,

Please find a little pre-reading for our phone conference
tomorrow. 

It includes our latest draft text for the IPP URL Scheme below:

There are also a few questions for you after the draft text.

--------

INTERNET-DRAFT

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

                                                          Robert Herriot
                                                        Sun Microsystems
                                                         Carl-Uno Manros
                                                       Xerox Corporation

                                                       November 11, 1998


              Internet Printing Protocol/2.0: 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), ds.internic.net (US East 
Coast), or ftp.isi.edu (US West Coast).


1  Abstract


IPP is an application level protocol that can be used for distributed
printing on the Internet.  Related IPP documents:

  Internet Printing Protocol/1.0: Design Goals

  Internet Printing Protocol/1.0: Rational for Structure and Model

  Internet Printing Protocol/1.0: Requirements

  Internet Printing Protocol/1.0: Model and Semantics

  Internet Printing Protocol/1.0: Encoding and Transport


This document describes a solution to an IESG request for a separate
naming scheme for IPP.

2  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 by


Herriot and Manros  Expires May 10, 1999              Page 1



default, the port number used by clients to connect to the server is
port 631.



3  IPP URL Scheme


A client and an IPP object (i.e. the server) MUST support the 'ipp'
scheme in the following IPP attributes.  Each of these attributes
identifies a printer or job object. The 'ipp' scheme is intended for use
in 'uri' valued attributes in this list, and for no other attributes.

   job attributes:
     job-uri
     job-printer-uri
   printer attributes:
     printer-uri-supported
   operation attributes:
     job-uri
     printer-uri


If a printer registers its URL with a directory service, the printer's
URL must contain the 'ipp' scheme.

Although user interfaces are beyond the scope of this document, it is
REQUIRED that if software exposes the URL values of any of the above
five 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 an
'http' target URL for use in the HTTP Request-Line and HTTP headers as
specified by HTTP[RFC2068][RFC2069] . However, the 'ipp' target URL
remains as is for the value of the "printer-uri" or "job-uri" attribute
in the message body.

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. Note: port 631 is the IANA-assigned TCP port number

When an IPP client sends a request directly (i.e. no proxy) to an '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 631) on
some host ("myhost.com" in this example) with the following headers:

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 an IPP client sends a request via a proxy, such as "myproxy.com",
to an 'ipp'  URL, such as "ipp://myhost.com/myprinter/myqueue", it MUST
open a TCP connection to some port (frequently 8080 ) on some proxy
("myproxy.com" in this example) with the following headers:


Herriot and Manros  Expires May 10, 1999              Page 2



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.

4  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 a version 1.0 request, it MUST return a
     version 1.0 response. That is, it MUST support  the 'http' scheme
     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
     scheme of these attributes MUST be 'http'.  For security, a server
     MAY support the 'https' scheme, in addition to 'http' in both
     requests and responses. When the server returns the printer
     attribute "printer-uri-supported", it MUST return all supported
     values, independent of the version in the request (i.e., a version
     1.0 "printer-uri-supported" response value MAY contain an ipp
     scheme).

     The table below shows the scheme that is returned 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.


       Operation                       Job created via
       attributes for
       a request            ipp             http            https


       http                 http            http            No object
                                                            returned

       https                https or http   https or http   No object
                                                            returned

       https                https or http   https or http   https



  @ If a server registers a URL containing an IPP scheme with a name
     service, then it MUST also register a URL with an http scheme. If a
     printer supports a secure connection using SSL3, then it MUST
     register a URL with an https scheme.

  @ If a client receives a "version not supported" error message, it
     must try to send a request in version 1.0, using the "http" scheme
     in place of the "ipp" for the target "job-uri" and "printer-uri"
     operations attributes in the request. An IPP/2.0 client MUST use an
     ipp scheme for non-secure printers and an https scheme for secure
     printers.  An IPP/1.0 client MUST use an http scheme for non-secure
     printers and an https scheme for secure printers.


Herriot and Manros  Expires May 10, 1999              Page 3



5  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].


6  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, 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, 1998.


[IPP-REQ]

  Wright, D., "Design Goals for an Internet Printing Protocol", draft-
  ietf-ipp-req-02.txt, June, 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.


6.1 Authors' Address


Robert Herriot
Sun Microsystems
17 Network Circle
Menlo Park, CA 94025
robert.herriot at eng.sun.com

Carl-Uno Manros
Xerox Corporation
701 Aviation Blvd.
El Segundo, CA 90245
manros at cp10.es.xerox.com

-----

Questions for Phone Conference on Thursday:

We have run into some question marks relating to Channel Security for IPP

1) Several current IPP implementations will support SSL3 over https://
scheme.
Can we mix ipp:// scheme with https:// for practical purposes?

2) Please check draft above to se if you like our thinking on how https://
scheme
works for backwards compatibillty. Do you agree to our solution?

3) Considering the potentially unsuitable mix between ipp:// scheme and
https://
scheme, should we wait to introduce the ipp:// scheme until we can combine
it
with TLS, which does not require a scheme on it's own. (However, we would
still need to interwork with SSL3 implementations).

Other questions:

4) Do you agree with the backwards compatibility rules for inter-working
with
existing implementations?

5) The WG members would like to hear directly from you the justification for

using the ipp:// scheme (again).

6) If we reach agreement on the ipp:// scheme issue, when could we expect a 
decision from the IESG on the IPP Proposed Standards documents?

Speak to you tomorrow,

Carl-Uno


Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros at cp10.es.xerox.com 



More information about the Ipp mailing list