Bob Herriot
> From Scott_Isaacson@novell.com Fri Dec 20 08:31:14 1996
> X-Mailer: Novell GroupWise 4.1
> Date: Thu, 19 Dec 1996 12:50:22 -0700
> From: "Scott A. Isaacson" <Scott_Isaacson@novell.com>
> To: hastings@cp10.es.xerox.com, robert.herriot@Eng
> Cc: ipp@pwg.org, rdebry@us.ibm.com, kcarter@vnet.ibm.com
> Subject: Re: IPP> Job Templates (Retry) [I like getting rid of Job
> Templates] -Reply
> Sender: ipp-owner@pwg.org
> Content-Length: 8464
> X-Lines: 191
>
> 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@novell.com
> W: http://www.novell.com
> ************************************************************
>
>
> >>> Robert Herriot <robert.herriot@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@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
> >
> >
>
>