# Regarding Issue #79 ("Add Printer fan-in") in Tom's recently posted
# issues document:
# > ftp::/ftp.pwg.org/pub/pwg/ipp/new_MOD/
# > -rw-r--r-- 1 pwg pwg 19968 Mar 20 08:42 isstnh03.doc
# > -rw-r--r-- 1 pwg pwg 23062 Mar 20 08:43 isstnh03.pdf
# I understand the desired goal as stated by Tom in his document. I also
# agree that some sort of "default job ticket" mechanism can be very useful
# in providing for the automatic setting/assignment of document production
# attributes.
# However, if the model then implies that "Printer" is not really a
# one-to-one association with a physical printer, we are going to run
# into some complexities when we (eventually) try to design management
# capabilities.
# That is, if a management-oriented app wants to use IPP as a way to
# determine the set of printers that may be managed, how does the app
# discover the actual physical printers associated with a Printer?
There are several issues involved here:
1. Does management want user to 'know' what physical printers
are involved?
2. Does management want to allow users to 'directly' query physical
printers.
3. Because a user has a job on one of the printers, should they
be allowed to query all of them?
# With "fan-in" (as proposed), when it comes to management of physical
# printers, the management side of the model can't use the concept of
# "Printer" due to this type of association.
I can see the IPP 'fan in' printer acting as a 'virtual' printer, with the
'back end' printer hidden from direct user view.
This makes a lot of sense from some viewpoints.
On the other hand, I see some scenarios where it would be useful to see
the actual printer status.
And I see where you would like to have the ability to configure one or the other.
Patrick Powell
# Comments?
# ...jay