that support IPP. Therefore, the Model was designed to make that
   representation straightforward. Typically a parser or formatter would
   be used to convert from or to the encoded data format. Once in an
   internal form suitable to a product, the data can be manipulated by
   the product. For example, the data sent with a Print Job can be used
   to control the processing of that Print Job.

   The semantics of IPP are attached to the (abstract) Model.
   Therefore, the application/server is not dependent on the encoding of
   the Model data, and it is possible to consider alternative mechanisms
   and formats by which the data could be transmitted from a client to a
   server; for example, a server could have a direct, client-less GUI
   interface that might be used to accept some kinds of Print Jobs. This
   independence would also allow a different encoding and/or
   transmission mechanism to be used if the ones adopted here were shown
   to be overly limiting in the future. Such a change could be migrated
   into new products as an alternate protocol stack/parser for the Model
   data.








 
RFC 2568                   Rationale for IPP                  April 1999


   Having an abstract Model also allows the Model data to be aligned
   with the (abstract) model used in the Printer [RFC1759], Job and Host
   Resources MIBs. This provides consistency in interpretation of the
   data obtained independently of how the data is accessed, whether via
   IPP or via SNMP [RFC1905, RFC1906] and the Printer/Job MIBs.

   There is one aspect of the Model that deserves some extra
   explanation. There are two ways for identifying a Job object: (a)
   with a Job URI and (b) using a combination of the Printer URI and a
   Job ID (a 32 bit positive integer). Allowing Job objects to have URIs
   allows for flexibility and scalability. For example a job could be
   moved from a printer with a large backlog to one with a smaller load
   and the job identification, the Job object URI, need not change.
   However, many existing printing systems have local models or
   interface constraints that force Job objects to be identified using
   only a 32-bit positive integer rather than a URI.  This numeric Job
   ID is only unique within the context of the Printer object to which
   the create request was originally submitted.  In order to allow both
   types of client access to Jobs (either by Job URI or by numeric Job
   ID), when the Printer object successfully processes a create request
   and creates a new Job, the Printer object generates both a Job URI
   and a Job ID for the new Job object. This requirement allows all
   clients to access Printer objects and Job objects independent of any
   local constraints imposed on the client implementation.

4. RATIONALE FOR THE PROTOCOL

   There are two parts to the Protocol: (1) the encoding of the Model
   data and (2) the mechanism for transmitting the model data between
   client and server.

4.1 The Encoding

   To make it simpler to develop embedded printers, a very simple binary
   encoding has been chosen. This encoding is adequate to represent the
   kinds of data that occur within the Model. It has a simple structure
   consisting of sequences of attributes. Each attribute has a name,
   prefixed by a name length, and a value. The names are strings
   constrained to characters from a subset of ASCII.  The values are
   either scalars or a sequence of scalars. Each scalar value has a
   length specification and a value tag which indicates the type of the
   value. The value type has two parts: a major class part, such as
   integer or string, and a minor class part which distinguishes the
   usage of the major class, such as dateTime string. Tagging of the
   values with type information allows for introducing new value types
   at some future time.






 
RFC 2568                   Rationale for IPP                  April 1999


   A fully encoded request/response has a version number, an operation
   (for a request) or a status and optionally a status message (for a
   response), associated parameters and attributes which are encoded
   Model data and, optionally (for a request), print data following the
   Model data.

4.2 The Transmission Mechanism

   The chosen mechanism for transmitting the encoded Model data is HTTP
   1.1 Post (and associated response). No modifications to HTTP 1.1 are
   proposed or required. The sole role of the Transmission Mechanism is
   to provide a transfer of encoded Model data from/to the client
   to/from the server. This could be done using any data delivery
   mechanism. The key reasons why HTTP 1.1 Post is used are given below.