Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol
draft-ietf-ipp-rat-04

Versions: 00 01 02 03 04 rfc2568                                        
 INTERNET-DRAFT                                       Stephen N. Zilles
                                                      Adobe Systems Inc.
                                                           July 14, 1997

          Rationale for the Structure of the Model and Protocol
                for the Internet Printing Protocol (IPP)
                      <draft-ietf-ipp-rat-00.txt>
                          Expires Jan 14, 1998

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

                                Abstract
This document is one of a set of documents which together describe all
aspects of a new Internet Printing Protocol (IPP). IPP is an application
level protocol that can be used for distributed printing on the
Internet. There are multiple parts to IPP, but the primary architectural
components are the Model, the Protocol and an interface to Directory
Services. This document provides a high level overview of the
architecture and provides the rational for the decisions made in
structuring the architecture.
 The full set of IPP documents include:
     Internet Printing Protocol/1.0: Requirements
     Internet Printing Protocol/1.0: Model and Semantics
     Internet Printing Protocol/1.0: Security
     Internet Printing Protocol/1.0: Protocol Specification
     Internet Printing Protocol/1.0: Directory Schema





















Zilles                                              [Page 1]


  Rationale for the Structure of the Model and Protocol July 14, 1997


                           TABLE OF CONTENTS


1. ARCHITECTURAL OVERVIEW..............................................3


2. THE PRINTER.........................................................4


3. RATIONAL FOR THE MODEL..............................................4


4. RATIONAL FOR THE PROTOCOL...........................................5

 4.1 The Encoding .....................................................5

 4.2 Smission Mechanism ...............................................5


5. RATIONAL FOR THE DIRECTORY SCHEMA...................................6


6. RATIONAL FOR SECURITY...............................................6


7. AUTHOR'S ADDRESSES..................................................7




























Zilles                                              [Page 2]


      Rationale for the Structure of the Model and Protocol July 14, 1997

         1      Rationale for the Structure of the Model and Protocol
         2            for the Internet Printing Protocol (IPP)

         3  1. Architectural Overview
         4  The Internet Printing Protocol (IPP) is an application level
         5  protocol that can be used for distributed printing on the
         6  Internet. This protocol defines interactions between a
         7  client and a server. The client is provided the capability
         8  to inquire about capabilities of a printer, to submit print
         9  jobs and to inquire about and cancel print jobs. The server
        10  for these requests is the Printer; the Printer is an
        11  abstraction a generic document output device and/or a print
        12  service provider. Thus, the Printer could be a real printing
        13  device, such as a computer printer or fax output device, or
        14  it could be a service that interfaced with output devices.
        15  The architecture for IPP defines (in the Model document) an
        16  abstract Model for the data which is used to control the
        17  printing process and to provide information about the
        18  process and the capabilities of the Printer. This abstract
        19  Model is hierarchical in nature and reflects the structure
        20  of the Printer and the Jobs that may be being processed by
        21  the Printer.  The Internet provides a channel between the
        22  client and the server/Printer. Use of this channel requires
        23  flattening and sequencing the hierarchical Model data.
        24  Therefore, the IPP also defines (in the Protocol document)
        25  an encoding of the data in the model for transfer between
        26  the client and server. This transfer of data may be either a
        27  request or the response to a request.   Finally, the IPP
        28  defines (in the Protocol document) a protocol for
        29  transfering the encoded request and response data between
        30  the client and the server/Printer.
        31  An example of a typical interaction would by a request from
        32  the client to create a print job. The client would assemble
        33  the Model data to be associated with that job, such as the
        34  name of the job, the media to use, the number of pages to
        35  place on each media instance, etc. This data would then be
        36  encoded according to the Protocol and would be transmitted
        37  according to the Protocol. The server/Printer would receive
        38  the encoded Model data, decode it into a form understood by
        39  the server/Printer and, based on that data, do one of two
        40  things: (1) accept the job or (2) reject the job. In either
        41  case, the server must construct a response in terms of the
        42  Model data, encode that response according to the Protocol
        43  and transmit that encoded Model data as the response to the
        44  request using the Protocol.
        45  Another part of the IPP architecture is the Directory
        46  Schema. The role of the Directory Schema is to provide a
        47  standard set of attributes which might be used to query a
        48  directory service for the URI of a Printer that is likely to
        49  meet the needs of the client.
        50  The IPP architecture also addresses security issues such as
        51  control of access to server/Printers and secure
        52  transmissions of requests, response and the data to be
        53  printed.

            Zilles                                              [Page 3]


      Rationale for the Structure of the Model and Protocol July 14, 1997

        54  2. The Printer
        55  Because the (abstract) server/Printer encompasses a wide
        56  range of implementations, it is necessary to make some
        57  assumptions about a minimal implementation. The most likely
        58  minimal implementation is one that is embedded in an output
        59  device running a specialized real time operating system and
        60  with limited processing, memory and storage capabilities.
        61  This Printer will be connected to the Internet and will have
        62  at least a TCP/IP capability with (likely) SNMP support for
        63  the Internet connection. In addition, it is likely the the
        64  Printer will be an HTML/HTTP server to allow direct user
        65  access to information about the printer.

        66  3. Rationale For The Model
        67  The Model is defined independently of any encoding of the
        68  Model data both to support the likely uses of IPP and to be
        69  robust with respect to the possibility of alternate
        70  encodings.
        71  It is expected that a client or server/Printer would
        72  represent the Model data in some data structure within the
        73  applications/servers that support IPP. Therefore, the Model
        74  was designed to make that representation straightforward.
        75  Typically, a parser or formatter would be used to convert
        76  from or to the encoded data format. Once in an internal form
        77  suitable to a product, the data can be manipulated by the
        78  product. For example, the data sent with a Print Job can be
        79  used to control the processing of that Print Job.
        80  The semantics of IPP are attached to the (abstract) Model.
        81  Therefore, the application/server is not dependent on the
        82  encoding of the Model data, and it is possible to consider
        83  alternative mechanisms and formats by which the data could
        84  be transmitted from a client to a server; for example, a
        85  server could have a direct, client-less GUI interface that
        86  might be used to accept some kinds of Print Jobs. This
        87  independence would also allow a different encoding and/or
        88  transmission mechanism to be used if the ones adopted here
        89  were shown to be overly limiting in the future. Such a
        90  change could be migrated into new products as an alternate
        91  protocol stack/parser for the Model data.
        92  Having an abstract Model also allow the Model data to be
        93  aligned with the (abstract) model used in the Printer, Job
        94  and Host Resources MIBs. This provides consistency in
        95  interpretation of the data obtained independently of how the
        96  data is accessed, whether via IPP or via SNMP and the
        97  Printer/Job MIBs.

        98  4. Rationale For The Protocol
        99  There are two parts to the Protocol: (1) the encoding of the
       100  Model data and (2) the mechanism for transmitting the model
       101  data between client and server.

       102  4.1 The Encoding
       103  The TranTo make it simpler to develop embedded printers, a
       104  very simple binary encoding has been chosen. This encoding

            Zilles                                              [Page 4]


      Rationale for the Structure of the Model and Protocol July 14, 1997

       105  is adequate to represent the kinds of data that occur within
       106  the Model. It has a simple structure consisting of name
       107  value pairs in which the names are length specified strings
       108  constrained to characters from a subset of ASCII and the
       109  values are either scalars or a sequence of scalars. Each
       110  scalar value has a length specification.
       111  A fully encoded request/response has a version number, an
       112  operation (for a request) or a status (for a response),
       113  associated parameters which are encoded Model data and,
       114  optionally, print data following the Model data.
       115  [ISSUE: what should be said about Parameters and Attributes]

       116  4.2 Smission Mechanism
       117  The chosen mechanism for transmitting the encoded Model data
       118  is HTTP 1.1 Post (and associated response). No modifications
       119  to HTTP 1.1 are proposed or required.
       120   The sole role of the Transmission Mechanism is to provide a
       121  transfer of encoded Model data from/to the client to/from
       122  the server. This could be done using any data delivery
       123  mechanism. The key reasons why HTTP 1.1 Post is used are:
       124  1. HTTP 1.0 is already widely deployed and, based on the
       125     recent evidence, HTTP 1.1 will be widely deployed as the
       126     manufactures release new products. The performance
       127     benefits of HTTP 1.1 have been shown and manufactures are
       128     reacting postively.
       129  2. Wide deployment has meant that many of the problems of
       130     making a protocol work in a wide range of environments
       131     from local net to intranet to internet have been solved
       132     and will stay solved with HTTP 1.1 deployment.
       133  3. HTTP 1.1 solves most of the problems that might have
       134     required a new protocol to be developed. HTTP 1.1 allows
       135     persistent connections that make a multi-message protocol
       136     be more efficient; for example it is practical to have a
       137     separate CreatJob and SendJob messages. Chunking allows
       138     the transmission of large print files without having to
       139     prescan the file to determine the file length. The accept
       140     headers allow the client's protocol and localization
       141     desires to be transmitted with the IPP operations and
       142     data. The HTTP redirect response allows a client to be
       143     informed  when a Job he is interested in is moved to
       144     another server/Printer for any reason.
       145  4. Most network Printers will be implementing HTTP servers
       146     for reasons other than IPP. These network attached
       147     Printers want to provide information on how to use the
       148     printer, its current state, etc. in HTML. This requires
       149     having an HTTP server which would be available to do IPP
       150     functions as well.
       151  5. Most of the complexity of HTTP 1.1 is concerned with the
       152     implementation of proxies and not the implementation of
       153     clients and/or servers. Work is proceding in the HTTP
       154     Working Group to help identify what must be done by a
       155     server. As the Protocol document shows, that is not very
       156     much.


            Zilles                                              [Page 5]


      Rationale for the Structure of the Model and Protocol July 14, 1997

       157  6. An HTTP based solution fits will with the Internet
       158     security mechanism that are currently deployed or being
       159     deployed. HTTP will run over SSL/TLS. The digest
       160     authentication mechanism of HTTP 1.1 provides an adequate
       161     level of access control (at least for intranet usage).
       162     These solutions are deployed and in practical use; a new
       163     solution would require extensive use to have the same
       164     degree of confidence in its security.

       165  5. Rationale For The Directory Schema
       166  Successful use of IPP depends on the client finding a
       167  suitable IPP enabled Printer to which to send a IPP
       168  requests, such as print a job. This task is simplified if
       169  there is a Directory Service which can be queried for a
       170  suitable Printer. The purpose of the Directory Schema is to
       171  have a standard description of Printer attributes that can
       172  be associated the the URI for the printer. These attributes
       173  are a subset of the Model attributes and can be encoded in
       174  the appropriate query syntax for the Directory Service being
       175  used by the client.

       176  6. Rationale For Security
       177  Security is an areas of active work on the Internet.
       178  Complete solutions to a wide range of security concerns are
       179  not yet available. Therefore, in the design of IPP, the
       180  focus has been on identifying a set of security
       181  protocols/features that are implemented (or currently
       182  implementable) and solve real problems with distributed
       183  printing. The two areas that seem appropriate to support
       184  are: (1) authorization to use a Printer and (2) secure
       185  interaction with a printer. The chosen mechanisms are the
       186  digest authentication mechanism of HTTP 1.1 and the SSL/TLS
       187  secure communication mechanism, which also includes
       188  authorization.

       189  7. Author's Addresses
       190      Stephen Zilles
       191      Adobe Systems Incorporated
       192      345 Park Avenue
       193      MailStop W14
       194      San Jose, CA 95110-2704
       195
       196      Phone: +1 408 536-4766
       197      Fax:   +1 408 537-4042
       198      Email: szilles@adobe.com
       199









            Zilles                                              [Page 6]