Subject: Re: IPP> Job Templates (Retry) [I like getting rid of Job Templates]

From: Tom Hastings <[email-masked]>
Date: Tue, 17 Dec 1996 17:17:51 PST

Keith and Roger,

I agree with the idea of getting rid of job templates for IPP V1.0.

Let me paraphrase Keith's proposal that build on Roger's:

Each URL in the Print operation specifies a Printer object.
Each URL in the Get-Attributes operation specifies either a job object
or a Printer object (but no longer a Job Template object).

I also agree with the idea of allowing more than one Printer object to
represent a single output device.  When more than one Printer object
represents a single output device (or represents another Printer), 
its called "fan-in".  With fan-in, Printer can have different policies 
specified by different sets of xxx-supported attribute values and
max-xxx-supported attribute values.  The SA can set up an ACL for each 
Printer that specifies which users can have access to which Printer 
objects that fan-in to the same output device.  So the SA can establish 
separate policies for different sets of users.  Some users can use the 
expensive color option of the output device and others can only use the 
black-and-white option.

I also like the idea of using the GetAttributes operation with a "special"
value of the requested-attributes input parameter of "job-submission" to 
indicate that the requester wants all of the xxx-supported printer attributes, 
but none of the other printer attributes, such as printer-name, 
printer-location, etc., unless the requester also includes those attributes 
in the requested-attributes input parameter to the GetAttributes operation.  
Then an implementation can add additional xxx-supported attributes and the 
requester automatically gets the new ones.  I'd suggest changing the name of 
this "pseudo" attribute from "job-submission" to "job-submission-attributes".

Finally, I like the idea of using the first value returned of each
xxx-supported attribute to mean the default value.  Then the requester
can get the defaults and all supported values specified by the SA as the
policy for that Printer in one request as you point out.  

   NOTE: we must then specify that the *order) of attribute values is 
   significant in IPP.

(ISO DPA and other attribute standards specify that the order of attribute
values shall not be significant.  If we want to be compatible with not making 
attribute values significant, we could just as another ":default" adornment in 
our State syntax, so that ":default" would be tacked onto the end of the
default value.  We need to check with MIME syntax to see if we can use
the simpler idea that order matters so that we can specify that the first
value of an xxx-supported attribute is the default.  In addition to being
more compact, specifying that the first attribute is the default, means
that there cannot be the error condition of no ":default" or more than
one ":default" value returned.).

If the SA policy is that there is only one value, then that value is both 
the default value and the only supported value.  If the Printer policy is 
to support several values, then the first is the default and the remaining 
are additional supported values.  Then the requester can determine the 
defaults without IPP having to expose the Job Template.  (And implemetations 
can implement defaults internally without having to have Job Templates,  
if they don't want to, or they can have Job Templates internally, like ISO 
DPA initial-value-job and initial-value-document objects).

Looks like a real good simplification for IPP V1.0!

Please check to see if my understanding of your proposal is the same as yours.

Thanks,
Tom

At 11:44 12/17/96 PST, [email-masked] wrote:
>Classification:
>Prologue:
>Epilogue:
>
>Keith, If I understand your comments correctly, I think that this is similar to
>the approach that Steve Gebert has taken in his prototype, and similar to my
>thoughts. I suggested that the job attributes returned by synthesised by the
>Printer to include defaults and policy as well.
>---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/17/96 12:37
>PM ---------------------------
>
>        ipp-owner @ pwg.org
>        12/17/96 12:24 PM
>
>
>To: ipp @ pwg.org@internet
>cc:
>Subject: IPP> Job Templates (Retry)
>
>IPP Team,
>
>I am having trouble sending notes to the ipp mailing list via my email
>system so I'm resending the attached note on Job Templates to the ipp
>mailing list just to be safe.
>
>Keith
>
>=========================================================================
>Date: 16 December 1996, 12:47:45 CST
>From: kcarter at vnet.ibm.com
>To:   ipp at pwg.org
>cc:   kcarter at vnet.ibm.com
>Subject: Job Templates
>
>IPP Team,
>
>In my opinion, Job Template objects should not be supported in IPP 1.0
>because doing so increases the complexity of the IPP print model
>and solution.  Instead, IPP should allow an application to query a
>Printer Object for attributes/values used to submit a print job (called
>"Job Submission Attributes" in this note).  An application can then
>present each attribute, its default value and its supported values to
>the end-user who can either accept or modify the default value for
>each attribute when submitting a print job.  Furthermore, since an
>administrator can assign multiple Printer Objects to an output device,
>the administrator can setup different default Job Submission Attributes
>for different users or groups of users who use the same output device.
>
>Issues with Job Templates
>-------------------------
>
>Several issues with Job Templates have been identified in document
>ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/
>job-template-issues.pdf.  Here is my view of the major issues with
>Job Templates (in no particular order):
>
>1.  Support for unique Job Template objects per Printer Object
>    implies storage and management of these objects.  For
>    example, an IPP implementation must determine how to create,
>    manage and control access to Job Templates across users.
>
>    IPP becomes further complicated if a Job Template object can
>    be used across multiple Printer Objects.  For example, Printer
>    Objects must reference their Job Templates and, if a Job
>    Template is deleted, all Printer Objects that use that Job
>    Template must be updated to not use that Job Template.
>
>2.  If an administrator changes the output device(s) (and potentially
>    printer driver) assigned to a Printer Object which is a print
>    queue, then all Job Templates assigned to the Printer Object
>    might now be invalid because of the physical attributes of the
>    new output device(s).
>
>3.  It is not clear to me how user friendly Job Templates will be to
>    end-users.  The customers I deal with view the Printer Object,
>    complete with Job Submission Attributes, as their target for
>    print operations.  A Job Template URL as a target for printing
>    does not seem as straightforward to me and implies that these
>    URLs must now be entries in a directory so users can locate these
>    Job Template URLs for printing.
>
>4.  Since a Printer Object may be a physical output device, how do
>    these devices handle Job Templates?
>
>Proposed Job Submission Attributes
>----------------------------------
>
>Job Submission Attributes include:
>
>-  Job Sheet Attributes (6.2.4)
>-  Notification Attributes (6.2.5)
>-  Job Scheduling Attributes (except job-print-after) (6.2.6)
>-  Job Production Attributes (except page-select) (6.2.7) plus:
>   *  content-orientation (6.2.8.14)
>   *  color (y/n for color printers)
>   *  collate (y/n)
>-  Attributes for Conversion of Text and HTML Files (6.2.8)
>
>Get-Attributes Request for Job Submission Attributes
>----------------------------------------------------
>
>The following method might be used for an application to obtain
>the Job Submission Attributes from a Printer Object:
>
>Selector                Printer URL
>Requested Attributes    job-submission:
>
>This approach allows an application to obtain the Job Submission
>Attributes without having to specify each attribute in the request
>thereby reducing the size of the request and providing a mechanism
>to return additional attributes in the future if the list of Job
>Submission Attributes changes.
>
>Get-Attributes Response for Job Submission Attributes
>-----------------------------------------------------
>
>Attr-Name ":" Attri-value CR LF
>
>Attri-value = 1#Value where the first value is the default value for the
>attribute in the Printer Object and any following values in the list are
>valid selections for the Printer Object.
>
>This approach allows an application to obtain the list of Job Submission
>Attributes plus the default value and valid values for each attribute in a
>single request to minimize network overhead.  The application can then
>present a user interface to show the end-user the valid attributes, the
>default value for each attribute and, if an end-user chooses, the valid
>values for each attribute.
>
>Your thoughts?
>
>Have a super day!
>
>Keith
>
>
>

---

From: [email-masked] (Robert Herriot)
Date: Tue, 17 Dec 1996 19:05:39 -0800

I agree with Keith's desire to simplify the model by avoiding the problems
that a separate job template might create.  But I am concerned that with
Tom's proposal we are creeping back into DPA complexity.

Although we are not yet dealing with administrative issues, I would like
us to keep it in mind.  I would like the model to be that an administrator
installs an output device, perhaps customizing some of its features because
of options that were purchased. I would hope that much of the initialization
is automatic with values supplied by the output device or software supplied
with it.

Then as a second part the admininstrator defines one or more Printers 
associated with the new output device and the default values (or job
template) associated with each Printer.  The advantage of default values
rather than a job template is there is no reference that may become
dangling, as Keith pointed out. The disadvantage is that an administrator
may have to enter the same values for many printers and if a site wants to
change a default, it can not be changed in one central place. For example,
suppose a site has 500 identical output devices and it wants 2 Printers
associated with each output device: a simplex version, and a duplex version.
An administrator would find it easier to reference 2 job templates, though
an implemenation could provide a power copy from some other printer.

If an administrator is not allowed to configure an output device's
attributes once for the output device, but must instead configure the
output device attributes for each separate Printer associated with the same
output device, this rapidly becomes an administrative nightmare.  What
happens when an operator loads a new paper type? Must the operator
change the media-supported for each Printer object?  If values of Printer
attributes can differ in each Printer, e.g. media-supported, the model
gets even more complex.

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.

Bob Herriot

> From [email-masked] Tue Dec 17 17:20:35 1996
> X-Sender: hastings@zazen
> X-Mailer: Windows Eudora Pro Version 2.1.2
> Mime-Version: 1.0
> Date: Tue, 17 Dec 1996 17:17:51 PST
> To: [email-masked], [email-masked]
> From: Tom Hastings <[email-masked]>
> Subject: Re: IPP> Job Templates (Retry) [I like getting rid of Job
>   Templates]
> Cc: [email-masked]
> Sender: [email-masked]
> X-Lines: 209
> 
> Keith and Roger,
>

---

From: Tom Hastings <[email-masked]>
Date: Wed, 18 Dec 1996 12:18:20 PST

>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.

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.  

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.

Tom

---

From: [email-masked] (Robert Herriot)
Date: Wed, 18 Dec 1996 19:35:52 -0800

Tom, 

I agree with a lot of what you say below, but not all.

Comments are below.

Bob Herriot

> From [email-masked] Wed Dec 18 15:39:52 1996
> 

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. 

> 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.

> object for an output device, there can only be one policy for that output 

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.