INTERNET DRAFT                                  Stephen N. Zilles
          <draft-ietf-ipp-rat-01.txt>                    Adobe Systems Inc.

	  July 14, 30, 1997                               Expires: Jan 30, 1998

                 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

          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 ''work
          in
     progress." progress.''

          To learn the current status of any Internet-Draft, please check
          the
     "1id-abstracts.txt" ''1id-abstracts.txt'' listing contained in the Internet-Drafts 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

          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 rationale for the decisions made in
          structuring the architecture.

          The full set of IPP documents include:

          Internet Printing Protocol/1.0: Requirements for an Internet
                Printing Protocol
          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
  Rationale for the Structure of the Model and Protocol July 14, 1997

                           TABLE OF CONTENTS

                               Expires: Jan 30, 1998
          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
      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 OVERVIEW

          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 be 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

                               Expires: Jan 30, 1998
          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.

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

        54

          2. The Printer
        55 THE PRINTER

          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 RATIONALE FOR THE MODEL

          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

                               Expires: Jan 30, 1998
          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 allows 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 RATIONALE FOR THE PROTOCOL

          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

          To make it simpler to develop embedded printers, a
       104 very
          simple binary encoding has been chosen. This encoding
      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 specification and is represented either as an 4
          byte integer or a string.

          A fully encoded request/response has a version number, an
       112
          operation (for a request) or a status and optionally a status
          message (for a response),
       113 associated parameters and attributes
          which are encoded Model data and,
       114  optionally, optionally (for a request),
          print data following the Model data.
       115  [ISSUE: what should be said about Parameters and Attributes]

       116

          4.2 Smission The Transmission 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 are given below. The

                               Expires: Jan 30, 1998
          most important of these is the first. With perhaps this
          exception, these reasons could be satisfied by other
          mechanisms. There is no claim that this list uniquely
          determines a choice of mechanism.

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

             2. 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 If the
                Model were to provide for the redirection of Job
                requests, such as Cancel-Job, when a Job is moved, 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.

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

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

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

       157  6.

             5. An HTTP based solution fits will well with the Internet
       158
                security mechanism that are currently deployed or being
       159
                deployed. HTTP will run over SSL/TLS. The digest
       160

                               Expires: Jan 30, 1998
                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 RATIONALE FOR THE DIRECTORY SCHEMA

          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 RATIONALE FOR SECURITY

          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 REFERENCES

          [1]  Wright, F. D., "Requirements for an Internet Printing
               Protocol:"

          [2]  Isaacson, S, deBry, R, Hasting, T, Herriot, R, Powell, P,
               "Internet Printing Protocol/1.0: Model and Semantics"

          [3]  Internet Printing Protocol/1.0: Security

          [4]  Herriot, R, Butler, S, Moore, P, Turner, R, "Internet
               Printing Protocol/1.0: Protocol Specification"

          [5]  Carter, K, Isaacson, S, "Internet Printing Protocol/1.0:
               Directory Schema"

                               Expires: Jan 30, 1998
           8. AUTHORS ADDRESS

           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

+

                               Expires: Jan 30, 1998