rfc2568.txt

RFC 的详细文档！

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




Zilles                        Experimental                      [Page 6]

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.



Zilles                        Experimental                      [Page 7]

RFC 2568                   Rationale for IPP                  April 1999


6. SECURITY CONSIDERATIONS - RATIONALE FOR SECURITY

      Security is an area of active work on the Internet. Complete
      solutions to a wide range of security concerns are not yet
      available. Therefore, in the design of IPP, the focus has been on
      identifying a set of security protocols/features that are
      implemented (or currently implementable) and solve real problems
      with distributed printing. The two areas that seem appropriate to
      support are: (1) authorization to use a Printer and (2) secure
      interaction with a printer. The chosen mechanisms are the digest
      authentication mechanism of HTTP 1.1 and SSL3 [SSL] secure
      communication mechanism.

7. REFERENCES

   [ipp-iig]  Hastings, T. and C. Manros, "Internet Printing
              Protocol/1.0:Implementer's Guide", Work in Progress.

   [RFC2569]  Herriot, R., Hastings, T., Jacobs, N. and J. Martin,
              "Mapping between LPD and IPP Protocols", RFC 2569, April
              1999.

   [RFC2566]  deBry, R., Isaacson, S., Hastings, T., Herriot, R. and P.
              Powell, "Internet Printing Protocol/1.0: Model and
              Semantics", RFC 2566, April 1999.

   [RFC2565]  Herriot, R., Butler, S., Moore, P. and R. Tuner, "Internet
              Printing Protocol/1.0: Encoding and Transport", RFC 2565,
              April 1999.

   [RFC2567]  Wright, D., "Design Goals for an Internet Printing
              Protocol", RFC 2567, April 1999.

   [ISO10175] ISO/IEC 10175 "Document Printing Application (DPA)", June
              1996.

   [RFC1759]  Smith, R., Wright, F., Hastings, T., Zilles, S. and J.
              Gyllenskog, "Printer MIB", RFC 1759, March 1995.

   [RFC1905]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
              "Protocol Operations for Version 2 of the Simple Network
              Management Protocol (SNMPv2)", RFC 1905, January 1996.

   [RFC1906]  Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
              "Transport Mappings for  Version 2 of the Simple Network
              Management Protocol (SNMPv2)", RFC 1906, January 1996.





Zilles                        Experimental                      [Page 8]

RFC 2568                   Rationale for IPP                  April 1999


   [SSL]      Netscape, The SSL Protocol, Version 3, (Text version
              3.02), November 1996.

8. AUTHOR'S ADDRESS

   Stephen Zilles
   Adobe Systems Incorporated
   345 Park Avenue
   MailStop W14
   San Jose, CA 95110-2704

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]





































Zilles                        Experimental                      [Page 9]

RFC 2568                   Rationale for IPP                  April 1999


9.  Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Zilles                        Experimental                     [Page 10]