rfc2566.txt

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

   Each object type has an associated set of operations (see section 3)
   and attributes (see section 4).

   It is important, however, to understand that in real system
   implementations (which lie underneath the abstracted IPP/1.0 model),
   there are other components of a print service which are not
   explicitly defined in the IPP/1.0 model. The following figure
   illustrates where IPP/1.0 fits with respect to these other
   components.

                                +--------------+
                                |  Application |
                      o         +. . . . . . . |
                     \|/        |   Spooler    |
                     / \        +. . . . . . . |   +---------+
                   End-User     | Print Driver |---|  File   |
         +-----------+ +-----+  +------+-------+   +----+----+
         |  Browser  | | GUI |         |                |
         +-----+-----+ +--+--+         |                |
               |          |            |                |
               |      +---+------------+---+            |
   N   D   S   |      |      IPP Client    |------------+
   O   I   E   |      +---------+----------+
   T   R   C   |                |
   I   E   U   |
   F   C   R   -------------- Transport ------------------
   I   T   I
   C   O   T                    |         --+
   A   R   Y           +--------+--------+  |
   T   Y               |    IPP Server   |  |
   I                   +--------+--------+  |
   O                            |           |
   N                   +-----------------+  | IPP Printer
                       |  Print Service  |  |
                       +-----------------+  |
                                |         --+
                       +-----------------+
                       | Output Device(s)|
                       +-----------------+

   An IPP Printer object encapsulates the functions normally associated
   with physical output devices along with the spooling, scheduling and
   multiple device management functions often associated with a print
   server. Printer objects are optionally registered as entries in a
   directory where end users find and select them based on some sort of
   filtered and context based searching mechanism (see section 16).  The
   directory is used to store relatively static information about the
   Printer, allowing end users to search for and find Printers that



deBry, et al.                 Experimental                     [Page 10]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   match their search criteria, for example: name, context, printer
   capabilities, etc.  The more dynamic information, such as state,
   currently loaded and ready media, number of jobs at the Printer,
   errors, warnings, and so forth, is directly associated with the
   Printer object itself rather than with the entry in the directory
   which only represents the Printer object.

   IPP clients implement the IPP protocol on the client side and give
   end users (or programs running on behalf of end users) the ability to
   query Printer objects and submit and manage print jobs.  An IPP
   server is just that part of the Printer object that implements the
   server-side protocol.  The rest of the Printer object implements (or
   gateways into) the application semantics of the print service itself.
   The Printer objects may be embedded in an output device or may be
   implemented on a host on the network that communicates with an output
   device.

   When a job is submitted to the Printer object and the Printer object
   validates the attributes in the submission request, the Printer
   object creates a new Job object.  The end user then interacts with
   this new Job object to query its status and monitor the progress of
   the job.  End users may also cancel the print job by using the Job
   object's Cancel-Job operation.  The notification service is out of
   scope for IPP/1.0, but using such a notification service, the end
   user is able to register for and receive Printer specific and Job
   specific events.  An end user can query the status of Printer objects
   and can follow the progress of Job objects by polling using the Get-
   Printer-Attributes, Get-Jobs, and Get-Job-Attributes operations.

2. IPP Objects

   The IPP/1.0 model introduces objects of type Printer and Job.  Each
   type of object models relevant aspects of a real-world entity such as
   a real printer or real print job.  Each object type is defined as a
   set of possible attributes that may be supported by instances of that
   object type.  For each object (instance), the actual set of supported
   attributes and values describe a specific implementation.  The
   object's attributes and values describe its state, capabilities,
   realizable features, job processing functions, and default behaviors
   and characteristics.  For example, the Printer object type is defined
   as a set of attributes that each Printer object potentially supports.
   In the same manner, the Job object type is defined as a set of
   attributes that are potentially supported by each Job object.

   Each attribute included in the set of attributes defining an object
   type is labeled as:





deBry, et al.                 Experimental                     [Page 11]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


     - "REQUIRED": each object MUST support the attribute.
     - "OPTIONAL": each object MAY support the attribute.

   There is no such similar labeling of attribute values.  However, if
   an implementation supports an attribute, it MUST support at least one
   of the possible values for that attribute.

2.1 Printer Object

   The major component of the IPP/1.0 model is the Printer object.  A
   Printer object implements the server-side of the IPP/1.0 protocol.
   Using the protocol, end users may query the attributes of the Printer
   object and submit print jobs to the Printer object.  The actual
   implementation components behind the Printer abstraction may take on
   different forms and different configurations.  However, the model
   abstraction allows the details of the configuration of real
   components to remain opaque to the end user.  Section 3 describes
   each of the Printer operations in detail.

   The capabilities and state of a Printer object are described by its
   attributes.  Printer attributes are divided into two groups:

     - "job-template" attributes: These attributes describe supported
       job processing capabilities and defaults for the Printer object.
       (See section 4.2)
     - "printer-description" attributes: These attributes describe the
       Printer object's identification, state, location, references to
       other sources of information about the Printer object, etc. (see
       section 4.4)

   Since a Printer object is an abstraction of a generic document output
   device and print service provider, a Printer object could be used to
   represent any real or virtual device with semantics consistent with
   the Printer object, such as a fax device, an imager, or even a CD
   writer.

   Some examples of configurations supporting a Printer object include:

     1) An output device with no spooling capabilities
     2) An output device with a built-in spooler
     3) A print server supporting IPP with one or more associated output
        devices
        3a) The associated output devices may or may not be capable of
          spooling jobs
        3b) The associated output devices may or may not support IPP






deBry, et al.                 Experimental                     [Page 12]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


   The following figures show some examples of how Printer objects can
   be realized on top of various distributed printing configurations.
   The embedded case below represents configurations 1 and 2. The hosted
   and fan-out figures below represent configurations 3a and 3b.

   Legend:

   ##### indicates a Printer object which is
         either embedded in an output device or is
         hosted in a server.  The Printer object
         might or might not be capable of queuing/spooling.

   any   indicates any network protocol or direct
         connect, including IPP


   embedded printer:
                                             output device
                                           +---------------+
    O   +--------+                         |  ###########  |
   /|\  | client |------------IPP------------># Printer #  |
   / \  +--------+                         |  # Object  #  |
                                           |  ###########  |
                                           +---------------+


   hosted printer:
                                           +---------------+
    O   +--------+        ###########      |               |
   /|\  | client |--IPP--># Printer #-any->| output device |
   / \  +--------+        # Object  #      |               |
                          ###########      +---------------+



                                            +---------------+
   fan out:                                 |               |
                                        +-->| output device |
                                    any/    |               |
    O   +--------+      ###########   /     +---------------+
   /|\  | client |-IPP-># Printer #--*
   / \  +--------+      # Object  #   \     +---------------+
                        ########### any\    |               |
                                        +-->| output device |
                                            |               |
                                            +---------------+





deBry, et al.                 Experimental                     [Page 13]

RFC 2566              IPP/1.0: Model and Semantics            April 1999


2.2 Job Object

   A Job object is used to model a print job.  A Job object contains
   documents.  The information required to create a Job object is sent
   in a create request from the end user via an IPP Client to the
   Printer object.  The Printer object validates the create request, and
   if the Printer object accepts the request, the Printer object creates
   the new Job object.  Section 3 describes each of the Job operations
   in detail.

   The characteristics and state of a Job object are described by its
   attributes.  Job attributes are grouped into two groups as follows:

     - "job-template" attributes: These attributes can be supplied by
       the client or end user and include job processing instructions
       which are intended to override any Printer object defaults and/or
       instructions embedded within the document data. (See section 4.2)
     - "job-description" attributes: These attributes describe the Job
       object's identification, state, size, etc. The client supplies
       some of these attributes, and the Printer object generates others.
       (See section 4.3)

   An implementation MUST support at least one document per Job object.
   An implementation MAY support multiple documents per Job object.  A
   document is either:

     - a stream of document data in a format supported by the Printer
       object (typically a Page Description Language - PDL), or