may each exist in different security domains. When objects are in
   different security domains the design goals for authentication and
   message protection may be much stronger than when they are all in the
   same domain.

   Secondly, the sensitivity and value of the content being printed will
   vary from one instance of a print job to another. For example, a
   publicly available document does not need the same level of
   protection as a payroll document does.  Message protection design
   goals include data origin authentication, privacy, integrity, and
   non-repudiation.







 
RFC 2567             Internet Printing Design Goals           April 1999


   In many environments (e.g. Windows, OS/2) a printer driver may be
   needed to create the proper datastream for printer.  This document
   discusses downloading such a new driver from a variety of sources.
   Downloading and installing any software, including drivers) on a
   computer exposes that computer to a number of security risks
   including but not limited to:

      - defective software
      - malicious software (e.g. Trojan horses)
      - inappropriate software (i.e. software doing something
        deemed unreasonable by the user.)

   As such, proper security considerations and actions need to be taken
   by the user and/or a system administrator to prevent the compromising
   of the computer.  Administrators should configure downloading
   mechanism for printer drivers in such a way as to be able to verify
   the source of driver software and encrypt or otherwise protect that
   software during download.

   Examples including security considerations can be found in sections 5
   (IPP SCENARIOS) and 10 (APPENDIX - DETAILED SCENARIOS) later in this
   document.

4.2. INTERACTION WITH LPD (RFC1179)

   Many versions of UNIX and in fact other operating systems provide a
   means of printing as described in [RFC1179] (Line Printer Daemon
   Protocol.)  This document describes the file formats for the control
   and data files as well as the messages used by the protocol.  Because
   of the simplistic approach taken by this protocol, many manufacturers
   have include proprietary enhancements and extensions to 'lpd.'
   Because of this divergence and due to other design goals described in
   this document, there is no requirement for backward compatibility or
   interoperability with 'lpd'.  However, a mapping of LPD functionality
   and IPP functionality shall be provided so as to enable a gateway
   between LPD and IPP.

4.3. EXTENSIBILITY

   The Internet Printing Protocol shall be extensible by several means
   that facilitate interoperability and prevent implementation
   collisions:

      - by providing a process whereby implementers can submit proposals
      for registration of new attributes and new enumerated values for
      existing attributes.






 
RFC 2567             Internet Printing Design Goals           April 1999


         * that require review and approval.  The Internet Assigned
         Number Authority (IANA) will be the repository for such
         accepted registration proposals after review.

         * that do not require review and approval.  IANA will be the
         repository for such registrations.

      - by providing syntax in the protocol so that implementers may add
      private (i.e. unregistered) attributes and  enumerated attribute
      values.

      - by providing versioning and negotiation so as to enable future
      implementations of IPP to interoperate with implementations of
      version 1.0 of IPP.

4.4. FIREWALLS

   As stated in section 3 Design Goals, Internet printing shall, by
   definition, support printing from one enterprise to another.  As
   such, the Internet printing protocol must be capable of passing
   through firewalls and/or proxy servers (where enabled by the firewall
   administrator) preferably without modification to the existing