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 hastings at cp10.es.xerox.com Tue Dec 17 17:20:35 1996
> X-Sender: hastings at zazen> X-Mailer: Windows Eudora Pro Version 2.1.2
> Mime-Version: 1.0
> Date: Tue, 17 Dec 1996 17:17:51 PST
> To: rdebry at us.ibm.com, kcarter at vnet.ibm.com> From: Tom Hastings <hastings at cp10.es.xerox.com>
> Subject: Re: IPP> Job Templates (Retry) [I like getting rid of Job
> Templates]
> Cc: ipp at pwg.org> Sender: ipp-owner at pwg.org> X-Lines: 209
>> 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, rdebry at us.ibm.com 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 at 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
> >
> >
> >
>>