rfc2567.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Wright                        Experimental                      [Page 6]

RFC 2567             Internet Printing Design Goals           April 1999


   While an Internet printing protocol may not of itself include this
   function, IPP must define and enable a directory schema which will
   provide the necessary information for a directory service
   implementation to consistently represent printers by their IPP
   attributes.

3.1.2. Create an instance of the printer.

   After finding the desired printer, an end-user needs to be able to
   create a local instance of that printer within the end-user operating
   system or desktop.  This local instance will vary depending upon the
   printing paradigm of the operating system.  For example, some UNIX
   users will only want a queue or a reference to a remote printer
   created on their machine while other UNIX users and Windows NT users
   will want the queue and also the necessary icons and registry entries
   to be created and initialized.  Where required, drivers may need to
   be downloaded from some repository and installed on the computer.
   All necessary decompressing, unpacking, and other installation
   actions should occur without end-user interaction or intervention
   excepting initial approval by the end-user.  Once the local instance
   of the printer has been installed, it shall appear to the end-user of
   the operating system and to the applications running there as any
   other printer (local, local area network connected, or network
   operating system connected) on the end-user desktop or environment.
   IPP's role in this goal is simply to enable the creation of the
   printer instance providing information such as where to locate a
   printer driver for this printer, as an attribute of an IPP Printer.

3.1.3. Viewing the status and capabilities of a printer.

   Before using a selected printer or, in fact at any time, the end-user
   needs the ability to verify the characteristics and status of both
   printers and jobs queued for that printer.  When checking the
   characteristics of a printer, the end-user typically wants to be able
   to determine the capability of the device, e.g.:

   - supported media, commonly paper, by size and type
   - paper handling capability, e.g. duplex, collating, finishing
   - color capability

   When checking the status of the printer and its print jobs, the end-
   user typically wants to be able to determine:

   - is the printer on-line?
   - what are the defaults to be used for printing?
   - how many jobs are queued for the printer?
   - how are job priorities assigned? (outside the scope of IPP)




Wright                        Experimental                      [Page 7]

RFC 2567             Internet Printing Design Goals           April 1999


3.1.4. Submitting a print job.

   Once the desired printer has been located and installed, the end-user
   wants to print to that printer from normal applications using
   standard methods.  These normal applications include such programs as
   word processors, spreadsheets, data-base applications, WEB browsers,
   production printing applications, etc.  Additionally, the end-user
   may want to print a file already existing on the end-user's computer
   -- "simple push".  In addition to printing from an application and
   simple push, the end-user needs to have the ability to submit a print
   job by reference.  Printing by reference is defined to mean as
   submitting a job by providing a reference to an existing document.
   The reference, a URI, will be resolved before the actual print
   process occurs.  Submitting a job by reference relieves the user from
   downloading the document from the remote server and then sending it
   via IPP to the printer.  This saves both time and network bandwidth.

   Some means shall be provided to determine if the format of a job
   matches the capability of the printer.  This can be done by one of
   the following (all of which are outside of scope of the IPP
   protocol):

      - the end-user selects the correct printer driver
      - the printer automatically selects the proper interpreter
      - the end-user uses some other manual procedure.

   A standard action shall be defined should the job's requirements not
   match the capabilities of the printer.

   Because the end-user does not want to know the details of the
   underlying printing process, the protocol must support job-to-printer
   capability matching (all implementations are not necessarily required
   to implement this function.)  This matching capability requires
   knowing both the printer's capabilities and attributes and those
   capabilities and attributes required by the job.  Actions taken when
   a print job requires capabilities or attributes that are not
   available on the printer vary and can include but are not limited to:

   - rejecting the print job
   - redirecting the print job to another printer (Not in V1.0)
   - printing the job, accepting differences in the appearance

   Print jobs will also be submitted by background or batch applications
   without human intervention.

   End-users need the ability to set certain print job parameters at the
   time the job is submitted.  These parameters include but are not
   limited to:



Wright                        Experimental                      [Page 8]

RFC 2567             Internet Printing Design Goals           April 1999


   - number of copies
   - single or two sided printing
   - finishing
   - job priority

3.1.5. Viewing the status of a submitted print job.

   After a job has been submitted to a printer, the end-user needs a way
   to view the status of that job (i.e. job waiting, job printing, job
   done) and to determine where the job is in the print queue.

   In addition to the need to inquire about the status of a print job,
   automatic notification of the completion of that job is also
   required.

   Notification means are not defined by the protocol but the protocol
   must provide a means of enabling and disabling the notification.

3.1.6. Canceling a Print Job

   While a job is waiting to be printed or has been started but not yet
   completed, the original creator/submitter of the print job (i.e. the
   end-user) shall be able to cancel the job entirely (job is waiting)
   or the remaining portion of it (job is printing.)  Altering the print
   job itself is not a V1.0 design goal.

3.2. OPERATOR (NOT REQUIRED FOR V1.0)

   An operator of a printer accepting jobs through the Internet is one
   of the roles in which humans act.  The operator has the
   responsibility of monitoring the status of the printer as well as
   managing and controlling the jobs at the device.  These
   responsibilities include but are not limited to the replenishing of
   supplies (ink, toner, paper, etc.), the clearing of minor errors
   (paper jams, etc.) and the re-prioritization of end-user jobs.
   Operator wants and needs will not be addressed by V1.0 of the
   protocol.

   The wants and needs of the operator include all those of the end-user
   but may include additional privileges.  For example, an operator may
   be able to view all print jobs on a printer while the end-user might
   only be able to see his own jobs.

3.2.1. Alerting.

   One of the required operator functions is having the ability to
   discover or to be alerted to changes in the status of a printer
   particularly those changes that cause a printer to stop printing and



Wright                        Experimental                      [Page 9]

RFC 2567             Internet Printing Design Goals           April 1999


   to be able to correct those problems.  As such, an Internet printing
   protocol shall be able to alert a designated operator or operators to
   these conditions such as 'out of paper', 'out of ink', etc.
   Additionally. the operator shall be able to, asynchronous to other
   printer activity, inquire as to a printer's or a job's status.

3.2.2. Changing Print and Job Status.

   Another of the required operator functions is the ability to affect
   changes to printer and job status remotely.  For example, the
   operator will need to be able to re-prioritize or cancel any print
   jobs on a printer to which the operator has authority.

3.3. ADMINISTRATOR (NOT REQUIRED FOR V1.0)

   An administrator of a printer accepting jobs through the Internet is
   one of the roles in which humans act.  The administrator has the
   responsibility of creating the printer instances and controlling the
   authorization of other end-users and operators.  Administrator wants
   and needs will not be addressed by V1.0 of the protocol.

   The wants and needs of the administrator include all those of the
   end-user and, in some environments, some or all of those of the
   operator.  Minimally, the administrator must also have the tools,
   programs, utilities and supporting protocols available to be able to:

   - create an instance of a printer
   - create, edit and maintain the list of authorized end-users
   - create, edit and maintain the list of authorized operators
   - create, edit and maintain the list of authorized
     administrators
   - create, customize, change or otherwise alter the manner in
     which the status capabilities and other information about printers
     and jobs are presented
   - create, customize, or change other printer or job features
   - administrate billing or other charge-back mechanisms
   - create sets of defaults
   - create sets of capabilities

   The administrator must have the capability to perform all the above
   tasks locally or remotely to the printer.

4. OBJECTIVES OF THE PROTOCOL

   The protocol to be defined by an Internet printing working group will
   address the wants and needs of the end-user (V1.0).  It will not, at
   least initially, address the operator or administrator wants and
   needs (V2.0).



Wright                        Experimental                     [Page 10]

RFC 2567             Internet Printing Design Goals           April 1999


   The protocol defined shall be independent of the operating system of
   both the client and the server.  Generally, any platform capable of
   supporting a WEB Browser should be capable of being a client.
   Generally, any platform providing a WEB/HTTP server and printing
   services should be capable of being a server.  Usage of the WEB
   Browser and Server is not required for IPP; the operating system,
   operating system extensions or other applications may provide IPP
   functionality directly.

   In many environments such as Windows 95, Windows NT and OS/2, the
   print data is created and transmitted to the printer on the fly
   rather than being created, spooled and then transmitted to the
   printer (a typical UNIX method.)  The Internet Printing Protocol must
   properly handle either methodology and make this transparent to the
   end-user.

4.1. SECURITY CONSIDERATIONS

   It is required that the Internet Printing Protocol be able to operate
   within a secure environment. Wherever reasonable, IPP ought to make
   use of existing security protocols and services. IPP will not invent
   new security features when the design goals described in this
   document can be met by existing protocols and services. Examples of
   such services include Secure Socket Layer Version 3 (SSL3) [SSL] and
   HTTP Digest Access Authentication [RFC2069].  Note: SSL3 is not on
   the IETF standards track.

   Since we cannot anticipate the security levels or the specific
   threats that any given IPP print administrator may be concerned with,
   IPP must be capable of operating with different security mechanisms
   and policies as required by the individual installation. The initial
   security needs of IPP are derived from two primary considerations.
   First, the printing environments described in this document take into
   account that the client, the Printer, and the document to be printed
   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.






Wright                        Experimental                     [Page 11]

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