I agree with a lot of what you say below, but not all.
Comments are below.
Bob Herriot
> From hastings@cp10.es.xerox.com Wed Dec 18 15:39:52 1996
>
> At 19:05 12/17/96 PST, Robert Herriot wrote:
>
> >I have tried to keep the fan-in concept supported by job template/default
> >values as a simple way of initializing a job in different ways for what
> >is fundamentally the same output device via all associated Printers.
> >
> >I suggest that we not try to solve the problem of limiting feature
> >access (as Tom suggests) via different Printers for a particular output
> >device during this project. That mechanism is very different from
> >simple initialization of values, and it adds to the complexity.
> >
>
> I think that the above is a good summary of the issue.
>
> From the user's point of view, I don't see any complexity being added
> by having fan-in of Printer objects. As far as the user is concerned
> there are just Printer objects that the Directory contains and that
> the end-user can submit to. The end-user can tell whether a Printer
> is (1) the only Printer for an output device, (2) fanning-in to an
> output device or (3) fanning-in to another Printer object.
You are right. From the end-user's point of view, a Printer is just
collection of potential features and defaults, and it doesn't matter
whether there is fan-in or not.
But from an administrator's point of view it does matter. We are
moving toward a world of zero or near-zero administration. So that
interface needs to be kept very simple for most sites.
I believe that when there are several Printers A, B and C that fan-in
to output device X, the defaults for A, B and C may differ, but the
features available are the same and all come from X. I would like an
adminstrator/operator to be able to change a feature of a printer A
and have printer's B and C feel those changes. For example
when someone changes the paper for A, Printers B and C get the same
change and it should not be necessary for an adminstrator/operator to
change all 3 printers.
>
> In fact, the confusion that I see is with having fan-in of job templates
> because our current draft has it both ways that a URL on the Print operation
> can specify either a Printer or a Job Template. By allowing fan-in
> only of Printer objects, the whole concept of Job Templates disappears
> from the end-user's view.
Using the above example of Printers A, B and C, I would be happy if A,
B and C each had their own defaults which an administrator would set
separately. This would remove the need for a job template. One possible
solution that permanently avoids a job template is to include a
a Printer attribute called defaults-name. An adminstrator can make
a change to a printer's defaults and have them propagate to other
printers with the same defaults-name. This is somewhat like the style
notion of MS Word.
>
> When we do go to IPP 2.0, we can revisit the idea of implementing the
> defaulting mechanism as an object that multiple printers can share, as
> you suggest that may be a help to some administrators, though it adds
> the complication of objects referring to other objects and dangling references,
> i.e., Printer objects referring to Job Template objects. Adding Job Templates
> to IPP 2.0 will not change the simple end-users view; adding Job Template
> objects will only help (or hurt) an Administrators job of specifying defaults
> for a set of Printer objects.
>
> I also think that the ability to have different access control and policies
> for the same output device to be a very important feature for some
> situations. Only fan-in of Printer objects will permit different policies
> for the same output device. Fan-in of Job Templates will only get different
> defaults. Defaults cannot be used to enforce policy; defaults are valid
> values for end-users to supply, but the user can change them to any other
> supported value that the policy specifies. If there can only be one Printer
> object for an output device, there can only be one policy for that output
> device.
I do not believe that the issue of policies belong in the model that I have
just suggested. If we believe that differing policies are important for
printers A, B and C (mentioned above), then I believe we need an entirely
different mechanism, perhaps in V1.0, but more likely in a later version.
I would suggest that policies could be implemented by allowing a
a constraint or override flag to be associated with any printer
attribute which an administrator wants to be different from the output
device. Constraints are limited to xxx-supported and end-user-acl.
The override flag is limited to maximum-xxx.
With constraints, a filter can be associated with an attribute values
of the output device's Printer object. For the xxx-supported
attributes, the constraints could list either the values to include or
the values to exclude, but the states are not included in the
constraint. For end-user-acl there could also be an include or exclude
list. For maximum-xxx attributes, there could be an override flag. The
filter determines which values come through from the output device's
Printer object but does not alter them. For example a filter for
Printer A's media-supported might include only letter, in which case
Printer A would show only letter paper and its state would be whatever
came from the output device, such as ready, not-ready or on-order.
>
> Tom
>
>