IPP> OPS - Diagrams showing Printer and Device objects with fan-out an d fan-in

IPP> OPS - Diagrams showing Printer and Device objects with fan-out an d fan-in

IPP> OPS - Diagrams showing Printer and Device objects with fan-out an d fan-in

Hastings, Tom N hastings at cp10.es.xerox.com
Wed Nov 3 03:21:33 EST 1999


Here is the new section that I'm writing for the Set3 spec that introduces
the Device object.  The fan-out pictures should be put into the Set2 spec.
Please send comments.
Thanks,
Tom

1.1	Device object
The OPTIONAL Device object models the physical output device that an IPP
Printer object logically represents.  The purpose of the Device object is to
model those operations and attributes that are closely tied to the physical
device (see [ipp-mod] section 2.1).  A Get-Device-Attributes operations
returns Device objects as specified in the "requested-attributes" supplied
by the client.
An IPP Printer object is associated with exactly one Device object, as
specified by the Printer's "associated-devices" (name(127)) attribute.  A
Device object is associated with one or more Printer objects as specified by
the Device's "associated-printers" (1setOf name(127)).  If the Device object
is associated with more than one Printer object, the configuration is
referred to as "fan-in".  Such a configuration can be used to offer
different classes of service, including differing capabilities and/or
defaults, for each Printer object with possibly differing access control.
While not explicitly provided in IPP/1.1 [ipp-mod], fan-in is not precluded
by the IPP/1.1 semantics.
If an IPP Printer object is supporting more than one output device, such a
configuration is called "fan-out" (see [ipp-mod] section 2.1).  In order to
represent a fan-out configuration, the [ipp-set2] specification REQUIRES
that the IPP Printer object be a "parent" Printer object that supports two
or more subordinate Printer objects, one for each device (see [ipp-set2]).
Such a parent Printer object MUST NOT have an associated Device object.
Only the subordinate Printer objects MAY have associated Device objects.
Thus the figures in [ipp-mod] should be re-drawn to show the parent Printer
object, multiple subordinate Printer objects and their associated Device
objects.
Legend:

----> indicates a network protocol with the direction of its requests

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

***** indicates a Device object which is either
      embedded in a output device or is
      hosted in a server.

..... indicates an association between Printer and Device objects

any   indicates any network protocol or direct 
      connect, including IPP


embedded Printer and Device objects:
                                                  output device
                                         +----------------------------+
 O   +--------+                          |  ###########   **********  |
/|\  | client |------------IPP-------------># Printer #...* Device *  |
/ \  +--------+                          |  # Object  #   * object *  |
                                         |  ###########   **********  |
                                         +----------------------------+


hosted Printer and Device objects:
                                server
                     +---------------------------+      
 O   +--------+      | ###########   **********  |      +--------+
/|\  | client |--IPP--># Printer #...* Device *  |-any->| output |
/ \  +--------+      | # object  #   * object *  |      | device |
                     | ###########   **********  |      +--------+
                     +---------------------------+

                                                  output device
                                         +----------------------------+
                                         |  ###########   **********  |
fan out:                server        +----># subord. #   * Device *  |
                   +-------------+   /   |  # Printer #...* object *  |
                   | ########### | any   |  # object  #   **********  |
 O   +--------+    | # parent  # | /     |  ###########               |
/|\  | client |-IPP-># Printer #--*      +----------------------------+
/ \  +--------+    | # object  # | \     +----------------------------+
                   | ########### | any   |  ###########   **********  |
                   +-------------+   \   |  # subord. #   * Device *  |
                                      +----># Printer #...* object *  |
                                         |  # object  #   **********  |
                                         |  ###########               |
                                         +----------------------------+
                                                  output device
                            server
fan in:                 +-------------+
                        | ########### |
                     +---># Printer #.....
                    /   | # object  # |   .
                  IPP   | ########### |    .   output device
 O   +--------+   /     |             |     .   +--------+
/|\  | client |--+      |             |      ...| Device |
/ \  +--------+   \     |             |     .   | object |
                  IPP   | ########### |    .    +--------+
                    \   | # Printer # |   .
                     +---># object  #.....
                        | ########### |
                        +-------------+
Figure 1 - Embedded, hosted, fan-out, and fan-in configurations
Note:  the addition of subordinate Printer objects and the Device object is
completely compatible with IPP/1.0 and IPP/1.1.  The protocol and semantics
are the same between a client and a Printer object for all configurations.




More information about the Ipp mailing list