The 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 recent
      evidence, HTTP 1.1 is being widely deployed as the manufacturers
      release new products. The performance benefits of HTTP 1.1 have
      been shown and manufactures are reacting positively.

      Wide deployment has meant that many of the problems of making a
      protocol work in a wide range of environments from local net to
      Intranet to Internet have been solved and will stay solved with
      HTTP 1.1 deployment.

      2. HTTP 1.1 solves most of the problems that might have required a
      new protocol to be developed. HTTP 1.1 allows persistent
      connections that make a multi-message protocol be more efficient;
      for example it is practical to have separate Create-Job and Send-
      Document messages. Chunking allows the transmission of large print
      files without having to pre-scan the file to determine the file
      length. The accept headers allow the client's protocol and
      localization desires to be transmitted with the IPP operations and
      data. 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 informed when a Job he is
      interested in is moved to another server/Printer for any reason.

      3. Most network Printers will be implementing HTTP servers for
      reasons other than IPP. These network attached Printers want to
      provide information on how to use the printer, its current state,
      HELP information, etc. in HTML. This requires having an HTTP
      server which would be available to do IPP functions as well.





 
RFC 2568                   Rationale for IPP                  April 1999


      4.  Most of the complexity of HTTP 1.1 is concerned with the
      implementation of HTTP proxies and not the implementation of HTTP
      clients and/or servers. Work is proceeding in the HTTP Working
      Group to help identify what must be done by a server.  As the
      Encoding and Transport document shows, that is not very much.

      5. HTTP implementations provide support for handling URLs that
      would have to be provided if a new protocol were defined.

      6. An HTTP based solution fits well with the Internet security
      mechanisms that are currently deployed or being deployed. HTTP
      will run over SSL3. The digest access authentication mechanism of
      HTTP 1.1 provides an adequate level of access control. These
      solutions are deployed and in practical use; a new solution would
      require extensive use to have the same degree of confidence in its
      security.  Note: SSL3 is not on the IETF standards track.

      7. HTTP provides an extensibility model that a new protocol would
      have to develop independently. In particular, the headers,
      intent-types (via Internet Media Types) and error codes have wide
      acceptance and a useful set of definitions and methods for
      extension.

      8. Although not strictly a reason why IPP should use HTTP as the
      transmission protocol, it is extremely helpful that there are many
      prototyping tools that work with HTTP and that CGI scripts can be
      used to test and debug parts of the protocol.

      9. Finally, the POST method was chosen to carry the print data
      because its usage for data transmission has been established, it
      works and the results are available via CGI scripts or servlets.
      Creating a new method would have better identified the intended
      use of the POSTed data, but a new method would be more difficult
      to deploy. Assigning a new default port for IPP provided the
      necessary identification with minimal impact to installed
      infrastructure, so was chosen instead.

5. RATIONALE FOR THE DIRECTORY SCHEMA

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




 
RFC 2568                   Rationale for IPP                  April 1999


6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY