Subject: IPP> MOD - Concerns about "fan-in"

From: JK Martin <[email-masked]>
Date: Thu, 20 Mar 1997 05:08:33 -0500 (EST)

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?

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.

Comments?

	...jay

---

From: Patrick Powell <[email-masked]>
Date: Sat, 22 Mar 1997 15:27:52 -0800 (PST)

# From: JK Martin <[email-masked]>
# To: [email-masked]
# Subject: IPP> MOD - Concerns about "fan-in"

# 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