server described for HTTP1.1 [RFC2068].

   An IPP server sends a response for each request that it receives.  If
   an IPP server detects an error, it MAY send a response before it has
   read the entire request.  If the HTTP layer of the IPP server
   completes processing the HTTP headers successfully, it MAY send an




 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


   intermediate response, such as "100 Continue", with no IPP data
   before sending the IPP response.  A client MUST expect such a variety
   of responses from an IPP server. For further information on HTTP/1.1,
   consult the HTTP documents [RFC2068].

5. Security Considerations

   The IPP Model document defines an IPP implementation with "privacy"
   as one that implements Secure Socket Layer Version 3 (SSL3).  Note:
   SSL3 is not an IETF standards track specification. SSL3 meets the
   requirements for IPP security with regards to features such as mutual
   authentication and privacy (via encryption). The IPP Model document
   also outlines IPP-specific security considerations and should be the
   primary reference for security implications with regards to the IPP
   protocol itself.

   The IPP Model document defines an IPP implementation with
   "authentication" as one that implements the standard way for
   transporting IPP messages within HTTP 1.1. These include the security
   considerations outlined in the HTTP 1.1 standard document [RFC2068]
   and Digest Access Authentication extension [RFC2069].

   The current HTTP infrastructure supports HTTP over TCP port 80. IPP
   server implementations MUST offer IPP services using HTTP over the
   IANA assigned Well Known Port 631 (the IPP default port). IPP server
   implementations may support other ports, in addition to this port.

   See further discussion of IPP security concepts in the model document
   [RFC2566].

5.1 Using IPP with SSL3

   An assumption is that the URI for a secure IPP Printer object has
   been found by means outside the IPP printing protocol, via a
   directory service, web site or other means.

   IPP provides a transparent connection to SSL by calling the
   corresponding URL (a https URI connects by default to port 443).
   However, the following functions can be provided to ease the
   integration of IPP with SSL during implementation:

      connect (URI), returns a status

         "connect" makes an https call and returns the immediate status
         of the connection as returned by SSL to the user. The status
         values are explained in section 5.4.2 of the SSL document
         [ssl].





 
RFC 2565            IPP/1.0: Encoding and Transport           April 1999


         A session-id may also be retained to later resume a session.
         The SSL handshake protocol may also require the cipher
         specifications supported by the client, key length of the
         ciphers, compression methods, certificates, etc. These should
         be sent to the server and hence should be available to the IPP
         client (although as part of administration features).

      disconnect (session)

         to disconnect a particular session.

         The session-id available from the "connect" could be used.

      resume (session)

         to reconnect using a previous session-id.

   The availability of this information as administration features are
   left for implementers, and need not be specified at this time.

6. References

   [RFC2278] Freed, N. and J. Postel, "IANA Charset Registration
             Procedures", BCP 19, RFC 2278, January 1998.

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

   [iana]    IANA Registry of Coded Character Sets:
             ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets.