Classification:
Prologue:
Epilogue:
Scott ... my comments on job-template
---------------------- Forwarded by Roger K Debry/Boulder/IBM on 12/04/96 06:09
AM ---------------------------
ipp-owner @ pwg.org
12/03/96 04:51 PM
To: smg1 @ VNET.IBM.COM at internet, ipp @ pwg.org at internet
cc:
Subject: IPP> Templates Issues
I have posted the files
job-template-issues.(txt, doc, pdf)
in ftp://ftp.pwg.org/pub/pwg/ipp/contributions-for-discussion/
Below are some of my views on Job Templates:
1. Job Templates are defaults only (no limitations or restrictions)
<<RKD>> Do we then need another mechanism for an administrator to
<<RKD>> set up policy attributes, e.g. can only print jobs of less
<<RKD>> than 20 pages on this printer?
<<RKD>> Steve Gebert and I were also having a discussion yesterday
<<RKD>> on whether or not the job-template provides a complete list
<<RKD>> of things that should be specified in a print request to this
<<RKD>> Printer. That is, if I ""get the job-template" and fill in the
<<RKD>> blanks or change some values from their defaults, does the
<<RKD>> client know that this represents all of the functionality
<<RKD>> available to a print request sent to this Printer?
2. Job Templates objects contain only attributes that can go into a Job
object, not a Printer Object.
3. I think that there can be 0 or more Job Templates per printer
4. Job Template objects should be unique to each Printer object (that is
not shared between Printer objects) since there has to be some
relationship between the values of attributes in a Job Templates object
and the values in the corresponding Printer object attributes. For
example, it would be a shame for a Job Template object to contain values
that are not even supported by a certain Printer to which the Job
Template is associated. Tom points out that however, it is useful to be
able to create One Job Template object and have it shared by more than
one Printer Object (it saves on administrative time to update if an update
has to be made to a Job Template object)
<<RKD>> Isn't this a implementation detail or is it really
<<RKD>> part of the IPP specification? For example, Novell
<<RKD>> may choose to implement a scheme whereby templates
<<RKD>> can be shared, but IBM may not. However, from the
<<RKD>> client's point of view it does not matter if the
<<RKD>> template is being shared by a number of output
<<RKD>> devices.
5. I think that a client should be able to query a printer and find out all of
its associated Job Templates objects. Then it could query the Job
Template object (using the Get Attributes operation on the Job Template
object) to find out the details of a given Job Template object. Or when
submitting a job, it could just point to a Job Template object and the Printer
fills in the defaults when creating the Job object from a Print operation.
<<RKD>> I'm not sure that I agree. At least there may be
<<RKD>> cases where an installation actually wants to hide
<<RKD>> the details of output devices by using job-templates.
<<RKD>> Thus the only name that the client ever knows about
<<RKD>> is the name of the job-template. We use this example
<<RKD>> in the current IPP specification. (Does this mean that
<<RKD>> it is the job-template name that goes into the
<<RKD>> directory?)
This is all very confusing since there are many levels of defaulting and
templates.
Possible Job Template locations:
1. At the Printer where the Job Templates are only known to a certain
Printer (they are not shared)
2. At some other administrative level so that they can be shared between
Printers
3. At each client workstation - the end user has "installed" the same
Printer several times each with a different Job Template. In some cases
the local Job Template (local to the client) is only a small change from
some administrator defined one and in some cases it is a totally new
creation of the end user where there was no administrative one to
tweak in the first place. It is also a problem to decide of "local" Job
Templates should be tied to a workstation or a user that is logged in: If I
am a user and I move to another machine, do I want the Printers for that
machine or do I want the printers of my "home" environment???
6. Job Templates also affect the way end users see defaults. In place
of any job attributes or Job Template attributes, there will always be
some physical defaults just because the nature of the final Output
Device. Do users want to see those overlayed with Job Templates
overlayed with attributes in the Print request?
These are more questions than answers, but I haven't had a chance yet
to formalize my thoughts better.
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
************************************************************
>>> "steve gebert Dept:ecg SN:579517 Div:ISM Ext"
<smg1 at VNET.IBM.COM> 12/03/96 02:55pm >>>
I am trying to work out some print scenarios. It seems as though the
first operation a client would want to perform is to ask the print server
what job attributes it can accept, what options are available, and what
the defaults are. Is there any concept of the client requesting the job
template to provide a set of choices to the user? The spec does state
that
a client may use a job template associated with a printer to initialize a job.
It is not clear to me if the template could be requested or if it is only
some set of values used as defaults or to constrain user supplied
information.
Can someone shed some light on this?