I agree with the recent discussion on getting rid of Job Templates in
IPP/1.0. Just for discussion purposes, here are my comments on
"policies" or "constraints" vs. "defaults". None of this should be
considered for version 1.0.
For every real instance of a Printer, there can be several entires in a
directory service, each with a different name, a URL for example. That
is multiple names (URLs) can refer back to the same Printer; each is just
a different name for that same Printer. For each different name there
can be both a LIMITS object and a TEMPLATE (DEFAULTS) object.
Note that this is can be, not must be. DEFAULTS objects are sets of
predefined end user supplied attribute values. LIMITS are sets of
predefined xxx-supported attribute values.
As jobs are submitted to a Printer, the Printer will need to know which
LIMITS and/or DEFAULTS object to apply to the job. It does this by using
the name that the submitter knows the Printer by. An administrator
configures which LIMITS and which DEFAULTS objects go with which
name for the Printer and then what the values are of those objects.
On a PRINT operation sent the Printer, the Printer can tell which LIMITS
and/or DEFAULTS to use since the name of the Printer comes in with the
PRINT request. This operation creates a JOB object. The way that
LIMITS and DEFAULTS are applied in the creation of this JOB object
follow these rules:
- The job object is initially populated with the DEFAULTS attribute values
- User supplied attributes values in the PRINT request then override any
DEFAULTS attribute values
- These are then all validated against the LIMITS attribute values. These
LIMITS attribute values override everything. If there is the notion of
madatory attributes, then the JOB is rejected if any end user attribute
value conflicts with LIMITS values. If there is not the notion of madatory
attributes, the values are simply overridden by the LIMITS object attribute
values.
If there are LIMITS or DEFAULTS objects they must be kept consistent
with any changes in the xxx-supported attributes of the Printer object.
If we allow a Modify Job operation, the Printer must make sure that the
new values are consistent with any LIMITS object, if one exists for the
name by which the end user knows this Printer.
This allows:
- one defaults object to be shared by multiple printers
- changes in the physical default characteristics to be propgated
- support for constraint (limits) implmentation
- limits could either be inclusive or exclusive (allow these vs not allow
these)
Scott
************************************************************
Scott A. Isaacson
Print Services Consulting Engineer
Novell Inc., 122 E 1700 S, Provo, UT 84606
V: (801) 861-7366, (800) 453-1267 x17366
F: (801) 861-4025, E: scott_isaacson at novell.com
W: http://www.novell.com
************************************************************
>>> Robert Herriot <robert.herriot at Eng.Sun.COM> 12/18/96 08:35pm >>>
Tom,
I agree with a lot of what you say below, but not all.
Comments are below.
Bob Herriot
> From hastings at 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
>>