The "Mapping between LPD and IPP Protocols" document gives some
   advice to implementers of gateways between IPP and LPD (Line Printer
   Daemon) implementations.

1.   ARCHITECTURAL OVERVIEW

   The Internet Printing Protocol (IPP) is an application level protocol
   that can be used for distributed printing on the Internet.  This
   protocol defines interactions between a client and a server.  The




 
RFC 2568                   Rationale for IPP                  April 1999


   protocol allows a client to inquire about capabilities of a printer,
   to submit print jobs and to inquire about and cancel print jobs. The
   server for these requests is the Printer; the Printer is an
   abstraction of a generic document output device and/or a print
   service provider. Thus, the Printer could be a real printing device,
   such as a computer printer or fax output device, or it could be a
   service that interfaced with output devices.

   The protocol is heavily influenced by the printing model introduced
   in the Document Printing Application (DPA) [ISO10175] standard.
   Although DPA specifies both end user and administrative features, IPP
   version 1.0 (IPP/1.0) focuses only on end user functionality.

   The architecture for IPP defines (in the Model and Semantics document
   [RFC2566]) an abstract Model for the data which is used to control
   the printing process and to provide information about the process and
   the capabilities of the Printer. This abstract Model is hierarchical
   in nature and reflects the structure of the Printer and the Jobs that
   may be being processed by the Printer.

   The Internet provides a channel between the client and the
   server/Printer. Use of this channel requires flattening and
   sequencing the hierarchical Model data. Therefore, the IPP also
   defines (in the Encoding and Transport document [RFC2565]) an
   encoding of the data in the model for transfer between the client and
   server.  This transfer of data may be either a request or the
   response to a request.

   Finally, the IPP defines (in the Encoding and Transport document
   [RFC2565]) a protocol for transferring the encoded request and
   response data between the client and the server/Printer.

   An example of a typical interaction would be a request from the
   client to create a print job. The client would assemble the Model
   data to be associated with that job, such as the name of the job, the
   media to use, the number of pages to place on each media instance,
   etc. This data would then be encoded according to the Protocol and
   would be transmitted according to the Protocol. The server/Printer
   would receive the encoded Model data, decode it into a form
   understood by the server/Printer and, based on that data, do one of
   two things: (1) accept the job or (2) reject the job. In either case,
   the server must construct a response in terms of the Model data,
   encode that response according to the Protocol and transmit that
   encoded Model data as the response to the request using the Protocol.

   Another part of the IPP architecture is the Directory Schema
   described in the model document. The role of a Directory Schema is to
   provide a standard set of attributes which might be used to query a




 
RFC 2568                   Rationale for IPP                  April 1999


   directory service for the URI of a Printer that is likely to meet the
   needs of the client. The IPP architecture also addresses security
   issues such as control of access to server/Printers and secure
   transmissions of requests, response and the data to be printed.

2. THE PRINTER

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

3. RATIONALE FOR THE MODEL

   The Model [RFC2566] is defined independently of any encoding of the
   Model data both to support the likely uses of IPP and to be robust
   with respect to the possibility of alternate encoding.

   It is expected that a client or server/Printer would represent the
   Model data in some data structure within the applications/servers